I mean that like they should be treated as completely separate coding languages. The added attributes and tags in HTML 5 should also be added to XHTML. Both should be well-formed, just that HTML 5 documents should be coded using the SGML format, while XHTML pages use the XML format.

That’s pretty much it.

However, that said, I actually think the best approach would be to use Modularization for everything. Rather than just remove current style forms, allow the use of an XHTML 5 Forms module, along with a core XHTML 2.0 module. Namespaces should be supported everywhere.

The whole “keep XML off the web” part is the biggest mistake I’ve ever seen. We should be keeping TagSoup off the web, and focusing on moving entirely to an XML-based web.

With XML Namespaces and other such technologies, content authors should be able to pick which models they use. The two places where this is most important is having support for existing style Forms, and scripts. Allowing every tag to have an href and src attribute is a welcome change, blowing away the presentation-specific tags is a welcome change. I do like the HTML 5 forms, as XForms seem overly complex for simple pages. XForms and XML Events should be optional modules, with XHTML 5 Forms and Scripts support available as well.

So I guess what I’m really recommending, is taking the good stuff from HTML 5, adding better Namespace handling, and releasing XHTML 2 as a fully modular markup language. Continuing to support Tag Soup style HTML is stupid, please let it die!

XHTML 2.0 is rather nice. I’ve been behind it 100% ever since I found out about it.

(X)HTML5, on the other hand, I’m not much of a fan of… I really don’t understand why the canvas, audio and video elements are needed, for example. I’ve seen things like a Mario Kart clone that used JavaScript and the canvas element. Technologies like Flash or Silverlight, however, could have been used to achieve the same result with extra features. No, I didn’t miss the point - proving it could be done without such proprietary technologies - but such a game would run considerably smoother using Flash. As for the audio and video elements, what is wrong with the object element?

I may be missing the point of (X)HTML5, but it doesn’t seem nearly as useful as XHTML 2.0. In addition, (X)HTML5 introduces elements specifically for presentation (canvas, audio, video), something that was supposed to disappear thanks to XHTML, especially XHTML 1.1 and XHTML 2.0.

You’re right, Robert, it’s a nice article

Thanks for your comments!

Still, the HTML5 FAQ should make it clear that having easily parsable (X)HTML is still a long-term goal.

This is somewhat similar to microformats (aka lightweight semantic web) vs. rdf: One is at hand now and usable now but limited, the other is very very promising but it is future.

But then, one day this future will be the current day and today will be past and forgotten. So basically we need both: What we can have and use now, we should use now, but without letting the real future out of sight.

In it’s current state, XHTML 2.0 is virtually impossible to implement. If they go through with their plan to re-use the XHTML 1.x namespace, it will be totally impossible to implement.

Nothing in XHTML 2.0 is well defined. in fact many things are very much undefined.

XHTML2 changes <script> to <handler>. HTML5 just sticks with <script>

XHTML2 reuses <input> for XForms, without using the XForms namespace (so basicallly, xhtml1:input is being redefined in a backwards incompatible way). HTML5, on the other hand, uses incremental improvement and retains backwards compatibility.

XHTML 2.0 adds <h> for headings, retains the numbered (<h1> to <h6> ) headings, yet fails to define how they interact with regards to the structure of the document. HTML5, on the other hand, retains the numbered headings, yets adds the same functionality as XHTML2 in a much more well defined way.

XHTML2 adds href, and other attributes, to almost every element. Browser vendors have reported that this would be extremely difficult to implement, and probably won’t be.

XHTML2 fails to define any error handling, beyond the draconian handling of XML. Error handling needs to deal with more than just syntax errors! e.g. bogus attributes or incorrect values, unknown/unexpected elements, etc.

HTML5 already has many features implemented in major browsers. XHTML2 is not, and will not be, implemented by any major browser.

Basically, HTML5 can do everything that XHTML2 can do, and much more.

2) Predefined sectioning elements are too generic and waste the opportunity to add real domain-specific semantics.

3) Vendors of visual Web browsers have to write code to support new elements even if new elements do the same thing from a visual perspective.

