[whatwg] HTML 5 vs. XHTML 2.0

Laurens Holst lholst at students.cs.uu.nl
Sun Nov 14 17:45:56 PST 2004

Dean, and all,

Dean Edwards wrote:
> hi all,
> the increased discussion about XHTML2 vs HTML5 has prompted this email.
> some things to consider:
> * HTML5 *extends* HTML4
> * HTML5 should be backwardly compatible with HTML4
> * XHTML2 *improves* XHTML1
> * XHTML2 is not backwardly compatible with XHTML1

Question is: could it be made to be? In other words: are there places 
where there are major incompatibilities with XHTML 1? Currently, I don't 
think so, and even though they do not have backwards compatibility as a 
design goal, it looks like they still considered it (because they kept 
<h1>...<h6> - in the current WORKING DRAFT at least - and also changed 
<q> to <quote>, etc.).

Maybe someone should contact them about their exact intentions and how 
we could co-operate with them once the discussion about this stabilizes 
a little and if we choose to further investigate the use of XHTML 2.

> * HTML4 tags are pretty similar to XHTML1 tags :-)
> a lot of the current discussion arises from the fact that we have 
> labeled our specifications under the umbrella "HTML5". i agree with this 
> but it does lead us to compare/contrast with XHTML2. i think this is a 
> major issue and prompts many questions. how far do we mirror the XHTML2 
> improvements? if we adopt some but not others will this lead to further 
> confusion about web standards? it seems that versions of HTML have 
> already lurched in different directions.

To me, it would be way preferable to just adopt the whole of it.

But if that turns out to be not an option, I'd say it is always better 
to at least partially adopt and copy the naming scheme instead of 
inventing a new one. Because if we do not this will:

1. Lead to even more diverging specs, losing all hope of them ever 
converging at some point in the future
2. Remove any common ground between authors for XHTML 2.0 and HTML 5 
(one of the advantages of HTML is that there's a single set of tags 
which everybody knows)
3. Require page authors to make a choice: 'either do this, and be in 
major ways incompatible with that, or vice versa', causing them to 
choose the most popular of the two (most likely to withstand future 
developments), instead of them choosing one of the specs based on its 
merits over the other, or based on the origin (relatively unknown WHATWG 
vs. W3C). Yes, I'm saying common ground between HTML 5 and XHTML 2.0 
would probably increase the chances of public adoption.
4. I forgot no. 4 :)

> however, extending HTML (especially the Forms module) is absolutely 
> necessary. how necessary are the other discussed changes (<q> vs 
> <quote>)? if we choose <quote> then what about the rest of the XHTML2 
> spec? i think we have to think hard about this before we add to the 
> confusion that web developers have to face.

I read on Ian's web log that he considers 'html 5' as the combination of 
Web Forms 2.0 and Web Apps 1.0 ("which we're half-seriously collectively 
calling 'HTML5'").

I think however that Web Forms and Web Apps should stick to what they 
were meant for - facilities for better forms and better web applications 
-, and that stuff concerning sections, headings, quotes and acronyms 
should belong in a different spec, maybe called Web Markup 2.0 or 
something (you think of a better name ;p). It's starting to look like 
modularization now, isn't it :) (not that bad an idea). *That* could 
then collectively be called HTML 5, I'd say.

> we have the opportunity to 
> clear up some of the existing confusion, with some careful pruning of 
> the original spec (goodbye <acronym>) but how far we go is a question 
> that should be debated thoroughly.

My vote is to create a spec which combines XHTML 2.0 with XHTML 1.1 
(/XHTML 1.0 Strict), deprecating the XHTML 1.0 tags in stead of removing 
them altogether, and making an 'HTML' version of it.

Additionally, it could introduce new tags which seem useful, have a 
proper use case (I create documentation for my company so I could 
probably say whether such a tag would at least be meaningful for our 
technical documentation), and are well-discussed (e.g. the question 
arises whether <file> isn't just another kind of <name>, and whether 
they couldn't just all fall under a better-defined <cite>).

This way, we would be compatible with XHTML 1.0 and 2.0, and we can hope 
for a possible XHTML 3.0 to adopt our additions :). Co-operation with 
the XHTML WG and creating some goodwill (adopting XHTML 2.0 alone, 
causing good browser support, will I think already do that) would 
probably help a lot with that.

> finally, if we do decide to /improve/ HTML does this require another 
> spec? i like the idea of the <name> and <file> elements but which of the 
> current specs do they belong? we need a new document to cover these 
> additions and many of (the discussed) deprecations (if we decide to go 
> in that direction).

I agree wholeheartedly.

If we do not do this, Web Forms and Web Apps should keep their hands off 
stuff like quote and headings, and just stick to what they were supposed 
to do. Because personally I do not care, not at all (as in: wouln't like 
/ prefer not to have), for a specification which introduces new tags 
incompatible with and going in a different direction from XHTML 2.0.

> sorry to be a wet blanket but i had to get these questions off my chest. 
> ;-)



p.s. Why the heck doesn't the WHATWG mailinglist send a reply-to: 
whatwg at whatwg.org header?

Ushiko-san! Kimi wa doushite, Ushiko-san!!

More information about the whatwg mailing list