Why should I close my HTML tags?



  • http://sewingandembroiderywarehouse.com/embtrb.htm

    This is an amazing piece of WTF-ery sure to make your DOM viewer assplode.

    It probably works in IE 5.



  • <META name="generator" content="Microsoft FrontPage 5.0">


  • From the source:

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
    ..
    <META name="generator" content="Microsoft FrontPage 5.0">

    That site reminds me of another (don't have the link)... some cult leader ranting about the evils within American socuety were going to cause the end of the world - and the font grew larger as you scrolled down, giving the impression he was screaming louder as time progressed.

     

     

     



  • Well, it certainly looks 'artsy'... and the designer probably thought of the poor visually impaired users. That's what i call thinking... [/sarcasm off]

    No seriously, on what drugs was the guy/gal which created this piece of ....



  • @lizardfoot said:

    It probably works in IE 5.
    IE 5, 5.5, 6, 7, 8, 9 all work fine. Perhaps also 10 but I don't have it to test.

    To put it simply, IE copes with this invalid markup:
    <td><font></td>
    It would appear that other browsers (and HTML5 parsing?) do not cope with it - they keep the FONT element open, while IE will auto-close it when it reaches the closing tag for the parent TD.



  • @keigezellig said:

    No seriously, on what drugs was the guy/gal which created this piece of ....
     

    Given it was created with FrontPage, it's a good bet that it was viewed in IE only and the web developer author confused results with success.



  •  Anybody still using the <font> tag should be taken out and shot anyway.



  • @TarquinWJ said:

    IE 5, 5.5, 6, 7, 8, 9 all work fine. Perhaps also 10 but I don't have it to test.
    IE 10 displays it like Opera, Firefox and Chrome (and unlike IE9).



  •  in FF the text gets bigger the more you scroll down. Arty.



  • @Cassidy said:

    That site reminds me of another (don't have the link)... some cult leader ranting about the evils within American socuety were going to cause the end of the world - and the font grew larger as you scrolled down, giving the impression he was screaming louder as time progressed.


    What, Timecube?



  • WTF is this?

    "</font color>"

    This is the first time in 15 years of web development that I've seen this.

    Thank $deity MS killed FrontPage.



  • @JimLahey said:

     in FF the text gets bigger the more you scroll down. Arty.

    It's not getting bigger.

    It's getting closer.

    HTML5, bitches!



  • @Quietust said:

    What, Timecube?
     

    Yesssssss! That's the fellah!

    @Signature Guy said:

    I agree with whatever Quietust just posted above.
     

    Ditto.

    @ubersoldat said:

    "</font color>" This is the first time in 15 years of web development that I've seen this.
     

    Sadly, I've encountered it a great deal. Usually from people learning HTML who don't understand attributes don't need to be closed (understandable). But from some terrible coding, too (despicible).



  • IE9 renders it OK in quirks mode, IE7 standards and IE9 standards and compatibility modes. IE8 Standards mode looks ridiculous...?

    @Severity One said:

     Anybody still using the <font> tag should be taken out and shot anyway.

    Some of the worst HTML I've ever seen contained FONT tags with style attributes...



  • @Cassidy said:

    @Quietust said:

    What, Timecube?
     

    Yesssssss! That's the fellah!

    Oh, I know that guy! I've always felt sorry for him, he's obviously a schizophrenic or something like that. His site, though, *wow*.



  • @Cassidy said:

    From the source:

    ”." class="error doctype"><<font color="red">!</font>DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
    ..
    <META name="generator" content="Microsoft FrontPage 5.0">

     

    Do I read that correctly that FrontPage generates NOT HTML? (The "!" is what I'm pointing at.)

     



  • No. Quoting failure on my part. It should read:

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">

    (i.e. HTML3.2 with BIG SHOUTY TAGS)

     Edit: No, it's TinyMCE listening to shoulder aliens and inserting things where it shouldn't

    Edit2: I mean unnecessary HTML, not anal probes.

     



  • @flop said:

    Do I read that correctly that FrontPage generates NOT HTML? (The "!" is what I'm pointing at.)
     

    Do I read correctly that this is your very first time seeing a DTD?



  •  Works perfectly fine in Pale Moon 19, AKA forked FF19, provided the text becoming as large as possible is normal.



  •  Works fine in FF on a Mac too, according to SWMBO.



  • @dhromed said:

    @flop said:
    Do I read that correctly that FrontPage generates NOT HTML? (The "!" is what I'm pointing at.)
    Do I read correctly that this is your very first time seeing a DTD?

    The whole DTD system is indeed a WTF (HTML5 mostly trashed it), but never having seen one before? Double-WTF.



  • @Severity One said:

    Anybody still using the <font> tag should be taken out and shot anyway.
     

    Is there a newer and better way to render text with arbitrary colors, without using <font>?  (Serious question,
    not trying to troll anyone here.)

     



  • @Mason Wheeler said:

    Is there a newer and better way to render text with arbitrary colors, without using <font>?  (Serious question,
    not trying to troll anyone here.)

    SPAN with a style attribute, if you're not a militant HTML developer. (Of course if you want to change the color of an entire paragraph, you'd put the style attribute in the P tag; or for a list you'd put it in the UL tag, etc. SPAN marks an arbitrary span of text.)

    CREATE A CSS STYLE OMG OMG OMG YOU CAN'T DO INLINE STYLES YOU EVIL COMMIE BASTARD I KILL YOU! if you are a militant HTML developer. You can chase them off with a Comic Sans font card.



  • @Mason Wheeler said:

    @Severity One said:

    Anybody still using the <font> tag should be taken out and shot anyway.
     

    Is there a newer and better way to render text with arbitrary colors, without using <font>?  (Serious question,
    not trying to troll anyone here.)

     

    Just in case you really are not trying to troll anyone: https://en.wikipedia.org/wiki/Cascading_Style_Sheets

     



  • @toon said:

    @Mason Wheeler said:

    @Severity One said:

    Anybody still using the <font> tag should be taken out and shot anyway.
     

    Is there a newer and better way to render text with arbitrary colors, without using <font>?  (Serious question,
    not trying to troll anyone here.)

     

    Just in case you really are not trying to troll anyone: https://en.wikipedia.org/wiki/Cascading_Style_Sheets

     

    Oh, I know all about cascading style sheets.  I also know that they're static and pre-built.  That's why I asked about arbitrary colors, which you can't exactly do in a stylesheet unless you have your server dynamically generating CSS files on the fly, which ruins the entire point of using a separate CSS file in the first place. (Not to mention the horrendous degree of extra complexity that actually implementing such a generation scheme would add to your server...)

     



  • @blakeyrat said:

    @Mason Wheeler said:
    Is there a newer and better way to render text with arbitrary colors, without using <font>?  (Serious question,
    not trying to troll anyone here.)

    SPAN with a style attribute, if you're not a militant HTML developer. (Of course if you want to change the color of an entire paragraph, you'd put the style attribute in the P tag; or for a list you'd put it in the UL tag, etc. SPAN marks an arbitrary span of text.)

     

    All right.  And what is the rationale for saying that <span style="color:#ABCDEF;">  is better/more correct/preferable to saying "<font color="#ABCDEF">, which is more compact and semantically simpler, and therefore easier to read?  (As a programmer, I value code readability and clarity above most other virtues.)

    Are there any actual benefits to doing it that way, or is this just HTML zealotry?

     



  • @Mason Wheeler said:

    All right. And what is the rationale for saying that <span style="color:#ABCDEF;"> is better/more correct/preferable to saying "<font color="#ABCDEF">, which is more compact and semantically simpler, and therefore easier to read? (As a programmer, I value code readability and clarity above most other virtues.)

    Are there any actual benefits to doing it that way, or is this just HTML zealotry?

    I think the theory is that some time in the vague future all previous HTML incarnations will go away in favor of XHTML and HTML5, and browsers will stop rendering them. The W3C made a lot of noise about this when XHTML was in development.

    The reality is that browsers will never in a million years stop rendering those HTML 3.2 sites, there's no reason for them to do so, and the first browser that does will lose half its users for being "broken". So... that HTML 3.2 site will render until the end of time. (Of course, HTML 3.2 browsers probably didn't do the "cascading huger font" thing, so it might not render the SAME as it did in 1997...)

    Here's the thing: websites are AWFUL. Until very recently NO popular websites could successfully pass validation. (Hell, for a period of about 5 years, it was literally impossible to have a "correct" Flash object on a site and also pass validation.) You'll find pages where HEAD is typed as HEADER, you'll find pages with unclosed tags, tags closed in the wrong order, mish-mash of CSS styles and old-style FONT tags, CSS files that contain 60,000 styles in them, etc.

    But that doesn't change the fact that:
    1) The messy coding of websites is beyond the user's and browser maker's control
    2) No matter how messy the coding is, the user wants to see the site
    3) So browsers are just going to have to suck-up and deal with it

    (BTW, this is all hilarious because it puts the open source-y Mozilla and WebKit developers in the same position that Microsoft Windows developers have been in for decades-- hey maybe you guys now ACTUALLY UNDERSTAND in a firm and not-theoretical way why all those compatibility hacks are in Windows, and why you can't just make a breaking change and say "deal with it", and maybe you'll maybe start to have a little empathy towards Microsoft developers as a result? Naaah.)

    Even I, who is as pragmatic as they get, think the style attribute is cleaner than using a FONT tag however. Mainly because it's consistent across every single type of tag, whereas the "color" attribute *only* applies to a couple specific tags. So it's less "semantic complexity" you have to keep in your head. "Oh can I use color with LI? I can't remember... maybe I need to add a extra FONT tag inside my LI just to set the color or maybe I can just set the color directly... I'll have to try it and see."

    I think CSS is poorly-designed, but I also think it's better than what came before.



  • @Mason Wheeler said:

    All right.  And what is the rationale for saying that <span style="color:#ABCDEF;">  is better/more correct/preferable to saying "<font color="#ABCDEF">, which is more compact and semantically simpler, and therefore easier to read?

    One of the reasons could be that <font> is not a valid tag for HTML that's supposed to validate to any current standard. If you want a better reason than "Because they said so," then there doesn't really seem to be one, since an attribute-less <font> tag doesn't do much of anything different than an attribute-less <span>. However, I'd say that <span> implies the possibility of having a wider use than <font> even if you don't use it for anything other than setting fonts.


  • Considered Harmful

    I'll bite. You're right in that <span style=... and <font color=... have the same semantic value, that is to say, none whatsoever. They both share the same failing that you're coupling the presentation and structure of your document. The style attribute does have a few advantages, such as greater flexibility (you can adjust a lot more than the color) and uniformity (virtually all elements support it, it accepts the same values everywhere).

    I couldn't recommend either one, though, as the actual idea of specifying a color inside your document fails the basic goal of hypertext: to present the content of a document in a user-agent agnostic fashion. CSS has this capability called media queries (which aren't available inline) which allow a document to be presented one way to a screen, another way to a handheld device, and yet another way to a screen reader (aural browser). So it might be red on your screen, or spoken at a higher volume by a screen reader, or black and bold when you print it on paper. You lose this with inline styles.

    However, sometimes on the web compromises must be made between purity and pragmatism, and the most important reason to use style="" instead of color="" is that it lets us use the same grammar our properly-done CSS uses, which in turn promotes consistency in both how web developers and browsers implement styles.



  • @Cassidy said:

    @Quietust said:

    What, Timecube?
     

    Yesssssss! That's the fellah!

    Thanks a lot -- the above link redirected to AdultFriendFinder.



  • @Mason Wheeler said:

    And what is the rationale for saying that <span style="color:#ABCDEF;">  is better/more correct/preferable to saying "<font color="#ABCDEF">, which is more compact and semantically simpler, and therefore easier to read?
     

    The <font> tag is a bit of a kludge - attributes are size, face (understandable) but colour shouldn't really be an attribute. Other attributes - such as weight - were split out into a separate tag, fortunately now deprecated.

    The "style" attribute is also more flexible and not just limited to colours, so doesn't suffer from limitations of the <font> tag.

    Another reason is - as Blakey mentions - at some point in the future deprecated tags won't be rendered by browsers so it's best to avoid using them now.

    @smxlong said:

    @Cassidy said:
    Yesssssss! That's the fellah!

    Thanks a lot -- the above link redirected to AdultFriendFinder.

     

    No idea why. Sounds like you have DNS hijacking issues.


     



  • @Cassidy said:

    Another reason is - as Blakey mentions - at some point in the future deprecated tags won't be rendered by browsers so it's best to avoid using them now.

    You know how I know you didn't read my post?



  • @blakeyrat said:

    You know how I know you didn't read my post?
     

    Now you're being pedantic. I was paraphrasing the theory; you're ruining it with reality.

    I would really like to see browsers draw a line under HTML4 and refuse to render HTML3 but sadly that ain't gonna happen.



  • @Cassidy said:

    Now you're being pedantic. I was paraphrasing the theory; you're ruining it with reality.

    Well you didn't demonstrate understanding of my point, so I assumed you didn't read it at all.

    @Cassidy said:

    I would really like to see browsers draw a line under HTML4 and refuse to render HTML3 but sadly that ain't gonna happen.

    "Sadly?" That's a wonderful, beautiful thing.

    You know what would be sad? Losing millions of pages of useful information because some geek was so much of a pedantic dickweed he thought that, since someone 12 years ago closed his tags in the wrong order, a user in 2013 shouldn't be able to see the page. That would be sad.



  • @blakeyrat said:

    @Cassidy said:
    Now you're being pedantic. I was paraphrasing the theory; you're ruining it with reality.

    Well you didn't demonstrate understanding of my point, so I assumed you didn't read it at all.

    @Cassidy said:

    I would really like to see browsers draw a line under HTML4 and refuse to render HTML3 but sadly that ain't gonna happen.

    "Sadly?" That's a wonderful, beautiful thing.

    You know what would be sad? Losing millions of pages of useful information because some geek was so much of a pedantic dickweed he thought that, since someone 12 years ago closed his tags in the wrong order, a user in 2013 shouldn't be able to see the page. That would be sad.

    The problem with that is that as long as we continue to accept it for pages written 12 years ago, it also continues to be valid for new stuff created today, and so the problem continues to get worse.  That's the fundamental problem with the Robustness Principle: If you tolerate something that's just a little bit over the line, that establishes a de facto new line at that position. And then you end up having to tolerate things that are just a little bit over that line, and so on, and it never ends.

    That's one of the things that really bugs me about the Web.  We've known since the 19-freaking-50s how to deal with textual input with a formal semantic meaning: you run it through a strict parser to determine the meaning, and if it does not validate, you abort with an error.  Do not pass Go, do not collect $200, and for the love of all that is binary do not let some program attempt to silently fix the user's mistakes for them! There's a reason why DWIM is understood as a Very Bad Idea by programmers who actually know what they're doing.

    But instead, we took the wrong path and ended up with the mess that is modern HTML, Javascript and CSS.

     



  • @Mason Wheeler said:

    The problem with that is that as long as we continue to accept it for pages written 12 years ago, it also continues to be valid for new stuff created today, and so the problem continues to get worse.

    I move that it does not.

    For example, you could easily write a web service that would use a modern browser (meaning: available today) to translate the 1997 page into valid 2013 HTML, then re-serve it to the browser. Think of how the Google Translate feature in Chrome works, but for HTML itself. Then your even-more-modern browser can shed the cruft. (Assuming you believe there is a lot of cruft to shed, which I wouldn't agree with, not without some evidence.)

    If Microsoft figured out how to shim Windows 3.11 applications without any loss of performance, why can't the browser development community? Because they're slackers!!!!! (Well, ok, because there's been no need to yet.)

    @Mason Wheeler said:

    That's one of the things that really bugs me about the Web. We've known since the 19-freaking-50s how to deal with textual input with a formal semantic meaning: you run it through a strict parser to determine the meaning, and if it does not validate, you abort with an error.

    Yeah, guess what? A lot of bad decisions were made in the past. Don't you think Microsoft would love to have a time machine to go back and make VBA thread-safe from day 1? But sometimes you have to just fucking cope with things.

    Welcome to reality. Sorry.



  • @blakeyrat said:

    Losing millions of pages of useful information because some geek was so much of a pedantic dickweed he thought that, since someone 12 years ago closed his tags in the wrong order, a user in 2013 shouldn't be able to see the page.
     

    You wouldn't "lose" them; you'd simply find that they won't display in specific browsers - much like the situation now for pages that have never had their presentation structure updated to reflect modern display methods, such as mobile devices and the like.  Information on microfiche hasn't been lost, it's simply been transferred into a more modern medium to keep it available.

    You would also lose millions of pages of outdated information, such as manuals to earlier verisons of open-source products and obsolete Linux guides on how to setup legacy services that are only used by neckbeard luddites yet still contaminate modern search results. I'd have thought you'd be singing those praises from the rooftops.



  • @Mason Wheeler said:

    But instead, we took the wrong path and ended up with the mess that is modern HTML, Javascript and CSS.
     

    Despite its drawbacks, I still feel it's an improvement over the original.


  • Considered Harmful

    @Mason Wheeler said:

    That's one of the things that really bugs me about the Web.  We've known since the 19-freaking-50s how to deal with textual input with a formal semantic meaning: you run it through a strict parser to determine the meaning, and if it does not validate, you abort with an error.  Do not pass Go, do not collect $200, and for the love of all that is binary do not let some program attempt to silently fix the user's mistakes for them! There's a reason why DWIM is understood as a Very Bad Idea by programmers who actually know what they're doing.

    That's why XHTML 1 Strict changed the web and today everyone uses XHTML 2... oh. Wait, they don't?

    Draconian policies on markup would have had a chilling effect on the growth of the web, and it may have never entered the mainstream if it required years of education and careful attention to detail just to publish a web page. As much as I hate tagsoup markup, if browsers didn't tolerate it the web would be a pretty barren place, and that would cut its popularity down to vanishing. Also, consider the business implications to a company if a content-entry intern could crash their production website by being a bit careless with the markup.

    I understand the desire to dejunkify the web, but you're not going to accomplish what you want by banning bad websites. All you'll do is drive people away from conforming browsers to ones that will parse the web just as it exists.



  • @joe.edwards said:

    it may have never entered the mainstream if it required years of education and careful attention to detail just to publish a web page.
     

    But I don't think it does require that effort you speak of. I've had novices update HTML3.2->4 and once they learned what tags not to use (and what to replace them with) they adapted pretty quickly. Granted we hadn't gone into CSS, but unlearning older habits didn't take a great deal of effort.

    @joe.edwards said:

    Also, consider the business implications to a company if a content-entry intern could crash their production website by being a bit careless with the markup.

    That suggests a lack of testing and change control. A production website could crash due to an intern adding careless code, be it markup, ASP code, PHP statements etc. The only difference is that browsers are more tolerant of HTML so can withstand lax coding, hence we don't impose as tight change control for content-entry. If HTML aborted on first error, you can bet that change and release policies for writing HTML would be as tight as writing ASP/PHP etc.@joe.edwards said:

    All you'll do is drive people away from conforming browsers to ones that will parse the web just as it exists.

    Yeah, I agree that will probably be the outcome; I think AOL realised that after buying Netscape and took the best business decision possible.

    (Having said that, some experts predicted that sites blocking IE6 would haemorrhage visitors and yet that didn't occur.)



  • @joe.edwards said:

    @Mason Wheeler said:
    That's one of the things that really bugs me about the Web.  We've known since the 19-freaking-50s how to deal with textual input with a formal semantic meaning: you run it through a strict parser to determine the meaning, and if it does not validate, you abort with an error.  Do not pass Go, do not collect $200, and for the love of all that is binary do not let some program attempt to silently fix the user's mistakes for them! There's a reason why DWIM is understood as a Very Bad Idea by programmers who actually know what they're doing.

    That's why XHTML 1 Strict changed the web and today everyone uses XHTML 2... oh. Wait, they don't?

    Draconian policies on markup would have had a chilling effect on the growth of the web, and it may have never entered the mainstream if it required years of education and careful attention to detail just to publish a web page. As much as I hate tagsoup markup, if browsers didn't tolerate it the web would be a pretty barren place, and that would cut its popularity down to vanishing. Also, consider the business implications to a company if a content-entry intern could crash their production website by being a bit careless with the markup.

    I understand the desire to dejunkify the web, but you're not going to accomplish what you want by banning bad websites. All you'll do is drive people away from conforming browsers to ones that will parse the web just as it exists.

     

    Yeah, I've heard the "you had to accept crap or no one would have used it" argument before, and I've never bought it.  Yes, there might not have been as many Geocities pages, but is that really a bad thing?  And it would hardly have required "years of education and careful attention to detail" to learn the basics of HTML, especially if you had a strict parser to help you out, which could give meaningful error messages explaining what needs to be fixed.

    But IMO the biggest effect that that would have had is to build demand for decent tooling.  If there was a real standard that was actually enforced to the point that people cared about following it from the beginning, we would have had good WYSIWYG editors for HTML, from the beginning, instead of crappy ones that are forced to be crappy because there is no actual, definitive way to do it right.  And with good tooling to generate HTML markup, the "years of education and careful attention to detail" requirement becomes even less valid, and less intimidating.

    And if a content-entry intern is writing raw HTML intead of, you know, entering content, that's not a business I think any of us would want to be working for in the first place.  Please don't pull out silly strawmen like that.  They don't help your case.

     



  • @Mason Wheeler said:

    Yes, there might not have been as many Geocities pages, but is that really a bad thing?

    Yes.


  • Considered Harmful

    @Cassidy said:

    But I don't think it does require that effort you speak of. I've had novices update HTML3.2->4 and once they learned what tags not to use (and what to replace them with) they adapted pretty quickly. Granted we hadn't gone into CSS, but unlearning older habits didn't take a great deal of effort.

    Well-formedness is one of those things that seems really easy to keep up with, but if you actually go around validating webpages you'll see how easy it is to muck it up. I rarely see a 100% validation result, even on sites that feature a Valid (X)HTML badge, or web development vendor websites, or pages specifically geared for web developers. I personally have launched many websites that were 100% valid on go-live day, but inside of a month the CMS-entered content had been mucked up something awful. Just look at what happens when you paste from Word into a contenteditable element.


  • Considered Harmful

    @Mason Wheeler said:

    And if a content-entry intern is writing raw HTML intead of, you know, entering content, that's not a business I think any of us would want to be working for in the first place.  Please don't pull out silly strawmen like that.  They don't help your case.

    This is not a strawman. This is something I see every day. User types or pastes something into the WYSIWYG of our big enterprisey third-party CMS, publishes their content, sees something weird, and I peek in the source and see the stuff of nightmares.



  • @joe.edwards said:

    @Mason Wheeler said:
    And if a content-entry intern is writing raw HTML intead of, you know, entering content, that's not a business I think any of us would want to be working for in the first place.  Please don't pull out silly strawmen like that.  They don't help your case.

    This is not a strawman. This is something I see every day. User types or pastes something into the WYSIWYG of our big enterprisey third-party CMS, publishes their content, sees something weird, and I peek in the source and see the stuff of nightmares.

     

    Then the problem is not the intern; the problem is that your CMS has b0rked code generation logic.  That's not the content-entry intern's fault, and it underscores the point I made: if a strong demand for good WYSIWYG tools existed--which it would if a strong standard enforced by strict parsers existed--we wouldn't have messes like this.

     



  • @blakeyrat said:

    ... for a period of about 5 years, it was literally impossible to have a "correct" Flash object on a site and also pass validation....

    I know that feeling.  I had a job about 2004-2005 to clean up websites for a specific company (they have many different brands) and had flash on their sites.  Thier goal was 100% valid HTML on all of their sites to enter them in design contests, bu the flash was causing issues.

    I actually worked on it until I found a way that rendered properly in Firefox and IE on multiple platforms and still be 100% complient without server-side or javascript detect scripts.  Then Safari came along and tried to interpret the IE Object tag for flash to "improve compatibility".  Unfortunately, it also then rendered the EMBED tag for the majority of other browsers that had it.  In otherwords, on Safari, it would render the flash twice, because it didn't follow the standards and ignore the inner tag.  We had to revert back to non-standard HTML for flash again (thanks Apple).



  • @Mason Wheeler said:

    And what is the rationale for saying that <span style="color:#ABCDEF;">  is better/more correct/preferable to saying "<font color="#ABCDEF">

    Both are wrong, but the span tag is better for consistency. To change colour, use <span style="color:#ABCDEF;">; to underline, use <span style="text-decoration:underline">; to change the font choice, use <span style="font-family:Arial, Century Gothic, sans-serif"> — they all use the same tag structure.

    Why I say both are wrong is that you should be using <span class="whatever"> and defining the class in a linked style sheet. That way the actual colour and size and so on can be adjusted (ideally on the fly) to the reader.



  • @joe.edwards said:

    if you actually go around validating webpages you'll see how easy it is to muck it up. I rarely see a 100% validation result
     

    The issue isn't how easy it is to muck it up, it's your response to it being mucked up. With browsers being in their current relaxed state, there's no pressure to fix the muckups - the markup will still render.

    If browsers became draconian overlords then markup will be treated much like programming languages in the sense of muckups need to be ironed out before deployment to production.  Similarly, that 100% figure you rarely see will quickly become commonplace.

    Yeah, I know it ain't gonna happen, but don't you think the tolerant nature of browsers is contributing to the problem? It certainly doesn't discourage it.

     @joe.edwards said:

    Just look at what happens when you paste from Word into a contenteditable element.

    I've no idea what that means - but if you're talking about "$thing does a bad job because there's no real reason to do a good job and it doesn't seem to have any effect anyway" shock horror - I've read that headline many times.



  • @havokk said:

    Why I say both are wrong is that you should be using <span class="whatever"> and defining the class in a linked style sheet. That way the actual colour and size and so on can be adjusted (ideally on the fly) to the reader.
     

    ...which I already addressed earlier.  Please actually read what's been written before contributing an idea that's already been rejected with a good explanation.  This is unfeasible if you need to be able to dynamically set up arbitrary colors for text, as you'd need to either dynamically generate stylesheets, which would 1) be a huge mess to code and 2) screw up the entire point of using separate, linked style sheets in the first place, or (even worse) create a style sheet with approximately 16.8 million different classes.

     



  •  I've been wondering if '<b>1<i>2</b>3</i>' is valid or not... It offends me, but is it technically wrong?

    123

    Anyway, I've been working of a HTML snippet auto-checker; for peices of localized HTML that get inserted into .aspx pages.

    A full-on page validator wouldn't work, but all the tags/attributes should match.

    Errors localizers have made include:

    localizing attribute names

    failing to localize link titles

    extra/too little whitespace

    and my favorite: leaving the anchor tags empty, so that the link exists, but there is nothing to click on.


Log in to reply