Whatever works for you. I might give HTML 5 a try, but until then? XHTML seems more natural, seeing as all tags are closed. As one commenter said: I don’t see the point in intentionally leaving out closing tags just because HTML 4 is sloppy.
I use pseudo-HTML5 on my personal site, but we’re really still looking at years before it’s finalized and moved into any type of standard adoption. I mean, look at CSS2. Original recommendation of spec was made in 1998. The most recent recommendation of CSS2 is CSS2.1, made 2007. Vendors still don’t support everything in CSS2 or follow it correctly. Putting hope that some future spec in this industry is going to go any faster or better is an exercise in disappointment. It’s really frustrating. For me, there are other soapboxes that are worth my time and energy.
Both my sites use HTML5 now, as do all new sites I develop. There’s really no reason not to, and it doesn’t mean you have to use any of the new (unsupported) elements - just do what you normally do with HTML4, with the additional benefit that you don’t need to look up the doctype every time!
Why not? It’s clean code, closed tags, renders better as a modern standard than HTML versions, AND, maybe more important than any other factor, seems to be the one of the many standards that renders well with CSS in various flavors of Microsoft IE. XHTML Strict seems to break more frequently in older versions of IE. HTML 5 has some intriguing attributes, especially regarding media, but is a moving target. It’ll be many years before the target is stable and browser rendering is consistent.
Besides, almost all coding these days is very little HTML and an awful lot of CSS (with its own inherent problems rendering on various flavors of IE).
I use HTML 4, because HTML 5 isn’t supported very well yet (the final specification isn’t expected until ~ 2022), XHTML is pointless and just tag soup…
The W3C standards state:
The ‘text/html’ media type [RFC2854] is primarily for HTML, not for XHTML. In general, this media type is NOT suitable for XHTML. However, as [RFC2854] says, “[XHTML1] defines a profile of use of XHTML which is compatible with HTML 4.01 and which may also be labeled as text/html”.
[XHTML1], Appendix C “HTML Compatibility Guidelines” summarizes “design guidelines for authors who wish their XHTML documents to render on existing HTML user agents”. The use of ‘text/html’ for XHTML SHOULD be limited for the purpose of rendering on existing HTML user agents, and SHOULD be limited to [XHTML1] documents which follow the HTML Compatibility Guidelines. In particular, ‘text/html’ is NOT suitable for XHTML
Joe it’s worth mentioning that the abstract of that document states:
and the use of ‘text/html’ SHOULD be limited to HTML-compatible XHTML 1.0 documents.
Which is in harmony with how most people are using it. Saying that “there is no reason to use XHTML” (emphasis mine) is like most statements made in the absolute, not fully credible. In this particular case you have two different factors: is there a technical reason to use XHTML, and is there a personal reason to use XHTML. While you might make a successful argument against the former, the latter is in the hands of the individual. Take grumps for example: to him (and a multitude of others), XHTML is tidier and more well-formed. That’s a perfectly good reason to use XHTML if that’s an important factor to that individual. To you, it’s tag soup, so likewise, that’s a valid reason to avoid it like the plague.
Edited to add: HTML-compatibility is defined in Appendix C of the XHTML 1.0 recommendation.
HTML 5 isn’t supported very well yet (the final specification isn’t expected until ~ 2022)
Except that date was taken completely out of context. The specification is nearly ready - the 2021 date was mentioned as being when they expect at least two mainstream browsers to fully support the specification. Given that there aren’t two browsers that fully support CSS2.1 yet, 2021 seems a reasonable goal for full support of all aspects of HTML5.
I understand what you’re saying, hell I prefer the syntax, it is so tidier, but I only use it if I serve the page as it was intended.
It is basically saying that text\html should only be served if the user agent does not support application/xhtml+xml and as a certain browser doesn’t support this (infact, the said browser doesn’t support much) I try to avoid using XHTML. Considering your not using any of XHTMLs features and everything you do in XHTML can be achieved in HTML4.01 just as easy, if not easier it makes sense to use it.
Infact, if application/xhtml+xml was supported universally, I would use XHTML no doubt, but as it isn’t I feel it is pointless, it is like making a PHP4 server parse php5 file extensions, the extension says its version 5, but it can only handle version 4 code. (Alright, the example isn’t great, but the same principles apply).
I mean, I understand why people use XHTML, I even used to, then I realised I had no real reason to, other then taking up a few more bytes in the file.
What really annoys me is people teaching XHTML because it is “newer and better then HTML4”, that annoys me to hell, which I guess is why I’m sort of against people using it when they don’t serve the file properly.
I don’t really want to get into the argument here, as we all know it just takes too much effort to get absolutely nowhere.
What really annoys me is people teaching XHTML because it is “newer and better then HTML4”, that annoys me
I can agree with that, Joe, people should make informed decisions. And since we’re diving this deeply, here’s the definition for “SHOULD” in RFCs, which harmonizes with that:
This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
So there’s room for informed people to go either way.
Joe544 - 21 April 2009 11:44 AM
I don’t really want to get into the argument here, as we all know it just takes too much effort to get absolutely nowhere.
Indeed, my take on this topic is to make a decision, and move on. I made the decision to use pseudo-HTML5 on my own site, but for the majority of the world, XHTML is the defacto choice, which is why ExpressionEngine currently only ships with XHTML auto-typography. Personally? I’m very eager for that to change, just not holding my breath.
Buddy Bradley, what you’re saying is probably correct, I was going off of memory when I said that, so I got the year and the information wrong, don’t I look like a fool. Thanks for pointing that one out though.
I do want to eventually sit down and work with HTML5, but at the minute I feel it will be a wasted effort, lack of support and the specification not in solid ground yet, that said, the specification changes could be minimal from now on in, and browsers begin to adopt it. (I’ve not really been tracking progress all that well, so I’m not 100% clued up on it).
I don’t really want to get into the argument here, as we all know it just takes too much effort to get absolutely nowhere.
One of the things that we have to understand here is that the reasons why we use a particular standard will vary, and yet be completely acceptable.
Frankly, one could argue that standards, whether valid HTML, XHTML, and CSS, don’t mean anything at all so long as whatever code used displays appropriately in Internet Explorer. Who cares about valid code? Sloppy, unclosed tags don’t matter much—it’s how the code is rendered that matters the most to the browser user, right?
Others may choose a different, yet highly appropriate path (valid code for whatever standard, and that plays nice nice with IE). Again, argumentation is pointless. Pragmatism wins (despite XHTML typography being an improvement). Whether or not XHTML code is served appropriately according to a defined standard somewhere doesn’t matter much if the browser won’t render the code appropriately, as intended.
My reasons for choosing XHTML Transitional are totally valid. For me. The code validates W3C. CSS validates W3C. XHTML is tidy, clean, neat (generally good behavioral traits for coding). And, importantly, and with fewer problems, XHTML Transitional plays well with more versions of IE, and nearly perfectly well with Firefox and Safari, Mac or Windows.
Pragmatism wins (despite XHTML typography being an improvement).
I’m not trying to prolong what I agree is an ultimately pointless argument, but… how is XHTML typography an “improvement” over HTML4? XHTML is just a reformulation of HTML in XML, it doesn’t really add anything new. And typography is largely controlled with CSS anyway.
I can fully understand Shea’s move. HTML 4.01 is the current standard that works in all browsers. XHTML is not supported by IE and I haven’t heard of any plans by MS to change that in the near future. I find HTML 4.01 Strict to be the cleanest and sensible choice. Obviously a case of IMHO.
I’m not trying to prolong what I agree is an ultimately pointless argument, but… how is XHTML typography an “improvement” over HTML4?
“Typography (Etymology: typos—type, graphos—written) is the art and techniques of arranging type, type design, and modifying type glyphs.”
Easier and better in XHTML and CSS than in HTML. How so? For me, it’s easier, cleaner, tidier, better organized, more flexible, fewer deprecations. That makes it, from my perspective an improvement, and I’m not alone in that assessment.
XHTML is just a reformulation of HTML in XML, it doesn’t really add anything new.
But not better? Then why bother? All that deprecation from HTML to XHTML would appear to be a waste of effort, no. We should notify the W3C before they finalize HTML 5. Some would argue that 5 doesn’t really add anything new. Except another layer of complexity and a standard that may not be ratified for another decade.
And typography is largely controlled with CSS anyway.
Depending on the layout and design, of course, and in my mind, it should be. But typography in CSS is anything but universal on web pages. In history, and today. Jennifer Kyrnin stated, and I agree,”Many browsers are very lax in how they interpret HTML. This leads to incongruities in how the pages are displayed, and XHTML doesn’t allow that.” I would add “...as much.”
Even WHATWG points out an arbitrary perspective. XHTML must be served with an XML MIME type. It seldom is. But, according to spec, XHTML is allowed to be served as text/html, which makes it an HTML document, not an XHTML document. Regardless of the rules, what’s practical is what gets used. Mostly.
Clearly, what’s more important beyond an arbitrary religious adherence to this standard or that standard is what works for the developer and readers, whether it be some vanilla version of HTML without a doc type, or various flavors of XHTML regardless of doc type or how they’re served.
Despite the glacier pace, web standards, as such, are dynamic, constantly changing both in rule and in use. Is there anything wrong with a site developer’s choice of adherence to vanilla HTML vs. HTML Strict vs. XHTML Strict as long as final rendering is appropriate?
XHTML is just a reformulation of HTML in XML, it doesn’t really add anything new.
But not better? Then why bother?
Uh - perhaps because reformulating as XML means that you can use other markup languages like MathML in your document (not that anyone ever does, but that was one of the benefits)? Other than deprecating a bunch of elements and attributes - which nobody is forcing you to use in HTML, 4 or 5 - there is nothing inherently ‘better’ about using XHTML.
Jennifer Kyrnin stated, and I agree,”Many browsers are very lax in how they interpret HTML. This leads to incongruities in how the pages are displayed, and XHTML doesn’t allow that.”
Given that you go on to admit that using XHTML means serving it as text/html (and therefore it isn’t XHTML at all, but HTML tag soup), I’m struggling to see the relevance of that quote.