If I understand correctly, sectioning elements carry 2 semantics:

1) This is a section.

2) This section is of type X.

The first is independent of the second but the second is dependant on the first. So you would need a two-part construct to model this relationship. I suggest instead a single element with an attribute. For example:

&ltsection>

and

<section role="navigation">

Or, I suggest using a div element instead of section.

Why is nl better than nav?
The spec defines nav as “a section with navigation links”. If you start adding content into this section like tables and paragraphs, this section bulks up and loses its value to future devices that could use this construct for presenting page navigation in a separate window. And the nl element could be very useful for small screen devices.

Faults in HTML4 and XHTML1 can be fixed.
1) X/HTML 5 does not fix them.

2) If it did fix them, then it would not be backwards compatible.

The more code paths you have in your implementation [of Web browsers] the more development cost and time…
Building an XML rendering engine (like XHTML 2) is much simpler than enhancing HTML rendering engines. I speak from experience. It is so complex to build a good tag soup rendering engine that current Web browser vendors have created a barrier to entry by encouraging tag soup. What is the business incentive for current Web browser vendors to encourage valid markup?

The numbers [in numbered heading] get normalized so it doesn’t really matter which number you use…
If that won’t confuse content authors then I don’t know that will. It’s kind of like Alice In Wonderland where things aren’t really how they appear.

iframe is heavily used by the advertizing industry
So is this the real reason browser vendors and search engines are against XHTML 2? Seriously, we all benefit from advertisement programs on the Web. Programs like AdSense from Google financially supports small content providers, which is great. But currently these programs do not work when content is served as XML. I would hope that W3C addresses the needs of ad providers even if it means adjusting the XML spec. Let’s find a non-iframe solution to this very important issue.

Being backwards compatible does not mean that you have to include all elements the previous version had.
This is objective and I bet one can use “set theory” to disprove this.

It also doesn’t mean you can’t redefine semantics.
This is subjective so we can go back and forth on this for a while.

HTML5 does comply with its charter, but perhaps we have to define backwards compatibility.
Great. I think you will find that X/HTML 5 is “compatible” with HTML 4 and XHTML 1 but not “backwards compatible”. But I hope you will also see that there is no need to be backwards compatible.

font was added because the state of art in WYSIWYG editors don’t yet have a way to deal with semantics
We have been producing a WYSIWYG editor that does not have a font selector or a color picker for over 3 years. It’s not rocket science. If we can do it, anyone can.

it’s better to allow them [WYSIWYG editors] to insert presentational markup when presentation was called for than to try to force the author to use semantics.
When you give a WYSIWYG user a font selector and a color picker, they will use them instead of semantic markup. Accessibility goes out the window

WYSIWYG editors are of course free to deal with semantics and ignore font
Guess what, it’s easier to sell candy than carrot sticks.

WYSIWYG isn’t going away any time soon so ignoring them doesn’t lead to better results.
But that is what the spec does - it ignores WYSIWYG editors by letting them do what they want. I see great parallels between the environmental movement and Web standards. WYSIWYG editors are like the polluters of the Web and spec writers are like regulators. In this case the regulators are looking the other way.

Class names are not CSS class names. They have nothing to do with CSS.
Not if you use the class attribute. The spec “overloads” the meaning of class. And also creates opportunities for conflict with existing documents that use class names that will only be predefined in the future.

If you want to use XML then use XHTML5
Here is the problem. The XHTML 5 spec is saying don’t use XHTML 5 when they say “generally speaking, authors are discouraged from trying to use XML on the Web”. Look, if the authors of the spec feel strongly about this, then they should simply dump XHTML 5. Let’s either treat XML as an equal to HTML or dump it!

The main difference is not the feature set, but the compatibility with existing content on the web, current authoring practice and existing implementations.

With HTML5, you don’t have to change the way you work even when you want to start using the new stuff (i.e. when they’re implemented in browsers). You just start to use the new stuff and it will work.

HTH,

What I don’t understand is; why are these new things specific to either XHTML 2 or HTML 5? Why can’t HTML 5 drop the acronym element too? Why can’t XHTML 2 have cool forms?

