7 ms·

This. I wish they didn't do a HTML5 but instead only did a XHTML5. There are a lot of good ideas in HTML5 but why did there need to be _another_ way of parsing

• icebraining 13y ago
  I'm sure many at the W3C would have loved to develop only a new version of XHTML, but the problem is that it breaks retro-compatibility, and that's almost impossible to impose. Any browser to try that would see its lunch get eaten by its more permissive competition.
• praptak 13y ago
  Out of curiosity - what is the correct way to write the BR tag in XHTML5?
  • porges 13y ago
    <br/> - you might like to read the guide for 'polyglot' markup [1] that is both valid HTML & XHTML [1]: http://dev.w3.org/html5/html-polyglot/#empty-elements http://dev.w3.org/html5/html-polyglot/#empty-elements
• userbinator 13y ago
  I think it's excellent that HTML5 completely specifies the parsing in a very clear, and most backwards-compatible way; judging by what the big browser vendors have been doing, they seem to be following it. (It also gives a nice starting point that makes it easier for anyone to write their own parser, and have it behave the same as any other mainstream browser - and having the possibility of making more browsers available, with the same standard parsing behaviour, is a good thing.)
• vesinisa 13y ago
  Apparently, you can still write polyglot documents that are both valid XHTML and HTML5.[1] But this requires closing void tags with <tag />. [1] http://blog.whatwg.org/xhtml5-in-a-nutshell http://blog.whatwg.org/xhtml5-in-a-nutshell
• jeswin 13y ago
  I prefer HTML over XHTML, because it is easier to write. I don't get the reasoning behind closing tags. LIs close before the next LI, or the UL. <BR> saves two characters over <BR /> and causes no harm. XHTML feels like trying too hard to make the machine overlord happy. It is plain wrong to make a standard easier for machine-parsing at the expense of humans who are typing it in. EDIT: Another example. I write some HTML in a text-editor/textarea and send it across to someone. If I missed a </LI>, should the parser reject it? If not, the standard should be accommodating enough so that this is valid.
  • kalleboo 13y ago
    The tradeoff is that allowing quirks like that means that either you need to make a massive specification to deal with each way someone might goof in their code (edit: which is what HTML5 tries to do), or you end up with each browser engine reacting differently. The main push behind stricter document control is making it easier to make all the browsers render documents consistently. Also, in the age of XHTML, manual document editing was seen as dead - tools like DreamWeaver were popular, and XSLT was touted as the answer to server-side templates. The web refuses to be anything but a pile of dirty hacks upon dirty hacks though, which while frustrating, may have a hand in it's popularity :)
    • zimbatm 13y ago
      That's why HTML5 specifies the parser, so that every browser extract the same DOM tree from the same input. The specification is strict in the sense that any parser has to behave the same while also allowing for human error.
      • DougWebb 13y ago
        ... so that every browser extract the same DOM tree from the same input That is, every browser whose engine has been updated for HTML5 and which also implements the parser specification correctly and without bugs. Which is most, but not all, of them. My personal preference is to include the optional closings, because XHTML has been around a lot longer and therefore a larger proportion of browsers have been coded to handle it properly and have had more time to work out bugs. I do like that HTML5 browsers can work around invalid markup in a well-specified way, which is much better than XHTML browsers just showing an error. It's the best of both worlds, especially when the browser's Developer Tools give you warnings about the invalid markup too so you don't need to use an external validator to find them.
• keeperofdakeys 13y ago
  XHTML lost, we decided that we preferred tag-soup, and keeping our past documents readable. Besides that, most XHTML came with a HTML mimetype, which meant it wasn't being read as XHTML. So the best bits, lighter parses, and XML embedding, were never usable.
  • talmand 13y ago
    I don't understand how there's much of any difference in readability between html and xhtml style of coding. Do closing tags really make it that much more difficult to read for some people?
    • chrisoverzero 13y ago
      I think that poster means machine-readable. An XML parser will choke on almost any HTML document.
      • talmand 13y ago
        I can see your point for the post I was responding to, but I've numerous posts throughout the page that seem to be debating over human readability as well.
    • keeperofdakeys 13y ago
      There isn't a difference in readability, XHTML is just stricter. Much of the HTML that exists is invalid HTML/XHTML, and the XML parser used for XHTML would simply error out. Most XHTML pages were served as HTML, due to mimetypes being wrongly configured, so no-one ever noticed. The XML parser was supposed to be faster, and allow any XML to be embedded in the XHTML (SVG, MathML, etc). This stuff was designed to change the shape of the web (especially since mobile phones weren't very powerful in those days).
• mcv 13y ago
  And if they were really going to break the standard like that, at least they could have broken it in such a way that it fixed all the stupid legacy decisions. Have it support <img>alt text</img> and <meta>content</meta>, as well as the old way, and then the developers can decide if they want to support legacy browsers. (They probably do, but at least we're looking at a future where html will be just a tad cleaner and more consistent.)