Understanding HTML



  • Right, so this isn't a huge WTF, but it's been annoying me all day, so I thought I'd rant here were people might understand. I'm working on a web application where the HTML has been provided to us by a web design company. Here is a snippet of code:

    <span class="header_blue">Some Text</span><br /><br />

    This really demonstrates a fundamental lack of understanding, that I wouldn't expect from a company whoes primary function, involves the web.

    Before the "this isn't a WTF" crowd jump in, let me enumerate some of the problems here.

    1. Why is it using a span? It's clearly meant to be a header, so it should be using one of h1, h2, h3 etc. Using a span here is terrible for search engine optimisation since machines can't take a hint about what an element is from the class name, the header text will appear to be part of the text both above and below it. Similar problems will occur for screen readers and the like.
    2. Every one of these header-spans has a line break after it. If they'd just used a block level element (like h1, h2 etc.) this would be unneccessary.
    3. Sometimes there are multiple line breaks. this should be specified in the style sheet as margin, the spacing between elements, I would have thought, is somethign that is coupled to the style of the page, not the content.
    4. The class name is "header_blue". Gnnarght! That name describes the style, not the meaning. What happens when marketing one day turn around and say that they want an orange colour scheme? You either change the CSS (like you should) and end up having a class called "header_blue" that makes the text orange, or you make a new class, and end up having to change all of the HTML, defeating the purpose of CSS.

    Thank you for listening to my rant.

    Carry on.



  • Br tags do not require self-closing in HTML, is this supposed to be XHTML, or is it another WTF from what they wrote?



  • TRWTF is that it is XHTML.   Anyway, I only disagree on one point...

    @SpoonMeiser said:

    Sometimes there are multiple line breaks. this should be specified in the style sheet as margin, the spacing between elements, I would have thought, is somethign that is coupled to the style of the page, not the content.

    I think line breaks can also be part of the content.  Regardless, CSS and HTML are such a hideous combination of fuckery that questions like this are essentially unresolvable.



  • @SpoonMeiser said:

    Before the "this isn't a WTF" crowd jump in, let me enumerate some of the problems here. (...)

    Incompetence != WTF.



  • @morbiuswilters said:

    I think line breaks can also be part of the content.

     

    Yes, they can.

    But, not in this case.



  • @pqueue said:

    Incompetence != WTF.

    I'm pretty sure it's part of the definition of WTF. 



  • @Lazy-lump said:

    Br tags do not require self-closing in HTML, is this supposed to be XHTML, or is it another WTF from what they wrote?
     

    Some people think if they use the doctype for XHTML and it validates then their code is perfect, even if they make utterly moronic decisions like the above.

    I've seen a lot of stuff like that before, typically when someone says "I know HTML", I take it to mean that they know how to do basic formatting tags, and not much else. In a way it's like saying you're a C++ expert but all you can do is cout.



  • @SpoonMeiser said:

    @morbiuswilters said:

    I think line breaks can also be part of the content.

     

    Yes, they can.

    But, not in this case.

    Obviously the first line break is just a hack to deal with the span garbage.  But why wouldn't the second line break be cool?  It's after a "header". 



  • @morbiuswilters said:

    @pqueue said:

    Incompetence != WTF.

    I'm pretty sure it's part of the definition of WTF. 

    It's not all there is to a WTF, though.


  • @morbiuswilters said:

    Obviously the first line break is just a hack to deal with the span garbage.  But why wouldn't the second line break be cool?  It's after a "header". 

     

    Because the only purpuse of it is to alter the spacing between the text and the header. That isn't content, that's style.

    Line breaks should be used when you don't want things to appear on the same line, not to specify the spacing between elements. They should have a margin-bottom in the stylesheet instead.



  • @SpoonMeiser said:

    Because the only purpuse of it is to alter the spacing between the text and the header. That isn't content, that's style.

    Line breaks should be used when you don't want things to appear on the same line, not to specify the spacing between elements. They should have a margin-bottom in the stylesheet instead.

    Eh, I disagree.  Layout can be part of the content if it provides context. 



  • @SpoonMeiser said:

    Because the only purpuse of it is to alter the spacing between the text and the header. That isn't content, that's style.

    Line breaks should be used when you don't want things to appear on the same line, not to specify the spacing between elements. They should have a margin-bottom in the stylesheet instead.

     

    Agree on all counts. 

    I've been slowly cleaning up a suite of similar sites that I have inherited.  Of course, these sites also use lots of blank "spacer.gif" images to handle padding, spacing and/or margins. Lots of fun.  It also uses the same "class='head1" stuff, and completely ignores the availability of H1-H6 tags. Clean up is slow but it is worth it, the HTML /CSS is slowly getting much smaller and much more manageable.

    But I also agree with Morbius in that HTML/CSS is far from perfect,,,.  There is absolutely no way to avoid formatting in your HTML markup; a large part of the issue is that the order in which your HTML is written and the way you nest elements (especially DIVS) control large parts of how the CSS is able to format it.


     



  • @morbiuswilters said:

    TRWTF is that it is XHTML.   Anyway, I only disagree on one point...

    @SpoonMeiser said:

    Sometimes there are multiple line breaks. this should be specified in the style sheet as margin, the spacing between elements, I would have thought, is somethign that is coupled to the style of the page, not the content.

    I think line breaks can also be part of the content.  Regardless, CSS and HTML are such a hideous combination of fuckery that questions like this are essentially unresolvable.

     

    Of course they can be part of the content, but the fact is, the OP is demontstrating how they're being used for layout to generate spacing.  This is bad because the gap will increase and decrease as line heights change, like when someone increases their font size in the browser, so the distance is unpredictable.  The way to accomplish scalable margins is to use margins with the em unit type, since they will be unaffected by line heights.

    And your "this is horrible and terrible and crappy" rhetoric gives me the impression that you tried to make yourself a web page, couldn't figure out how to use floats, and gave up claiming that "its CSS and HTML that suck, not me". 



  • @Soviut said:

    Of course they can be part of the content, but the fact is, the OP is demontstrating how they're being used for layout to generate spacing.  This is bad because the gap will increase and decrease as line heights change, like when someone increases their font size in the browser, so the distance is unpredictable.

    I would think, if anything, this is preferable.  If the spacing remains the same while the font size increases, the separation between header and body is lost.  This is a part of the content because it defines a clear boundary.  Eh, I'm tired of arguing it, though.  There is nothing more tedious than HTML Nazis.

     

    @Soviut said:

    And your "this is horrible and terrible and crappy" rhetoric gives me the impression that you tried to make yourself a web page, couldn't figure out how to use floats, and gave up claiming that "its CSS and HTML that suck, not me".

    I'm sure I've done much more with HTML and CSS than you will ever have a chance to in your life.  They are horrible standards with conflicting goals and a lack of necessary features.  The goals of lightweight semantic markup are generally unachievable and CSS provides very limited control of formatting without resorting to hideous, counter-intuitive and brittle hacks.  Hopefully the whole thing will be replace by something like Flash or Silverlight for all but the most basic web pages.



  • @morbiuswilters said:

    Hopefully the whole thing will be replace by something like Flash or Silverlight for all but the most basic web pages.
     

    I can understand your disdain of HTML and CSS, but they're the best we've got. Flash (dunno about Silverlight) in its current form is horrible, counterintuitive inaccessible crap and would be a *huge* step backwards.



  • @anthetos said:

    @morbiuswilters said:

    Hopefully the whole thing will be replace by something like Flash or Silverlight for all but the most basic web pages.
     

    I can understand your disdain of HTML and CSS, but they're the best we've got. Flash (dunno about Silverlight) in its current form is horrible, counterintuitive inaccessible crap and would be a *huge* step backwards.

    Hey, imagine the possibilities with a flash-based Community Server. We'd have much more to talk about in this forum!


  • @morbiuswilters said:

    I would think, if anything, this is preferable.  If the spacing remains the same while the font size increases, the separation between header and body is lost.  This is a part of the content because it defines a clear boundary.  Eh, I'm tired of arguing it, though.  There is nothing more tedious than HTML Nazis.

     

    Nice example of Godwins Law there.

    I'd agree that you generally want spacing to stay proportunate to font size. That's why you have two units that are proportunate to font size: em which is proportunate to font width, and ex which is proportunate to font height.

    I don't think Soviut really got to the root of why using br for spacing is bad.



  • @morbiuswilters said:

    If the spacing remains the same while the font size increases, the separation between header and body is lost.  This is a part of the content because it defines a clear boundary.
     

    h1 {
       margin-bottom: 1em;
    }

    The space between a header and its text is a purely visual separation, and as such should not be marked up in HTML. The boundary you describe is defined by the presence of a H1 and its subsequent P, and it usually manifests itself in visual browsers, through CSS or the browser's default styles, as a bit of space. But anything goes, really, as long there's a visual distinction to set it apart from body text.

    In less words: putting a BR there is nonsense.

    But at least you're applying the is it content? way of thinking, which is more than I can say for the people who just gave me some of their "html+css". Classnames of the form "Blue2" abound. Sigh.

    Your criticism of HTML+CSS+JS is justified, though. It's all cobbled together with only a semblance of an idea of what it should do. I would like to note, though, that the only "hacks" I've ever used are the underscore/star parsing bugs in IE, which I find the least offensive method of solving cross-browser bullshit. All the other junk can be avoided with a little more insight into how stuff works.



  • @dhromed said:

    In less words: putting a BR there is nonsense.

    I'm tired of this argument.  HTML/CSS Nazis are dreadfully boring and I usually end up wanting to slit my wrists after talking to them for a few minutes.  I still consider it a valid use of a br.  What would the point of br even be if not for scenarios like this?

     

    @dhromed said:

    I would like to note, though, that the only "hacks" I've ever used are the underscore/star parsing bugs in IE, which I find the least offensive method of solving cross-browser bullshit.

    Which is worthless when new browsers come out and is generally ugly.  Generally it is better to do capability testing in JS or establish the capabilities based on UA string and override the default styles with some inline CSS for broken browsers.

     

    @dhromed said:

    All the other junk can be avoided with a little more insight into how stuff works.

    I've encountered many problems across many different browsers that require tweaks and hacks.  Some of the issues were browser-specific (DIAF Safari) and some were simply because the CSS standard had no way to accomplish what I needed to do. 



  •  All of this is making me want to go and create an entire page using just tables in the hope that somebody's head will explode in fury over it.



  • @morbiuswilters said:

    Generally it is better to do capability testing in JS or establish the capabilities based on UA string and override the default styles with some inline CSS for broken browsers.

    I'm going to have to disagree with this solution.

    Capability testing in JS will only work if an end-user has javascript enabled, which makes it too unreliable. Even then, using the UA string for identification is generally considered bad practice, because it can be changed by the end-user. As such it is, again, unreliable.

    Imho a much better solution to fix IE is to use conditional comments to serve specialized style sheets to different (down to the minor version number, iirc) versions of IE.



  • @Ragnax said:

    Capability testing in JS will only work if an end-user has javascript enabled, which makes it too unreliable.

    If JS is disabled, I really don't care if the site doesn't work for them.  I will display a "turn JS on" message.

     

    @Ragnax said:

    Even then, using the UA string for identification is generally considered bad practice, because it can be changed by the end-user.

    Who changes their UA string?  Oh, techies.  If they change their Firefox UA to IE and are shocked to discover the software behaving differently, they need to be smacked upside the head.



  • @morbiuswilters said:

    If JS is disabled, I really don't care if the site doesn't work for them.  I will display a "turn JS on" message.
     

    Why don't you just use a conditional HTML comment to apply a CSS for IE?

    As someone who writes standards compliant pages and browses most sites with JavaScript off, blatant disregard for standards is worse than standards Nazism.



  • @anthetos said:

    As someone who writes standards compliant pages

    What does this have to do with anything?  The standards are a mess and so is support of them.  How does you writing standards compliant pages mean that I should too?

     

    @anthetos said:

    ...browses most sites with JavaScript off...

    Maybe you could join the rest of us in this century?  You deliberately cripple your browser and then act like everyone should change to accomodate you?  Have fun with that. 



  • @morbiuswilters said:

    The standards are a mess and so is support of them.
     

    They're the best we've got.

    @morbiuswilters said:

    Maybe you could join the rest of us in this century?
     

    This is coming from someone who wants to return the dark ages of UA sniffing and exploitation of browser-specific behavior? How ironic.

    @morbiuswilters said:

    You deliberately cripple your browser and then act like everyone should change to accomodate you?  Have fun with that. 

    No, I deliberately choose not to run untrusted scripting that changes the behavior that I expect from my user agent.



  • @anthetos said:

    They're the best we've got.

    True, but that doesn't make them any less useless.

     

    @anthetos said:

    This is coming from someone who wants to return the dark ages of UA sniffing and exploitation of browser-specific behavior? How ironic.

    UA sniffing works quite well at determining browser capabilities.  I prefer using JS to determine capabilities where possible, but UA sniffing is pretty good.  Hacks that require exploiting parsing errors in certain versions of IE are just a mess and conditional comments are useless with FF and Safari.

     

    @anthetos said:

    No, I deliberately choose not to run untrusted scripting that changes the behavior that I expect from my user agent.

    Then this is your problem, not mine.  If you want the functionality, enable scripting.  Otherwise, get off of my site.  We're not talking about viewing a blog here, we're talking about more sophisticated sites (like the one you are posting to right now!) and applications.  Trying to support paranoid and delusional users who refuse to use modern technology is a waste of my time.



  • @morbiuswilters said:

    Maybe you could join the rest of us in this century?  You deliberately cripple your browser and then act like everyone should change to accomodate you?  Have fun with that. 

    Except for the fact that certain browsers mean for handicapped people don't run javascript, also not all mobile devices support it either.



  • @morbiuswilters said:

    Then this is your problem, not mine.  If you want the functionality, enable scripting.  Otherwise, get off of my site.  We're not talking about viewing a blog here, we're talking about more sophisticated sites (like the one you are posting to right now!) and applications.  Trying to support paranoid and delusional users who refuse to use modern technology is a waste of my time.
     

     Agree. Doesn't it come to a point where you have to consider the costs (time mostly) involved in trying to cater to .001 of your expected visitor base? You can spend hours/days/etc. hacking around to get the page(s) to look and work identical on every single browser ever produced, but all you've really done (other than giving yourself a Standards Gold Star ™) is waste your time and probably the client's money.



  • @Lingerance said:

    Except for the fact that certain browsers mean for handicapped people don't run javascript, also not all mobile devices support it either.

    We're talking about things more complicated than simple text here.  People with disabilities are incapable of doing certain things and there's only so far you can go to cater to them.  Also, my microwave is no good for barbequeing a rack of ribs so I suppose that's the slaughterhouse's fault.



  • @TheTXI said:

    Doesn't it come to a point where you have to consider the costs (time mostly) involved in trying to cater to .001 of your expected visitor base? You can spend hours/days/etc. hacking around to get the page(s) to look and work identical on every single browser ever produced, but all you've really done (other than giving yourself a Standards Gold Star ™) is waste your time and probably the client's money.

    Get out of here with your reasonable attitude towards software development shaped by years of real world experience and an appreciation for time and budget constraints!  Begone! 



  • @TheTXI said:

    Agree. Doesn't it come to a point where you have to consider the costs (time mostly) involved in trying to cater to .001 of your expected visitor base? You can spend hours/days/etc. hacking around to get the page(s) to look and work identical on every single browser ever produced, but all you've really done (other than giving yourself a Standards Gold Star ™) is waste your time and probably the client's money.
     

     Or you can just use the standards and have it work correctly on everything but IE quickly...



  • @Bigcheese said:

     Or you can just use the standards and have it work correctly on everything but IE quickly...

    Are you reading any of this?  Read more of this.  Stop not reading before you post. 



  • @morbiuswilters said:

    @Ragnax said:
    Capability testing in JS will only work if an end-user has javascript enabled, which makes it too unreliable.
    If JS is disabled, I really don't care if the site doesn't work for them.  I will display a "turn JS on" message.

    And the users it will be shown to will likely proceed to surf elsewhere. Demanding javascript is enabled is fine and dandy for trusted web-applications, but not for every public website in the world.

    @morbiuswilters said:

    @Ragnax said:
    Even then, using the UA string for identification is generally considered bad practice, because it can be changed by the end-user.
    Who changes their UA string?  Oh, techies.  If they change their Firefox UA to IE and are shocked to discover the software behaving differently, they need to be smacked upside the head.

    @morbiuswilters said:

    Obviously it is because you are using Linux.  If your OS had a desktop market share larger than 1% it might be weird for them to not take you into account.  Otherwise, [b]just change your UA string[/b]. ([url=http://forums.thedailywtf.com/forums/p/9674/177260.aspx#177260]Cross-thread quoted[/url])

    ¬_¬



  • @Ragnax said:

    @morbiuswilters said:
    @Ragnax said:
    Capability testing in JS will only work if an end-user has javascript enabled, which makes it too unreliable.
    If JS is disabled, I really don't care if the site doesn't work for them.  I will display a "turn JS on" message.
    And the users it will be shown to will likely proceed to surf elsewhere. Demanding javascript is enabled is fine and dandy for trusted web-applications, but not for every public website in the world.
    You're forgetting or ignoring the sad fact of life that any nontrivial site has got to work around dozens of browser glitches, and using JS / UA really is the only way around it that wouldn't make your head implode. Not elegant, but what can you do, really?

    @Ragnax said:

    @morbiuswilters said:
    @Ragnax said:
    Even then, using the UA string for identification is generally considered bad practice, because it can be changed by the end-user.
    Who changes their UA string?  Oh, techies.  If they change their Firefox UA to IE and are shocked to discover the software behaving differently, they need to be smacked upside the head.
    @morbiuswilters said:
    Obviously it is because you are using Linux.  If your OS had a desktop market share larger than 1% it might be weird for them to not take you into account.  Otherwise, just change your UA string. (Cross-thread quoted)
    ¬_¬
    There's a difference here. Exhibit A concerns itself with making a cross-browser site. Exhibit B is working your way into a site that uses UA-banning, as opposed to UA-adjusting.



  • @Ragnax said:

    And the users it will be shown to will likely proceed to surf elsewhere. Demanding javascript is enabled is fine and dandy for trusted web-applications, but not for every public website in the world.

    I'm not talking about extremely simple pages like a blog listing or a news site.  Additionally, the loss of users who don't have or will not run JS is probably unnoticeable.

     

    @Ragnax said:

    @morbiuswilters said:
    @Ragnax said:
    Even then, using the UA string for identification is generally considered bad practice, because it can be changed by the end-user.
    Who changes their UA string?  Oh, techies.  If they change their Firefox UA to IE and are shocked to discover the software behaving differently, they need to be smacked upside the head.

    @morbiuswilters said:

    Obviously it is because you are using Linux.  If your OS had a desktop market share larger than 1% it might be weird for them to not take you into account.  Otherwise, just change your UA string. (Cross-thread quoted)

    ¬_¬

    Yeah, two completely different points there.  Using UA checking is a pretty decent way to determine compatibility with a browser.  Changing your UA is a good way to get into sites that block based on it, but of course there may be quirks here and there.  The blocking the second quote is referring to is based on OS, not browser.  Changing your UA to FF for Windows would let you in just fine, but it shouldn't come as a shock if some Windows-only functionality doesn't work.

     

    As a web developer, I always take 3 browser/OS combinations into account: IE on Windows, Safari on OS X and FF on Windows, in that order.  Generally, it's not terribly difficult to design fast, highly-interactive apps that will run on all three with minimal tweaking for the different browsers.  Additionally, FF on OS X and Linux will almost always work with any site designed for FF on Windows, so those are feebies.  Safari on Windows is pretty close to the OS X version, but it's got a lot of quirks and bugs of its own and no Windows user is using it as their primary browser.  Opera generally isn't even worth considering due do its numerous incompatibilities, quirks and the fact that nobody users it, but it also has a built-in UA switcher so if Opera users feel lucky they can give something like Windows/FF a shot and see if Opera is compatible enough to not choke.  Otherwise, they will most likely have IE, FF or Safai available as a backup option.



  • @morbiuswilters said:

    @Ragnax said:

    And the users it will be shown to will likely proceed to surf elsewhere. Demanding javascript is enabled is fine and dandy for trusted web-applications, but not for every public website in the world.

    I'm not talking about extremely simple pages like a blog listing or a news site.  Additionally, the loss of users who don't have or will not run JS is probably unnoticeable.

    You're right - users with any computer security awareness are few and far between. On the other hand, it looks like I'll never be using your websites. TYVM. HTH. HAND.



  • Why is it that I keep reading that disabiling Javascript is somehow
    a good and secure thing that only a few knowledgeable experts know
    about? 

    Why would anyone disable javascript? This is a legit
    question. I just don't quite get it. To me it seems on the paranoid
    side, but if I'm wrong, please enlighten me.

    On any case, I'm lucky that most of my clients (and/or bosses) don't care about people with disabled javascript or without flash, or still using IE5. Otherwise my job would be a lot less fun. 



  • @fatdog said:

    Why is it that I keep reading that disabiling Javascript is somehow a good and secure thing that only a few knowledgeable experts know about?

    Any code from the Internet that is executed could become a potential vector for attack.  However, disabling it completely is sort of like throwing the baby out with the bathwater.  Personally I used NoScript with an extensive whitelist.  My primary reason is to stop obnoxious sites that open dozens of popups or do other crazy bullshit.  However, I'm perfectly willing to enable JS on all the sites I actually use.  For me it is more tha annoyance factor of certain JS that is used by unethical sites, rather than a concern over security. 



  • @morbiuswilters said:

    For me it is more tha annoyance factor of certain JS that is used by unethical sites, rather than a concern over security. 

     

     Same here... once I started seeing ads infected with javascript exploits, I adopted NoScript with open arms. The concept of having everything in the blacklist by default then adding things I use to the whitelist used to sound annoying to me, but it turns out it really isn't.



  • @fatdog said:

    Why is it that I keep reading that disabiling Javascript is somehow a good and secure thing that only a few knowledgeable experts know about? 

    Why would anyone disable javascript? This is a legit question. I just don't quite get it. To me it seems on the paranoid side, but if I'm wrong, please enlighten me.

    On any case, I'm lucky that most of my clients (and/or bosses) don't care about people with disabled javascript or without flash, or still using IE5. Otherwise my job would be a lot less fun. 

     

     There's an inherent security issue with allowing an unknown, untrusted site to execute code on your machine. Granted, it's not like this is as huge an issue as some people make it, but if you think as an attacker it becomes pretty obvious why that would be a potential line of attack. Letting people run stuff on your machine is inherently less secure than letting them run it on their machine and sending you the results.



  • @aristos_achaion said:

    There's an inherent security issue with allowing an unknown, untrusted site to execute code on your machine. Granted, it's not like this is as huge an issue as some people make it, but if you think as an attacker it becomes pretty obvious why that would be a potential line of attack. Letting people run stuff on your machine is inherently less secure than letting them run it on their machine and sending you the results.

    Also, the JS security model is a pretty big WTF.  Most of this wouldn't be an issue if we were using a scripting language designed from the ground-up to use crypto signatures from trusted CAs.  Not that JS couldn't do this, but it's just not how things evolved. 



  • @aristos_achaion said:

    There's an inherent security issue with allowing an unknown, untrusted site to execute code on your machine. Granted, it's not like this is as huge an issue as some people make it
     

    Wrong, this is actually a VERY huge issue in an age when an increasing number of people do an increasingly large part of their financial transactions online. Learn more here.

     



  • @morbiuswilters said:

    Also, the JS security model is a pretty big WTF.  Most of this wouldn't be an issue if we were using a scripting language designed from the ground-up to use crypto signatures from trusted CAs.  Not that JS couldn't do this, but it's just not how things evolved. 

    Funny thing... Java has this built-in since the Applet days. IO functions like "read from disk", "write to disk", "open up TCP connection to this.crappy.site.com" are denied by default, unless the .jar is signed by a trusted CA. If it isn't, it will only allow these operations if you explicitly give the applet permission.

    Too bad JS didn't follow on this; but then again, I think it was those ActiveX controls the ones that actually began the "attack vector" frenzy.



  • @danixdefcon5 said:

    Funny thing... Java has this built-in since the Applet days. IO functions like "read from disk", "write to disk", "open up TCP connection to this.crappy.site.com" are denied by default, unless the .jar is signed by a trusted CA. If it isn't, it will only allow these operations if you explicitly give the applet permission.

    Yes, Java had a better security model.

     

    @danixdefcon5 said:

    Too bad JS didn't follow on this; but then again, I think it was those ActiveX controls the ones that actually began the "attack vector" frenzy.

    JS security has enough problems to count as a WTF on its own without needing to add in ActiveX (which is dead anyway).



  • @SpoonMeiser said:

    The class name is "header_blue". Gnnarght! That name describes the style, not the meaning. What happens when marketing one day turn around and say that they want an orange colour scheme? You either change the CSS (like you should) and end up having a class called "header_blue" that makes the text orange, or you make a new class, and end up having to change all of the HTML, defeating the purpose of CSS.

     

    The OSRWTF (other somewhat-related WTF) is that MySpace did this in their profile pages for years (and they probably still do). SPANs and DIVs with classes like "orange12" and "blue10" have been common throughout their non-validating mess of what resembles neither proper HTML or XHTML.

    Actually, I'm pretty sure they're not DIVs. They preferred to use tables to do their content alignment and layout.



  • @blkballoon925 said:

    The OSRWTF (other somewhat-related WTF) is that MySpace did this in their profile pages for years (and they probably still do). SPANs and DIVs with classes like "orange12" and "blue10" have been common throughout their non-validating mess of what resembles neither proper HTML or XHTML.

    Actually, I'm pretty sure they're not DIVs. They preferred to use tables to do their content alignment and layout.

    And yet it still displays just fine.  I mean, it looks godawful, but that's what most people on MySpace want their pages to look like.  The company is also very highly valued.  I think that is proof enough that while standards can be a helpful starting point, at the end of the day what matters is the result.  People are not paying us to adhere to standards, they are paying us to make their lives easier, happier, more connected and more entertaining.  Standards have a purpose, but I think the most important thing you can learn about a standard is when it is okay to bend or break it.



  • That is true, and I have to agree with you to an extent. However, standards are also in place so that (when observed) we aren't forced to use something as awful as IE to browse the web if we should choose not to, and something else like Firefox or Opera is able to understand and display the same pages in the way the author intended them to look. Now, when standards hinder the ability to do something, it can be beneficial (and sometimes necessary) to break the rules. But IMO MySpace isn't that special. Facebook built a much better (and still valuable) product on better written (although not completely valid) code. Unfortunately, many web developers have chosen to ignore the second half of Jon Postel's philosophy to "be liberal in what you accept, and conservative in what you do." And while I agree with your point, I have to say if all the XHTML parsers and web developers would adhere closer to standard, we wouldn't end up with WTFs like http://forums.thedailywtf.com/forums/t/9674.aspx?PageIndex=1 or http://thedailywtf.com/Articles/Followup-Redirection-with-Smoke-And--Smoking.aspx

    As for those pages that have IMG tags missing an ALT property, or the ones that use nested tables to arrange content...just ask the visually-impaired who use screen readers how they feel about those websites.

    As a sidenote, TRWTF (UI related) is that I pushed a CTRL+ key combination by mistake in an attempt to cut and paste and now everything in the rich text field is right justified, but there are no toolbar or context menu options to change this setting.



  • Even the most well-defined and well-documented standard can't prevent incompetency. Plus, I'd have to agree with morbiuswilters. HTML was fine when all backgrounds were white, all text were black, and all hyperlinks were either red, blue, or purple. Today, not so much.

    HTML isn't the only evil on the web though; most of us will know that POST vars and the browser's back button just don't work together.

    Most web apps I've come across or written have hack upon hack just to mimic the 'desktop' environment clients love so much. They hate 'flashy screens' when loading a new page in IE, they can't stand waiting times > 1 second, and nice colors seem more important than a working, well-written product.

    You could say TRWTF are the clients, but fact is, the entire set-up, from protocol to mark-up, just fails to deliver what both clients and developers have been hoping for for years.



  • @Duroth said:

    HTML isn't the only evil on the web though; most of us will know that POST vars and the browser's back button just don't work together.
    Those are easy to swallow though so they don't appear in the history.

    POST -> file.lang then file.lang uses header('Location: transaction_complete.php')

    file.lang doesn't appear in the history. This is what PHPnuke did on the administration pages (one of the few things I actually liked about it).


Log in to reply