Representative lines from a view file
-
<button class="button" id="buttonOK" type="submit">OK</button>
<script type="text/javascript">
document.getElementById("buttonOK").style.display = "none";
</script>
-
Poor man's
<noscript>
or poor man'sdisplay: none;
?You decide!
-
You mean.... these two things are one after another? Jesus.
-
It's a poor man's noscript, because if it were display:none it wouldn't ever be shown to users without JS, would it?
-
Sounds like poor man's noscript to me.
I love this bit:
<button class="button">
-
It's a poor man's noscript, because if it were display:none it wouldn't ever be shown to users without JS, would it?
When I see something like this I question the author's sanity enough not to be sure.
I mean, yes, you're right, but who the hell knows what the author intended, and if it works as intended.
-
I don't think it's a question of sanity, I think it's a question of a lack of knowledge. There are a very large number of people who don't understand this stuff especially well, and copy/paste any old shit until they hammer it enough until it works. Like the WTF I posted last night of someone jamming a query into a view despite previously being told not to (and when I rebuked them politely I got bitched at for being a barrier to helping people FFS)
We happy few that actually understand can see what's wrong, why it's wrong and so on. And we're judgemental bastards for it.
I suspect it is what the author intended, because it's at the limit of their skill, and I suspect it even works as intended. I have seen this pattern elsewhere enough to recognise it.
-
We happy few that actually understand can see what's wrong, why it's wrong and so on. And we're judgemental bastards for it.
I'd be judgmental bastard to myself if I did this. And I frequently am. Because this is not a complex bit of C++ which requires knowledge about what gets allocated in which bit of memory and when it gets cleaned up. It's a matter of a single <insert_search_engine> search for "show element only if javascript disabled".
-
Most people do not hold themselves up to the sorts of standards we expect from ourselves. As long as it works, etc.
-
Just reminds me of the selected="selected" pattern⌠The guy probably had a button class that applied to other things such as <a> markups (I tried putting html entities in markdown, result was:
<a>
).In any case, ugly shit is ugly.
-
The guy probably had a button class that applied to other things such as <a> markups
Bootstrap does this, tough it uses a slightly more sane
btn
.
-
This is probably due to jQuery. Specifically jQuery_ui.
I'm not even joking.
-
I know you're not. Semantics (and good naming) are for people who don't use jQuery, a.k.a. bad web developers.
-
-
Just reminds me of the selected="selected" pattern⌠The guy probably had a button class that applied to other things such as <a> markups (I tried putting html entities in markdown, result was:
<a>
).In any case, ugly shit is ugly.
selected="selected" is about forcing HTML semantics into XML and having to find a solution to what was considered an edge case. Fortunately that shit has been abolished in HTML5.
-
Bullshit. selected="true" would even have been a better solution. Or selected="element_id_or_rank" to the <select> markup instead of the <option> markup. Having to comply with XML doesn't excuse every thing.
-
I didn't say it was a good solution. I'm just saying that it was about taking the original SGML/HTML attribute that didn't require a value and forcing it to have one.
The fact they picked a stupid one is another matter entirely. I first encountered this crap in 2001 and back then I never understood why
selected="true"
or evenchecked="yes"
was considered inferior toattribute="attribute"
.In hindsight, ISTR there was some justification (asspull?) about not confusing less clever parsers, because if you have
selected="true"
, logic dictates that you should also haveselected="false"
which non-XHTML aware parsers would treat under the old semantics and make it selected. By having only one valid value, you avoid that.
-
Not necessarily, actually - the GDS did some research into this: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/
Scroll down to "Why is there such a big difference?" and you'll see what I mean.
-
selected="true" would imply that selected="false" leaves the element unselected (which is not the case). selected="selected" is not necessarily better but I don't think it would have been a better solution.
-
When using selected="true" it feels right to write something like:
<cfloop array="#listOfComponents#" index="compName"> <option value="#compName#" selected="#currentComponentName eq compName#">#compName#</option> </cfloop>
instead of the correct
<cfloop array="#listOfComponents#" index="compName"> <option value="#compName#" <cfif currentComponentName eq compName >selected="true"</cfif>>#compName#</option> </cfloop>
Filed under: This code was literally right in front of me while I was reading this thread
-
Wait, are you saying having bad design from the start and ascending compatibility combined implies that things are bound to stay bad?
Now that's breaking news!
-
Because breaking compatibility with many, many clients is a good idea now?
-
Actually yes. A feature should be supported, be marked obsolete and give a warning for some time, and if you haven't fixed it by the time it was removed, well tough for you.
-
I think you have grave misunderstandings about how browsers work and what their idea of 'to specification' is.
-
Buttons are supremely annoying in that they behave differently from links css-wise, and that when in IE you press enter, it automatically clicks the first button it sees in certain circumstances. An a element is often much more convenient than a button.
Also they look different on different platforms.
-
Also they look different on different platforms.
Not when you jQuery-ui them, unless I miss the purpose of jQuery-ui
-
-
<a class="button">
"Why isn't this actually a button?"
I don't see the problem with this.
This is evidenced by the fact that I do this, and have it in my default styles for every project.
Sometimes you need a link that doesn't look like a link but is clickable nonetheless. No biggie. My panties are straightened and unwedged.
-
More importantly, why is one of these a button and the other a link?
Because "screw you!" if you want to start a private message in a new tab?
Filed under: [consistently inconsistent]()
-
Yeah that makes no sense.
-
-
-
More importantly, why is one of these a button and the other a link?
<img src="/uploads/default/5067/53e5fa4a633332e9.png" width="272" height="36">
Because "screw you!" if you want to start a private message in a new tab?
<hr><small>Filed under: consistently inconsistent</small><!-- CC @Yamikuronue, does this work? -->
The same reason that Reply is a button and Cancel is a link?
JWITW
-
The same reason that Reply is a button and Cancel is a link?
That makes sense. See, "Reply" is a button to submit the form. "cancel" is the link to the previous pag...
No, wait, never mind...
-
More importantly, why is one of these a button and the other a link?
Because "screw you!" if you want to start a private message in a new tab?
Why does it matter? They both go to the same place... which has the first button on it.
-
But that's one extra click. Ain't nobody got time for that!
-
selected="selected" is about forcing HTML semantics into XML and having to find a solution to what was considered an edge case. Fortunately that shit has been abolished in HTML5.
Unless you use the XML serialisation, XHTML5
-
Unless you use the XML serialisation, XHTML5
Whoever that XHTML5 was a good idea requires being forced to kneel on rice whilst holding a penny to the wall with their nose, to contemplate what they've done.
-
Whoever that XHTML5 was a good idea requires being forced to kneel on rice whilst holding a penny to the wall with their nose, to contemplate what they've done.
That... is a really weird punishment
-
He's a PHPÂ guy.
-
You have no idea.
-
That... is a really weird punishment
And yet it feels appropriate.
-
-
-
E for effort, I got a reply notice but no mention
-
For Science!
@Yamikuronue, did you get both a reply and a mention?
-
@Yamikuronue, did you get both a reply and a mention?
Isn't the screenshot visible in your client?
-
No, I don't think Yamikuronue managed to take a time-travelling screenshot.
-
Oh - see what you mean - I doubt it - from experience, if you get an @mention in a thread you'd normally get a reply for, the reply gets suppressed in favour of a mention - I'd received reply notifications on the "The topic about 'The topic about "The topic ideas topic"'" topic below:
-
the reply gets suppressed in favour of a mention
I'd think a reply is more important than a mention and suppress the other way around, but oh well, I'm not Jeff.