Code. Really confused... HTML vs XHTML

1 to 13 of 13

  1.  
  1.  
    OK, I give up...

    With all this talk about HTML5 where does this leave XHTML?

    I just looked into using Facebook's Open Graph protocol on my page, but notice that it's an XHTML thing. Does this mean I can't use it on a standard HTML 4.01 strict page? A while back I swapped back to that in preparation for HTML5.

    This doctype shit is really confusing me, especially with all the HTML5 hype surrounding us all.
  2.  

    You can do XHTML5 too...

  3.  

    Potted history, probably riddled with inaccuracies, but I think this about covers it:

    • XHTML became preferable to HTML4 because it represented a purer semantic expression of web documents. HTML4 was cluttered with loads of presentational crap, and XHTML stripped it back and also enforced some XML conventions such as closing tags and properly expressed attributes. You know all this, anyway.
    • Two factions emerged from the ashes of the HTML4/XHTML transition:
      • Faction 1 said that this pure XML shit was the way we should go, and started working on XHTML2.0, a purists dream that stripped everything back even more, but in practice was almost totally unworkable. XHTML had already led to a lot of div soup, where IDs and classes actually evolved to represent real, meaningful things (class="sidebar", etc) and XHTML2.0 would have exacerbated this even more. If you think of the HTML doctype as specialist, the XHTML doctype is aimed at being generalist. But HTML is a specialist markup (for the web), so...
      • Faction 2 said that HTML4 was OK, but clearly flawed in some areas. There are loads of common classes a such that people use, why not standardise it all? Sure, it may mean that web docs become specialist to the web, but so long as each tag/attribute carries real meaning, then it may help reduce div soup and mean people consider the real structure of their documents more.
    • Faction 2 create HTML5, in many ways a bit dirtier than XHTML, but in many ways more appropriate for web-documents. It also looks forward and considers typical structure, etc. While it's true that you can be 'dirty' in HTML5 (not closing tags, not wrapping attributes in speech marks), you don't have to be. You can still pander to your XHTML sensibilities whilst writing HTML5.
    • XHTML is still a perfectly valid doctype, but HTML5 opens up the ability to use media tags like audio and video, as well as being able to properly structure your document with footer, sidebar, nav, etc tags. It's not all fully supported yet, but creating fallbacks is pretty straightforward.
    • You can happily embed XHTML directly in HTML5, but not the other way around. I don't think there's much in XHTML that's invalid in HTML5, if anything...
  4.  
    For the complete history of HTML5 and doctype's check http://diveintohtml5.org/ it has a great history section, he even dug up some conversations from message boards at the start of the internets, when TBL and a few others were discussing things like img tags..
  5.  
    "it'll all be flash in a few years"
  6.  
    Good answer, Jord. Just to add to that, if you are stuck in the old ways, (like me) and prefer XHTML syntax, (closing image or input tags, lowercase etc), that is perfectly valid. All you really need to care about in the short term is the new tags and how they affect document flow,(read the new ABookApart bok or the DiveIntoHTML5 site linked above), and the amazing new Javascript API goodness.

    It really isn't much else.
  7.  

    As an addendum to my last point: you could embed HTML5 in XHTML if you were (as I put it) pandering to your XHTML sensibilities by closing tags and wrapping attributes properly -- so long as you weren't using any of the new tags.

    HTML5 has no moral superiority over XHTML, in many ways it's the other way around, HTML5 is just a pragmatic and forward thinking approach to marking up web-based documents.

    I think one of the interesting things about XHTML -- and one of the reasons HTML5 is now becoming popular amongst the same people that championed XHTML -- was that it showed that even when you prioritise semantics and standards, it's still quite possible to end up with non-semantic, tag-soup. How many arguments have been had about how to mark up a navigation, or whether we should use standard IDs/Classes for footers/headers, or how to semantically embed video/audio, Javascript hacks, etc. While it certainly made things better, it didn't really achieve the goal of turning web-documents into semantically rich, workable docs. HTML5 probably won't achieve that either, but it's certainly the first time that web-markup has had a chance to look forwards rather than just try and correct the mistakes of the past, which can only be a good thing.

  8.  
    It's interesting - I prefer XHTML syntax as it's easier to see how tags are nested and forces you to be more diligent in that regard with closing off tags etc.

    The thing I like about HTML5 is that it's more overtly focussed on the web (as opposed to trying to be a more abstract markup language for any occasion) and gives more semantically meaningful elements to use, but it will be interesting to see how the notion of the "web" evolves with new devices hitting the market, and whether that opens up new semantic contexts and requirements.
  9.  
    This.

    The thing I like about HTML5 is that it's more overtly focussed on the web (---) and gives more semantically meaningful elements
  10.  
    It's interesting - I prefer XHTML syntax as it's easier to see how tags are nested and forces you to be more diligent in that regard with closing off tags etc.

    The thing I like about HTML5 is that it's more overtly focussed on the web (as opposed to trying to be a more abstract markup language for any occasion) and gives more semantically meaningful elements to use, but it will be interesting to see how the notion of the "web" evolves with new devices hitting the market, and whether that opens up new semantic contexts and requirements.


    I prefer the XHTML way of doing things too. Self-closing and lowercase elements etc are great but I sometimes think it's a bit too rigid. For example, boolean attributes liked "checked" and "required" shouldn't need to look like this: checked="checked". So, when I'm writing HTML5 code I use all of my XHTML experience to create a structure which is easy to read and would still (if the elements allowed it) be valid xhtml strict code. But the flexibility of HTML5 is amazing.

    I think (in some cases) that HTML5 will have a negative impact on the way people code because of it's flexibility. It allows uppercase tags and non-self-closing tags without whinging or breaking anything so people may start to use it again. However, everything is much more semantic.

    I'm babbling on. Everything has been said.

    I'm going to go and eat a banana.
  11.  
    I'm just hoping designers don't get too fond of marking up documents with caps lock on. Shudder.
  12.  
    I'm just hoping designers don't get too fond of marking up documents with caps lock on. Shudder.

    Hopefully, proper designers care about good markup as well as good design.

    EDIT: MAYBE THEY'LL START USING <B>CODE LIKE THIS TOO</B>
  13.  
    Fuck, still well confusing.

1 to 13 of 13

  1.  
 
Sponsors: Digital Agency London