Forum Moderators: open
I've seen the old "thy shall not use xhtml" stuff, and while I agree to it if you assume that your code will not validate, I disagree with it in the fact that I can keep my xhtml code validating just fine.
So why do I use it over html 4.0 strict ?
'Latest greatest' was probably when I started it together with learning CSS, but it isn't so for a long while even among the reasons anymore.
So who are your reasons to use xhtml ?
The reasons not to use xhtml are in another thread already: [webmasterworld.com...]
xhtml allows more freedom in CSS for styling independently both the html and the body (they both act like less "special" blocks).
Could you elaborate a little more on this? what restrictions does valid html impose?
Could you elaborate a little more on this? what restrictions does valid html impose?
I know I tried to give a CSS solution I was using in production in an xhtml site to a member out here asking a "how do I", but I discovered it didn't work at all in his HTML doctype, and worked instantly when I switched back to xhtml ((x)html code was valid in both cases as was the CSS).
It had to do with the special treatment <html> and <body> get, but unfortunately it appears I can't remember exactly how to reproduce it now (I tried, didn't trigger it, maybe it's something that got "fixed" in more recent firefox versions, hard to tell at this point).
But to show examples of the same CSS and same (x)html acting different between a xhtml and html doctype, take e.g. a look at this recent thread:
[webmasterworld.com...]
(only the xhtml code is posted but I'm sure you can swap out for a html doctype)
Sure the effect sought was the one of the html etc, but the bottom line is that it gets rendered differently.
To see how e.g. <body> and <html> get special treatment and some subtle differences between HTML and xhtml:
[w3.org...]
For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. For documents whose root element is an HTML "HTML" element or an XHTML "html" element that has computed values of 'transparent' for 'background-color' and 'none' for 'background-image', user agents must instead use the computed value of the background properties from that element's first HTML "BODY" element or XHTML "body" element child when painting backgrounds for the canvas, and must not paint a background for that child element. Such backgrounds must also be anchored at the same point as they would be if they were painted only for the root element.
But the thing that really gets to me is just a bit below:
Note that the rule for the BODY element will work even though the BODY tag has been omitted in the HTML source since the HTML parser will infer the missing tag
bodyI use XHTML 1.0 in the following scenarios:
1. When the CMS I'm using generates XHTML by default - not just in the templates (which are easy to change), but in the other markup handled by the CMS back-end. I could modify the CMS, but it makes patching and upgrading harder for no real-world benefit - it would be a waste of my time.
2. When dealing with large or complex data tables - because HTML allows implied closing tags such as
</td>3. If I want to have an
idhtml
xhtml (even transitional) has far more strict validation...
There's been some inconclusive discussions about adding a "strict" mode to the HTML5 validator, to show the omission of optional closing tags, unquoted attributes etc in HTML as warnings.
I think it's a good idea. I'd like to see a "short" validator mode as well, one that shows the inclusion of optional closing tags, quoted attributes etc in HTML as warnings.
I want to have the ability to use xml parsers to manipulate my code
Some XML parsers can also parse HTML eg libxml (?)
I've only ever worked on one XHTML website, all my other work is HTML. No plans to change its backend systems to produce HTML, but I do find it annoying having to type the extra bits ;)
In other words -- I generally use XHTML for anything where I want XML functionality, but never as a simple replacement for HTML.
I've spent 9 years coding in XHTML and I look at it as my mistress; Risky, sexy, clean, fun and unafraid to try anything new.
If I had to move to HTML it would be my wife; more fumbling around, unable to try anything new and way to forgiving given my mistress tendencies.
I have read post after post, blog after blog arguing which way I should be coding but at the end of the day XHTML works fine, I need no tweaking, no browser hacks and I like the way it makes me to keep my code clean and error free.
I also love how clean the code looks. I'm sorry but I'm that geeky about the code I create that I want it to look as clean and tidy as I can.
Sad I know...
2 years ago I realized that there was no point to using XHTML because HTML 4.01 would let me use markup code exactly the same way.
I could still close all my tags (other than the self-closing puppies), I still could use all lower case, in essence I could use the exact same markup rules I did when using XHTML (again, other than the self-closing puppies).
So I started changing my XHTML doctypes to HTML 4.01.
There is absolutely no difference. As a matter of fact, to change my markup it as simple as using "find and replace" for " />" to ">". Bingo, instant conversion of xhtml to html.
It showed to me that xhtml is really just a semantically stricter version of html.
The only real eye opener, however, was when I changed any xhtml 1.0 transitional to html 4.01 strict. THAT'S what really mattered. Using xhtml transitional is STILL using deprecated and in many cases no longer used HTML 3 or 4 markup.
You only realize the bad habits you've fallen into when you start using a strict doctype.
I first started coding in 1996 HTML 2.0 had just come out (the first actual named version). I jumped on the XHTML bandwagon, same as everyone else, in 2004 when wanting to switch from table-based to css-based. All the books and gurus claimed xhtml would be the future of html.
Well we now know that is not so - mostly thanks to MS pooping out a different non-standards supporting IE every 2 years or so; none of which support xhtml when served as intended with the mime-type of "application/xml+xhtml" either.
Ultimately it is a moot point because HTML 5 and XHTML 5 use the exact same page.
And those of you who never learned XHTML syntax will have a hard time of it in the future when HTML 5.X is finally supported - perhaps another 5 years or so - by some future IE (maybe).
Because HTML 5 and XHTML 5 were developed TOGETHER! They are the same document. The intent is simply so if you designate a mime-type of "text/html" it will serve as HTML 5, if you designate a mime-type of "application/xml+xhtml" it will serve as XHTML 5.
All the optional values of HTML are gone. The mandatory syntax (including self-closed tags) is required for both. So the whole XHTML vs HTML debate will be moot in a few years.
But don't hold your breath. Because TA DAAA! IE8 doesn't support xhtml served as "application/xml+xhtml". Don't you just love MS and the way they move technology forward?
What that means is you will have to designate "text/html" which makes it automatically HTML 5 (unless you don't care what IE does to the page). You will never be able to take advantage of the inherent xml parsing while IE still has its head up its ASP.
All the optional values of HTML are gone. The mandatory syntax (including self-closed tags) is required for both. So the whole XHTML vs HTML debate will be moot in a few years.
HTML5 retains HTML4's rules: optional tags are still optional [whatwg.org], self-closing tags aren't required [whatwg.org].
But HTML5 does now allow XML syntax in HTML documents: <br /> and <br> are both valid HTML5.
So a valid HTML5 document that uses XML syntax will be valid XHTML5 and valid HTML5, and can be switched from HTML to XML by just changing the mime type, as you say.
[edited for typo]
>>HTML 5 defines an HTML syntax that is compatible with HTML 4 and XHTML 1 documents published on the Web, but is not compatible with the more esoteric SGML features of HTML 4, such as the NET syntax (i.e. <em/content/). Documents using the HTML syntax must be served with the text/html media type.<<
This seems to make learning what is and isn't allowed more trouble than not.
>>Some attributes from HTML 4 are no longer allowed in HTML 5. If they need to have any impact on user agents for compatibility reasons it is defined how they should work in those scenarios...<<
>>.. in addition, HTML 5 has none of the presentational attributes that were in HTML 4 as their functions are better handled by CSS.<<
Good, we need to stop the tag soup.
>>The following elements are not in HTML 5 because their usage affected usability and accessibility for the end user in a negative way: frame, frameset, noframes <<
Does anyone here really expect to ONLY use markup that is required to be forever limited as text/html? Just for future scaleability alone that is foolhardy.
The idea of using one markup syntax for the powerful potential of interchanging two mime-types is a sound strategy.
So for that alone, I acknowledge it is better (if not important) for beginners to LEARN current xhtml syntax - just so they have less to re-learn later.
...it seems some HTML 4 rules will be retained for required older browser support [...] I expect it will be dropped once the browsers (IE) have caught up to it.
Breaking millions of pages because they use valid HTML rules is probably not high on browser makers' To-Do-lists :) It's not IE that's the problem here, it's existing content e.g. Amazon.
The HTML5 spec defines how to parse HTML, and HTML has optional tags. A conforming browser will support the omission of optional tags, as current browsers, mostly, do now.
We've all got into the habit of using pseudo-XHTML syntax in our HTML documents. It was seen as best practice, in part because XHTML was The Next Step. Best practices change over time - using uppercase tags was once best practice...
I think we may gradually see more people using the leaner HTML syntax e.g. Google [html5.validator.nu] (to me, that's elegant code!)
Does anyone here really expect to ONLY use markup that is required to be forever limited as text/html?
Yes. For low-ish values of forever :)
It's not the syntax that's important (aesthetic and code maintainability reasons aside), it's building and accessing the DOM tree that's important.
The same document in HTML5 (even if it omits optional tags) and XHTML5 versions will build the same tree, and the same things can be done with that tree in either case. Syntax choice doesn't matter *if* both syntax versions build the same tree in parsers.
