HTML5 character encoding WTF



  • As pointed out by this blog  - HTML5 character encoding, what a joke! The standard says that if your document is in  ISO-8859-1, it should be interpreted as being in windows-1252, and similarly for other standard encodings. Why on earth they didn't specify mandatory UTF-8 for a new standard and leave it at that I don't know.

     Why don't those link buttons work on this stupid community  server anyway?



  • I agree that the choice to explicity specify that ISO-8859-1 MUST be interpreted as windows-1252 is odd (to say the least), but unless people are using chars from the 80–9F range, I don't think this will cause any trouble. Save for that peculiar control char range, both encodings are exactly the same.


    We publish in UTF-8 anyway.



  • @xiox said:

    Why on earth they didn't specify mandatory UTF-8 for a new standard and leave it at that I don't know.

    THIS.





  • @xiox said:

    Why on earth they didn't specify mandatory UTF-8 for a new standard and leave it at that I don't know.

     Oh, I don't know... maybe because the doctype for HTML5 doesn't specify the version and would potentially break webpages made in the last 17 years?



  • @powerlord said:

    Oh, I don't know... maybe because the doctype for HTML5 doesn't specify the version and would potentially break webpages made in the last 17 years?

     

    Who's fault is that then? Let's remove the versioning from the standard - yet another great idea!



  • @fluffy777 said:

    "last call for comments".... let's all comment!

    I would comment something extremely clever and funny, but I'm too lazy to create an account.



  • @xiox said:

     Why don't those link buttons work on this stupid community  server anyway?

    You have to highlight the text you want to turn into a link, then click them.



  • @morbiuswilters said:

    You have to highlight the text you want to turn into a link, then click them.

    Bad UI design. They should make you read a dialog box then type "I UNDERSTAND" or something.


  • Discourse touched me in a no-no place

    @dabean said:

    @morbiuswilters said:

    You have to highlight the text you want to turn
    into a link, then click them.

    Bad UI design.

    Clearly an inferior design. If that's what the OP is suffering from, there's a case for submiting a pebcak report.

    However, even if the design isn't the problem, I still think my analysis is probably accurate, and subsequent complaints displayed somewhere...


  • This is also weird:

    User agents must not support the CESU-8, UTF-7, BOCU-1 and SCSU encodings.

    Not requiring is one thing, but actively prohibiting?


  • Discourse touched me in a no-no place

    @Spectre said:

    This is also weird:

    User agents must not support the CESU-8, UTF-7, BOCU-1 and SCSU encodings.

    Not requiring is one thing, but actively prohibiting?

    Someone should go rip off the HTML5 working drafts, fix the stupid shit and release a spec for NFAHTML 1.0 (Not Fuckin' Around HTML) - and get it all done way before HTML5 is finalized.

     

    Also, are all of these cases true for both HTML5 and XHTML5? Remember, they're different standards (Why we still have two, and they aren't word-for-fucking-word identical is ABSOLUTELY POSITIVELY BEYOND ME)



  • @Weng said:

    @Spectre said:

    This is also weird:

    User agents must not support the CESU-8, UTF-7, BOCU-1 and SCSU encodings.

    Not requiring is one thing, but actively prohibiting?

    Someone should go rip off the HTML5 working drafts, fix the stupid shit and release a spec for NFAHTML 1.0 (Not Fuckin' Around HTML) - and get it all done way before HTML5 is finalized.

     

    Also, are all of these cases true for both HTML5 and XHTML5? Remember, they're different standards (Why we still have two, and they aren't word-for-fucking-word identical is ABSOLUTELY POSITIVELY BEYOND ME)

      I agree, it is a disgrace, because if you remain backwards for too long you can't improve any. My 2 cents worth from the registered lurker.



  • @Weng said:

    Also, are all of these cases true for both HTML5 and XHTML5? Remember, they're different standards (Why we still have two, and they aren't word-for-fucking-word identical is ABSOLUTELY POSITIVELY BEYOND ME)

    XHTML5? There's no such thing. The latest finalized XHTML spec is 1.1, with 2.0 at draft stage.



  • @tdb said:

    @Weng said:

    Also, are all of these cases true for both HTML5 and XHTML5? Remember, they're different standards (Why we still have two, and they aren't word-for-fucking-word identical is ABSOLUTELY POSITIVELY BEYOND ME)

    XHTML5? There's no such thing. The latest finalized XHTML spec is 1.1, with 2.0 at draft stage.

     

    I think "XHTML5" is short hand for the XML-compatible version of HTML5. It has a name but I CBF Googling for it. Things like <br /> instead of <br>, was what I thought was the main difference.



  • @derula said:

    I would comment something extremely clever and funny
     

    You are such a goddamn liar.



  • @dhromed said:

    @derula said:
    I would comment something extremely clever and funny
    You are such a goddamn liar.

    Oh, really? That's appropriate, because I heard that you sir fight like a cow!



  • @derula said:

    That's appropriate, because I heard that you sir fight like a cow!
     

    Moo, bitch.



  • @Zemm said:

    I think "XHTML5" is short hand for the XML-compatible version of HTML5. It has a name but I CBF Googling for it. Things like <br /> instead of <br>, was what I thought was the main difference.

    Isn't HTML5 XML compatible itself? I'm fairly certain it is.



  • @toth said:

    @Zemm said:
    I think "XHTML5" is short hand for the XML-compatible version of HTML5. It has a name but I CBF Googling for it. Things like <br /> instead of <br>, was what I thought was the main difference.

    Isn't HTML5 XML compatible itself? I'm fairly certain it is.

     

    No, it just permits you to use either HTML or XHTML style closing tags (I think possibly even in the same doc -- i.e. either is equally valid), so it's backwards-compatible to XHTML, but not necessarily XML compatible.



  • @sprained said:

    No, it just permits you to use either HTML or XHTML style closing tags (I think possibly even in the same doc -- i.e. either is equally valid), so it's backwards-compatible to XHTML, but not necessarily XML compatible.

    Really? Lame. Why is it so hard for the W3C to come up with a decent standard?



  • @toth said:

    Really? Lame. Why is it so hard for the W3C to come up with a decent standard?
     

    IIRC it's because there are almot no actual web developers on their panels.  (WTF?)



  • @sprained said:

    @toth said:

    Really? Lame. Why is it so hard for the W3C to come up with a decent standard?
     

    IIRC it's because there are almot no actual web developers on their panels.  (WTF?)

     

    HTML5 is a decent standard, by web standards ... standards. (Made more sense in my head.) The dumb standards are the ones where the W3C spends half a decade ignoring HTML in some futile and useless quest to make a SGML file format XML-compatible.

    Even if XHTML had been successful (and it was doomed from day one), it adds literally not one new feature that weren't already in HTML. The only argument about XHTML that's ever been slightly compelling is that browser makers could simplify their code, because dealing with XML is easy and dealing with SGML is hard-- the problem with that argument is that it assumes once XHTML Strict is a standard, all HTML webpages will disappear overnight.

    It doesn't help that XHTML Strict is incompatible with roughly 90% of the high-volume ad server tags, either. Atlas UATs? Don't validate. DoubleClick DART tags? Ain't gonna validate.

    The reason HTML5 is a good standard is that someone finally knocked on the W3C's heads and said "hello McFly!! SGML is never going away! Even if you close your eyes, plug your ears, and yell 'lalalala'" and they finally got the message this time. Of course, it took a splinter group separating from the W3C standards process to do this... it was impossible to inject common-sense into the process itself. (W3C only took on HTML5 when it was a hair's breadth away from being fully complete. Of course, now that they have, it's been languishing in W3C hell ever since...)

    And yes, HTML5 can be XML compatible if web developers really want that "feature" for some reason.

    As for the W3C itself... there are probably web developers on their panels, but they are very few and far-between and none of them work on the kind of large corporate sites that are really pushing the web envelope right now. (I can almost guarantee there are no, say, Facebook or Google web developers on the panels for example. The reason? Those developers have jobs and get stuff done.) The DoubleClick/Atlas incompatibility issue with XHTML Strict was a death knell, and if the W3C had a single person who understood web development, it would have been binned for that reason alone.

    It's not just that they aren't web developers, though, it's that there's no common sense. Why would they believe XHTML could ever supplant HTML to the point where browsers don't need both code paths? Why were they bothering with crap like, "you can use a XLST transform to turn your webpage into a Word document!" when CSS doesn't even support columns in the standard? Hell, why weren't columns in version 1.0 of CSS? Why is DOM still a disaster, how about addressing some of its 50,000 shortcomings?

    The only standard in the web world I think is well done is the Javascript/ECMAScript standard. But even that is crippled by the awful DOM standard.

    Sorry for the rant.



  • @blakeyrat said:

    @sprained said:

    @toth said:

    Really? Lame. Why is it so hard for the W3C to come up with a decent standard?
     

    IIRC it's because there are almot no actual web developers on their panels.  (WTF?)

     

    HTML5 is a decent standard, by web standards ... standards. (Made more sense in my head.) The dumb standards are the ones where the W3C spends half a decade ignoring HTML in some futile and useless quest to make a SGML file format XML-compatible.

    Even if XHTML had been successful (and it was doomed from day one), it adds literally not one new feature that weren't already in HTML. The only argument about XHTML that's ever been slightly compelling is that browser makers could simplify their code, because dealing with XML is easy and dealing with SGML is hard-- the problem with that argument is that it assumes once XHTML Strict is a standard, all HTML webpages will disappear overnight.

    It doesn't help that XHTML Strict is incompatible with roughly 90% of the high-volume ad server tags, either. Atlas UATs? Don't validate. DoubleClick DART tags? Ain't gonna validate.

    The reason HTML5 is a good standard is that someone finally knocked on the W3C's heads and said "hello McFly!! SGML is never going away! Even if you close your eyes, plug your ears, and yell 'lalalala'" and they finally got the message this time. Of course, it took a splinter group separating from the W3C standards process to do this... it was impossible to inject common-sense into the process itself. (W3C only took on HTML5 when it was a hair's breadth away from being fully complete. Of course, now that they have, it's been languishing in W3C hell ever since...)

    And yes, HTML5 can be XML compatible if web developers really want that "feature" for some reason.

    As for the W3C itself... there are probably web developers on their panels, but they are very few and far-between and none of them work on the kind of large corporate sites that are really pushing the web envelope right now. (I can almost guarantee there are no, say, Facebook or Google web developers on the panels for example. The reason? Those developers have jobs and get stuff done.) The DoubleClick/Atlas incompatibility issue with XHTML Strict was a death knell, and if the W3C had a single person who understood web development, it would have been binned for that reason alone.

    It's not just that they aren't web developers, though, it's that there's no common sense. Why would they believe XHTML could ever supplant HTML to the point where browsers don't need both code paths? Why were they bothering with crap like, "you can use a XLST transform to turn your webpage into a Word document!" when CSS doesn't even support columns in the standard? Hell, why weren't columns in version 1.0 of CSS? Why is DOM still a disaster, how about addressing some of its 50,000 shortcomings?

    The only standard in the web world I think is well done is the Javascript/ECMAScript standard. But even that is crippled by the awful DOM standard.

    Sorry for the rant.

    If the W3C was in charge of the rest of the Internet, we'd still connect over 300 baud circuit-switched lines; the only application would be telnet; email would be sent via a nightly UUCP job which would arrive on the opposite coast at the approximate speed of snail mail; and Telnet 2.0 would have been in committee for the last decade and a half, although we are assured it will finally make the Internet useful by the sheer force of its strict, unyielding syntax.



  • @morbiuswilters said:

    If the W3C was in charge of the rest of the Internet, we'd still connect over 300 baud circuit-switched lines; the only application would be telnet; email would be sent via a nightly UUCP job which would arrive on the opposite coast at the approximate speed of snail mail; and Telnet 2.0 would have been in committee for the last decade and a half, although we are assured it will finally make the Internet useful by the sheer force of its strict, unyielding syntax.
     

    Haha, nice.

    I just want to add that the reason the Javascript/ECMAScript standard is pretty good is because it's not done by the W3C. I didn't want to give the mistaken impression that I approve of anything the W3C does.



  • @blakeyrat said:

    It's not just that they aren't web developers, though, it's that there's no common sense. Why would they believe XHTML could ever supplant HTML to the point where browsers don't need both code paths? Why were they bothering with crap like, "you can use a XLST transform to turn your webpage into a Word document!" when CSS doesn't even support columns in the standard? Hell, why weren't columns in version 1.0 of CSS? Why is DOM still a disaster, how about addressing some of its 50,000 shortcomings?
     

    Don't get me started on CSS... (although the CSS3 standard does support columns).

    Not that it would have mattered much, seeing as how IE 8 still is arguably not fully CSS2 compliant, and MS is resolved not to implement any CSS3 until the spec is finalized (meaning 2023?)



  • @sprained said:

    Not that it would have mattered much, seeing as how IE 8 still is arguably not fully CSS2 compliant, and MS is resolved not to implement any CSS3 until the spec is finalized (meaning 2023?)
     

    You can't blame them, after what happened when they implemented CSS1 before the standard was final. "Oh, we know you read the box model as meaning this in your finished and shipping browser, Microsoft, but we've just finalized the standard and now it means THE EXACT OPPOSITE. Psych!!" Then comes 10 years of bad press as Microsoft:

    1) Refused to change their CSS box model for backwards-compatibility reasons

    2) Everybody in every other browser community slammed them constantly for getting CSS "wrong"



  • @sprained said:

    Not that it would have mattered much, seeing as how IE 8 still is arguably not fully CSS2 compliant, and MS is resolved not to implement any CSS3 until the spec is finalized (meaning 2023?)

    At this point, the W3C is just stalling for time, hoping that the machines rise up and slaughter humanity before they have to produce a coherent styling language with multi-column layouts.



  • @derula said:

    @fluffy777 said:
    "last call for comments".... let's all comment!

    I would comment something extremely clever and funny, but I'm too lazy to create an account.

     

     

    I wouldcomment something extremely clever and funny, but I'm too lazy to think of something funny.



  • @blakeyrat said:

    @sprained said:

    Not that it would have mattered much, seeing as how IE 8 still is arguably not fully CSS2 compliant, and MS is resolved not to implement any CSS3 until the spec is finalized (meaning 2023?)
     

    You can't blame them, after what happened when they implemented CSS1 before the standard was final. "Oh, we know you read the box model as meaning this in your finished and shipping browser, Microsoft, but we've just finalized the standard and now it means THE EXACT OPPOSITE. Psych!!" Then comes 10 years of bad press as Microsoft:

    1) Refused to change their CSS box model for backwards-compatibility reasons

    2) Everybody in every other browser community slammed them constantly for getting CSS "wrong"

    Is that what happened?  I hate CSS so I try to avoid it like the plague, but I did always wonder how Microsoft could get the box model so wrong.  Not to mention that it seems they could have patched it as soon as they noticed the problem, before layouts were designed around it and it became an issues of backwards compatibility.  It makes a lot more sense that the W3C fucked up, as usual.



  •  @morbiuswilters said:

    Is that what happened?  I hate CSS so I try to avoid it like the plague, but I did always wonder how Microsoft could get the box model so wrong.  Not to mention that it seems they could have patched it as soon as they noticed the problem, before layouts were designed around it and it became an issues of backwards compatibility.  It makes a lot more sense that the W3C fucked up, as usual.

    That's what I've been told by an IE developer. It may be apocryphal, I dunno, but I don't see any reason to doubt it-- especially since, IMO, the IE way of implementing the box model is more intuitive, and W3C specs are usually vague.

    Also, I do know of at least one example where the W3C screwed over MS for no reason. MS implements innerText to match the standard's innerHTML. W3C decides this is a good idea, so they put it in the spec-- but name it textContent! Entirely inconsistent with their own naming scheme, incompatible with existing websites! Morons.

    And of course, Mozilla is so pig-headed they refuse to alias innerText to textContent. Last time I checked, the W3C doesn't prohibit you from using innerText... and it would bring immediate compatibility benefits... but no, Mozilla won't do it.



  • @sprained said:

    @toth said:

    @Zemm said:
    I think "XHTML5" is short hand for the XML-compatible version of HTML5. It has a name but I CBF Googling for it. Things like <br /> instead of <br>, was what I thought was the main difference.

    Isn't HTML5 XML compatible itself? I'm fairly certain it is.

     

    No, it just permits you to use either HTML or XHTML style closing tags (I think possibly even in the same doc -- i.e. either is equally valid), so it's backwards-compatible to XHTML, but not necessarily XML compatible.

    But that doesn't make sense. If it's compatible with XHTML, then it must be compatible with XML too, since XHTML is a subset of XML.



  • @Spectre said:

    If it's compatible with XHTML, then it must be compatible with XML too, since XHTML is a subset of XML.

    No. Why would XHTML⊂XML∧XHTML⊂HTML5⇒HTML5⊂XML? That doesn't make any sense.



  • @Spectre said:

    @sprained said:

    @toth said:

    @Zemm said:
    I think "XHTML5" is short hand for the XML-compatible version of HTML5. It has a name but I CBF Googling for it. Things like <br /> instead of <br>, was what I thought was the main difference.

    Isn't HTML5 XML compatible itself? I'm fairly certain it is.

     

    No, it just permits you to use either HTML or XHTML style closing tags (I think possibly even in the same doc -- i.e. either is equally valid), so it's backwards-compatible to XHTML, but not necessarily XML compatible.

    But that doesn't make sense. If it's compatible with XHTML, then it must be compatible with XML too, since XHTML is a subset of XML.

    I think what he meant was that XHTML is forwards-compatible with HTML5, since any valid XHTML is presumably valid HTML5, but not vice-versa.



  • @derula said:

    XHTML⊂XML∧XHTML⊂HTML5⇒HTML5⊂XML?
     

    Good Lord.



  • @Someone You Know said:

    @derula said:
    XHTML⊂XML∧XHTML⊂HTML5⇒HTML5⊂XML?
    Good Lord.

    Better than morb's mom.



  • @derula said:

    @Someone You Know said:
    @derula said:
    XHTML⊂XML∧XHTML⊂HTML5⇒HTML5⊂XML?
    Good Lord.

    Better than morb's mom.
     

    Not for extremely large values of XML.



  • @derula said:

    @dhromed said:
    @derula said:
    I would comment something extremely clever and funny
    You are such a goddamn liar.

    Oh, really? That's appropriate, because I heard that you sir fight like a cow!

     

    That's pretty damn hard-core, actually. 



  • @Spectre said:

    But that doesn't make sense. If it's compatible with XHTML, then it must be compatible with XML too, since XHTML is a subset of XML.
    XHTML allows you to use XML namespaces. HTML5 does not. You can write a document that is valid that uses XML syntax (as opposed to in HTML4 where technically you are supposed to be writing SGML which has a different meaning for />), but that’s about it.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.