It's Officially Over. It's (X)HTML5

[Arlen]

Now that the W3C has announced the end of XHTML2, what is that going to mean for the future?

Some pieces of XHTML2 are going to survive, most will end by the end of this year. Does that change the way you're view the future of the web? How?

What do you look forward to seeing? What do you dread?

[felgall]

I am looking forward to the same decision being made about that horrible mess called HTML5 and its replacement by something meaningful.

[AlexDawson]

I am rather disappointed they decided to cease XHTML2, I know there are the unfortunate issues (thanks in part due to IE's blatent lack of support) but I saw a lot of promise in it. I think it will change the web for the better on one hand as people will no longer look at XHTML as an "upgrade" for HTML (and end up using it inappropriately as 99% of people do) but HTML5 is far from perfect, has issues which I would like to see dealt with (such as the removal of rev which is important in microformats and is not the same as role, no matter how people swing it) so I guess this is like the initial XP to Vista upgrade

I am looking forward to the same decision being made about that horrible mess called HTML5 and its replacement by something meaningful.

What isn't meaningful about HTML5? It has its issues granted but its still a draft, it is not even close to being something requiring abandonment.

[Arlen]

More details on what is included in the XHTML2 decision, for those interested.

Continuing work:
The XML Events 2 work will probably move over into the Forms group.
The Role and Access modules will probably be pulled into the HTML group.

Uncertain:
CURIE -- Since RDFa currently uses CURIE technology, the fate of this will probably be tied to RDFa. Currently the inclusion of RDFa in the HTML5 spec is under vigorous discussion, so the final fate here is unknown.

Will Stop:
XHTML 2.0
XFrames
HLink
XHTML+MathML+SVG Profile
XHTML Modularization 1.0 Second Edition

@AlexDawson, microformats.org itself says not to use rev in microformats. They give as the reason that it has been misused more often than properly used (citing some Google stats) and say that the use of rev in any microformat except for VoteLinks (which has been officially grandfathered, even though they point out it is an incorrect use of rev) is deprecated and no future microformats should be developed using it. Note please nothing about this decision was caused by HTML5 (though some of the research that people on the HTML5 list used is cited) and in fact the microformats decision was cited by some in the discussion around rev on the HTML5 list.

@felgall, your reaction is noted, and expected. I wonder would it change your mind at all if you were to see the HTML5 authoring spec, instead of the user-agent spec?

Nobody is saying HTML5 is perfect. I've been having a pretty strong discussion about the absence of the di element, which I'm almost certain to lose, BTW. But the W3C has recognized that the XHTML2 fire is burning low, so here we are.

What else do we anticipate/dread?

There's the video codec wars, maybe. What else?

[felgall]

I wonder would it change your mind at all if you were to see the HTML5 authoring spec, instead of the user-agent spec

Does the author spec say that tags deprecated in HTML 4 have now been removed and no longer exist and that all the tags where the useragent spec says the meaning has changed have in fact still got only their HTML 4 meaning? If so then maybe I would change my mind but then if that is the case then surely the useragent spec should be updated to remove those inconsistencies.

Also does the authoring spec remove all reference to doctype as part of the HTML 5 spec and specify that an SGML doctype should be used instead.

[Arlen]

Does the author spec say that tags deprecated in HTML 4 have now been removed and no longer exist and that all the tags where the useragent spec says the meaning has changed have in fact still got only their HTML 4 meaning? If so then maybe I would change my mind but then if that is the case then surely the useragent spec should be updated to remove those inconsistencies.

To the first part of that question the answer is, for the most part, yes. The user agent spec tells the user agent how to handle lots of things that the author spec says shouldn't be done. But there are some exceptions to this, yes.

For the second part of that question the answer is, again for the most part, no. "Strong" now means important, not strong emphasis, etc.

Also does the authoring spec remove all reference to doctype as part of the HTML 5 spec and specify that an SGML doctype should be used instead.

Nope, it pretty much says the same thing the UA spec says, which is that since the doctype is only used by user agents for switching between standards and quirks mode, it must be present in HTML5 to ensure the user agent is in standards mode. It also says only one DOCTYPE should be included, no matter if the document is html or xhtml. In the case of the document being served as an xhtml MIME type, the doctype should be a valid xhtml doctype, including IIRC a reference to a custom DTD you have written, if such be the case, or one on the w3.org servers. (No, there isn't an XHTML5 DTD. Since the spec isn't yet frozen it would be silly to generate one, now wouldn't it? Will there ever be one? Frankly I don't know, but what I've read in the specs makes me think there will be at some point in the future.)

[felgall]

Nope, it pretty much says the same thing the UA spec says, which is that since the doctype is only used by user agents for switching between standards and quirks mode, it must be present in HTML5 to ensure the user agent is in standards mode. It also says only one DOCTYPE should be included, no matter if the document is html or xhtml.

So HTML 5 is still abandoning decades of development of markup languages through SGML and is going its own way.

The doctype isn't there for switching between standards and quirks mode - even though UAs use it for that purpose - it is there to identify the what standard the markup language follows and this change is basically saying lets ignore the standards in developing HTML 5 and create something that doesn't follow the markup language standards.

[AlexDawson]

@AlexDawson, microformats.org itself says not to use rev in microformats. They give as the reason that it has been misused more often than properly used (citing some Google stats) and say that the use of rev in any microformat except for VoteLinks (which has been officially grandfathered, even though they point out it is an incorrect use of rev) is deprecated and no future microformats should be developed using it. Note please nothing about this decision was caused by HTML5 (though some of the research that people on the HTML5 list used is cited) and in fact the microformats decision was cited by some in the discussion around rev on the HTML5 list.

While it's usage has been deprecated I still feel sorry for its loss as there is no replacement in its place which accurately reverses the relationship from the resource to the website rather than the website to the resource. Being able to describe two way relationships within anchors had some real potential for semantically linking chains of documents but alas, I guess that is something to be addressed at a different point in time.

[Arlen]

While it's usage has been deprecated I still feel sorry for its loss as there is no replacement in its place which accurately reverses the relationship from the resource to the website rather than the website to the resource. Being able to describe two way relationships within anchors had some real potential for semantically linking chains of documents but alas, I guess that is something to be addressed at a different point in time.

Right. And in the meantime you can still describe that relationship, by inverting the words and using rel. For a simple example:

rev="owns"

is the same relationship as

rel="owned by"

So, we get the same old players (me, Alex, and Felgall) with the same old points (excepting Alex, the only one of us with something new to say). I was hoping we could find something new to pass on to the working group, since it's clear now what the next version is going to be.

@felgall, I can understand your affection for SGML, really I can. But here's the problem. No matter how many times SGML has been put into the past specs, the makers of user agents have declined to implement it. Over and over again. And there's no reason to suppose if it were to be put in the specs again this time would be any different. So the choice seems to be putting it in again, and having it be ignored just like it has been every other time, or accepting that situation as reality, and putting into the spec something the user agents *will* support. If you have a third option, I'd love to hear it. If there were a good business case for implementing SGML in the user agents over what's currently there, it hasn't been presented well enough yet. If you can do that, again, I'd love to hear it.

You've repeatedly said they were throwing away decades of knowledge about parsing languages, but you've never once come up with a concrete example of how the spec does that beyond "it's not SGML." That forces me to the conclusion that you somehow think SGML is the only possible way to parse a markup language. I wish you well in your continuing search for something that parses either XHTML or HTML as SGML; if you find it, give a shout; I'd like to have a real-world example to compare the specifics of the HTML5 parsing model with, so I can figure out what's been lost, because so far I haven't seen it.

Let me conclude, if anyone's still reading this at this point, with an observation from other development languages. There are rigid languages, like Pascal and java, which some people have used to build wondrous things. And there are looser languages, such as C and Ruby, which other people have used to build wondrous things. Things like dynamic or static typing are each useful, and can each be used to good effect. Some characteristics of the language matter less than some characteristics of the human using it.

No language can please everyone 100%. HTML5 is no different. There are parts of it that bug me. I'd love to get the video codec war settled, but that ain't gonna happen anytime soon. I'd like to make sure the most important bits of the language are smoothed out; I can adapt to the rest.

The point is, perfection is impossible, so I'm out to get the best I can get, because if the past is any indicator, I'll have to live with the result for probably the rest of my web building career. HTML5 is different; it requires a different mode of thinking. Sometimes different is worse. Sometimes different is better. Sometimes different is just....different.

To ensure this goal, I'm trying to get feedback on what is good and what may have been lost, forgotten, or just badly screwed up. Chime in.

[AlexDawson]

Well I don't know if this is relevent but I would like to propose a new inline element for expressing content as being out of context (perhaps <ocxt>). While we have elements which explain context (acronyms being a prime example) we don't have anything to denote something is taken out of context (whether humour, sarcasm or opinion). For the purposes of the semantic web I could see some use for such an element to separate factual from opinionated content and in terms of attributes it could support rel (nature of the context) and cite (if the statement was made in relation to expressed work).

[Stomme poes]

I would like a <rant> tag, personally. <ocxt> = oxycontin to me. If I were more dyslexic it would say something about roosters.

I guess this is the sort of thing one gets when you try to write some standards, some specs, and then go call them "guidelines". "Guidelines" means "suggestions". Remember when seat belts were just suggestions? 80% of drivers didn't use them until someone could give them a fine for driving without.

If HTML5 came with its own corps of jack-booted storm troopers then maybe everyone will play ball. There's this funny idea I have in my head, where Microsoft goes along with the other vendors and makes this spec and everything, and then at the last minute implements something entirely different. Where did I get this idea from? It's so strange.

[AlexDawson]

Well a rant would be out of context of the main discussion so I guess that could fall under the element, I just think there would be a use for the tag, everyone jokes about wanting <sarcasm> or <rant> or something similar, having an element to split the difference betweem context amd otherwise would be useful to give the content itself more semantic meaning.

[SpacePhoenix]

With that news, is XML now dead in the water? Many sites use XHTML1, will they have to migrate to HTML5, could we end up with half of sites going with XHTML1 and half going with HTML5, how many will bother migrating to HTML5?

[AlexDawson]

SpacePheonix...

Firstly, XML and XHTML are different languages, you should not confuse them, XML is not dead and will not die for a long time as there are many hundreds of other extensions based on the language which remain in use such as RSS, Atom, OpenOffice documents, Microsoft Office 2007 ODF, XAML, SVG, and more (to name but a few of the thousands).

Secondly 99&#37; of all websites claiming they use XHTML are not doing so in the slightest, they may have the doctype but they are not using the correct MIME type which is an explicit requirement of the specifications, without that application/XHTML-XML it is not XHTML, it is simply HTML pretending to be XHTML, not only this but if it was decalred properly no-one in Internet Explorer (any version) could see the page.

[felgall]

With the way XML has expanded to cover documents in just about every area imaginable why doesn't the new HTML5 standard use an XML structure but allow the page to be interpreted as HTML in antiquated browsers.

The future of documents seems to be SGML/XML for everything except the web. Why should the web be the exception?

[jamesicus]

With that news, is XML now dead in the water? Many sites use XHTML1, will they have to migrate to HTML5, could we end up with half of sites going with XHTML1 and half going with HTML5, how many will bother migrating to HTML5?

Well, many sites do use XHTML 1.0 alright, but they are really HTML sites (XHTML served as text/html) so XML isn't in play for them.

James

[felgall]

Well, many sites do use XHTML 1.0 alright, but they are really HTML sites (XHTML served as text/html) so XML isn't in play for them.

James

It is if the web version of the document is only one of the dozen or more different versions of the same document being used in various different XML formats for different situations (perhaps with XSLT being used to dynamically convert between the different formats).

XML only doesn't come into play for web only documents but if you want to be able to convert documents for multi-use then XML is the obvious way to go because just about all the different places wherte documents are used now support an XML format (except for the web).

[jamesicus]

It is if the web version of the document is only one of the dozen or more different versions of the same document being used in various different XML formats for different situations (perhaps with XSLT being used to dynamically convert between the different formats).

XML only doesn't come into play for web only documents but if you want to be able to convert documents for multi-use then XML is the obvious way to go because just about all the different places wherte documents are used now support an XML format (except for the web).

Then you just write XML documents -- you don't need XHTML.

James

[felgall]

Then you just write XML documents -- you don't need XHTML.

James

But XHTML is the version of XML intended for the web. Perhaps we should just start serving all our XHTML as XML instead of XHTML and dump HTML completely. That would make web documents compatible with everytrhing else.

How do the various browsers go with using CSS to style XML documents?

[AutisticCuckoo]

How do the various browsers go with using CSS to style XML documents?

Contemporary browsers do it well. Even IE5.5 can do it, if I recall correctly, although no IE version supports XHTML so you'll have to add a lot of rules to emulate the default rendering of XHTML elements. And since IE7 and below don't support the table-related display values you'll have some serious trouble with tables.

[SpacePhoenix]

In what way does IE not support XML? I can view XML files perfectly fine in ie7. Is anyone aware of a simple site that serves XHTML as text/xhtml which i can see how well they render?

[felgall]

Contemporary browsers do it well. Even IE5.5 can do it, if I recall correctly, although no IE version supports XHTML so you'll have to add a lot of rules to emulate the default rendering of XHTML elements. And since IE7 and below don't support the table-related display values you'll have some serious trouble with tables.

So once we can ignore IE7 and earlier the way forward with XML will be a workable one and if IE9 changes rendering engine and starts supporting XHTML properly then it will be even more practical and everyone creating documents for use in various places including the web will be able to use XHTML propperly and forget about the HTML5 dead end leaving it for those whose only concern is documents on the web.

[jamesicus]

In what way does IE not support XML? I can view XML files perfectly fine in ie7. Is anyone aware of a simple site that serves XHTML as text/xhtml which i can see how well they render?

I don't understand the content type text/xhtml? Anyway in case you meant rendering XML as in application/xhtml+xml a very simple RDF/XML file is my Web Authoring References & resources RSS Feed (validation output for ease of viewing structure -- scroll down to view source code). Now go to http://jp29.org/pprss.rdf (XML content) .....

If you are using a Firefox Browser the feed output will be rendered

If you are using an Opera Browser the feed output will be rendered

If you are using a Safari Browser the feed output will be rendered

If you are using a K-Meleon Browser the feed output will be rendered

If you are using an Internet Explorer Browser the feed output will not be rendered -- you will be presented with a download file.

(Google also -- Microsoft incorporation you know)

BTW, As outlined in the IE Blog their browsers now skip the XHTML prolog if present and render the page in strict compliance mode -- they simply will not render any XML.

James

[SpacePhoenix]

One thing we should keep in mind is that the average user of site will not care how a site is served as long as it works and is useable. They won't care whether it's XHTML or HTML5. I've noticed that some big sites don't bother with a Doctype

[AutisticCuckoo]

In what way does IE not support XML?

IE does support XML. But it doesn't support XHTML, i.e., it doesn't recognise the semantics and doesn't apply a default style sheet, so everything will be display:inline and so on.

Is anyone aware of a simple site that serves XHTML as text/xhtml which i can see how well they render?

There is no such MIME type as text/xhtml.

XHTML should preferably be served as application/xhtml+xml, which isn't supported by IE. It is also acceptable to serve it as application/xml or text/xml, which IE supports, but since it doesn't recognise the XHTML namespace it will treat it as generic XML.

You can try it yourself. Create an XHTML document and save it on your hard drive as, e.g., text.xml, then open it in IE.