All in all I’m a bit skeptical and don’t expect to have to change the way I work anytime soon, ’cause it probably is gonna take ages for browsers (and especially IE) to implement the good stuff.

zcorpan,

I’ve asked Vlad to read your comment.

Implementation Of Sectioning Elements
Why would div with a role be any simpler to implement than elements? With roles you can have situations where a div is all of an aside as the main content and a footer and a checkbox at the same time; that cannot happen with element names.

Why is <nl> better than <nav>? A navigation section isn’t always a list, it could equally well be a table or a paragraph or anything else. <nl> can only be used if you have a list.

How do you suggest we improve sectioning elements?

HTML 4 And XHTML 1 Faults Are Perpetuated Into A Future Spec
Faults in HTML4 and XHTML1 can be fixed.

I don’t understand your view on backwards compatibility. Browsers only have one implementation of HTML, or perhaps two (quirks and standards). The more code paths you have in your implementation the more development cost and time, which is not a good thing. Forcing browser developers to add yet another code path when it can be avoided will probably just lead to the spec being ignored by browser vendors.

The problems of numbered headings have been addressed with sectioning elements. The numbers get normalized so it doesn’t really matter which number you use, indeed you could use <h1> for all your headings just like you would use <h> for all your headings in XHTML2.

<i>, <b> and <small> have been added to address the need of being able to mark up things that have typographical convensions but don’t have specific semantic elements in HTML. Using <span class> for all those cases doesn’t really improve anything. <iframe> is heavily used by the advertizing industry, and it is an interoperably implemented mechanism to embed an HTML document into another. Forcing authors to use a less interoperably implemented mechanism to do the same doesn’t really improve accessibility.

X/HTML 5 Does Not Comply With The X/HTML 5 Charter
Being backwards compatible does not mean that you have to include all elements the previous version had. (User agents are expected to continue supporting the elements it already supports but are not part of HTML5.) It also doesn’t mean you can’t redefine semantics. However, for all intents and purposes, in the case of <i> and <small> an HTML5 UA would pretty much do the same as an HTML4 UA.

HTML5 does comply with its charter, but perhaps we have to define backwards compatibility.

What, The font Element Is Supported?
<font> was added because the state of art in WYSIWYG editors don’t yet have a way to deal with semantics, so it’s better to allow them to insert presentational markup when presentation was called for than to try to force the author to use semantics. WYSIWYG isn’t going away any time soon so ignoring them doesn’t lead to better results. (WYSIWYG editors are of course free to deal with semantics and ignore <font>, though.)

WYSIWYG Signature
This has only to do with document conformance (that WYSIWYG editors are allowed to use <font>). It’s an open issue though, and as with anything else in the spec, it may be changed or removed.

Support For Predefined Class Names
Class names are not CSS class names. They have nothing to do with CSS. Essentially, if I understand role=”" correctly (there are some predefined values and it can be extended), it is the same as role=”" except simpler and it was already present in previous versions of HTML.

As with the role=”" attribute, the issue with multiple values has to be looked at to see if it would cause any problems.

HTML 5 Versus XHTML 5
If you want to use XML then use XHTML5. If you don’t want to use XML then use HTML5. Both are fine. If you want to use both at the same time then you can do that too. You have to jump though hoops to do so but those are the same hoops as Appendix C anyway.

If you think there’s too much to choose from then use HTML5. It is compatible with browsers and search engines, and if you want to use it with your “XML tool chain” then all you need to do is replace the XML parser with an HTML5 parser and the XML serializer with an HTML5 serializer.

A Too Hasty Process
The specs, or at least the WF2 spec, started before the WHATWG was created. HTML5 is not a result of too slow process at the W3C, it is a result of browser manufacturers disagreeing with the vision of the W3C with regards to the future of HTML and web applications. The estimated shedule is 15 years for HTML5 to become a Recommendation — you’re the first to say it’s too hasty. The unrealistic timelines and milestones you referred to are the ones the new W3C HTML WG Charter suggested.

Thanks for the feedback!

Cheers,