Burningbird

Proving that the issues with extensibility will never go away until faced, and resolved:

• Anne van Kesteren: Concerns that HTML5 does not have distributed extensibility. That is, namespaces. What people seem to want is to extend the browser with hundreds of markup languages. (How this keeps things simple to answer was not something I saw addressed.) You need something else than namespaces for that though, to start with. Also, what is wrong with using XML for this?
• Sam Ruby: It seems that the distributed extensibility discussion won’t go away like apparently some would hope it would [...] It occurs to me that Anne may be intentionally being thick here. what is wrong with using XML for this? Come on. I can answer that with two words: IE, and Postel. Next question?
• Dave Orchard: While I agree with Sam's assertion that misdirection is going on and IE8 is crucial, I think the real issue is that the anti-distributed extensibility crowd want control over all the languages that could be added into HTML. There's no changing XML that would make them happy. I think the goal is that the HTML WG becomes the gatekeeper over any new languages that get added into the browser. We've seen it with aria-, SVG, MathML. Note that IE8 has a form of namespaces, and Chris Wilson was a supporter of distributed extensibility on the HTML WG list.

I'm not sure we need another form of namespaces. What we need is to address the concept of extensibility, without looking at the mechanics. Is extensibility good? Years ago, I would have been puzzled at even asking this question. Of course extensibility is good. Now I'm not sure that this opinion is shared by one and all. So, perhaps we should ask, Is extensibility bad? From the answers, we might find out where the problems exist, and maybe generate a dialog that results in solutions.

Tina Holmboe from the XHTML WG has written a concise overview of XHTML titled XHTML—Myths and Realities. She's provided a nice overview of the markup, including the purpose behind the development of XHTML and the state of XHTML today. The only somewhat jarring note I found about the overview is it seems that Tina went a bit out of her way not to sell XHTML. Perhaps this seeming "you should really need it before using it" push is the reality part of the topic.

I use content negotiation for my sites, serving up XHTML for those browsers and agents that can process XHTML, and HTML for the rest. I'm looking into embedded RDFa into my text in a new iteration of yet another site design, but my main reason for using XHTML is that I like to keep open the possibility of using inline SVG. I also think that support for XHTML seems to be broader than is implied by Tina, but again that could be her trying to downplay any hyperbole about XHTML—there's hyperbole about XHTML?

Though I know this is outside of Tina's overview, I would have like to have more focus on the differences between the HTML5/WhatWG stuff and XHTML 2.0. It's confusing that we have one group working supposedly on an "XHTML 5.0", and another on XHTML 2.0. Especially when one of the main issues to do with XHTML 2.0 was XForms, while a milestone reached with HTML5 recently was the incorporation of Web Forms 2.0—but don't let the "forms" that appears in both fool you into thinking we have any form of consensus or agreement.

Where I focused on Ian Hickson's statement about extensibility, every other person, and their brothers, sisters, and aunts are throwing a hissy because of the HTML5 timeline.

Scott Gilbertson writes:

Even if your 2022 ronc-o-matic web-enabled toaster (It slices! It dices! It browses! It arouses!) does ship with Firefox v22.3, will HTML still be the dominant language of web? Given that no one can really answer that question, does it make sense to propose a standard so far in the future?

Jeff Croft writes:

I’m not saying the specs should go away. They absolute serve a purpose. I’m just saying that I personally am done paying much attention to them. Instead, I’m reading blogs like Surfin’ Safari and Mozilla Developer News to find out what the new shiny is in browsers, because these are the things I can actually take advantage of in serving my clients and users.

And?

So?

Specification work was never focused on the end users, it's focused at the user agents or others who have to implement the specifications. The Mozillas, Apples, Operas, Microsoft, et al. The only reason I pay attention to any of it is because of my concern about extensibility.

In the meantime, the new stuff that is HTML5 is leaking into browsers now, not years from now. That's part of the specification process—actual implementation on the street in order to "proof the spec", as it were. And pieces of HTML5 are not just showing up in Firefox, Opera, and Safari/WebKit— IE8 has a few HTML5 tricks up its sleeve.

Heck, HTML5 isn't the only longish spec under development. CSS 2 started in 1998, the lost call for CSS 2.1 was in 2002, the candidate recommendation was in 2007, and Microsoft is only now providing CSS 2.1 support. That's ten years, end to end.

In the meantime, I'm using CSS3 stuff that's only supported by a couple of browsers, and the final release of all the CSS3 bits is probably years out, too. Of course, I only play around with my own spaces—professional web designers and developers know that we can't necessarily use the shiny new stuff for client applications, because we're still having to support browsers that are seven years old.

Hey! We're still supporting browsers almost as old as the timeline when HTML5 will be finalized! I guess things aren't as "today" and "now" as we think they are.

The point is, specifications take time, or at least, good specifications typically take time. Any doofus can toss a quick spec out and call it done, but who wants to use the doofus spec?

That schedule part of what Ian had to say didn't phase me. As far as I'm concerned, the group can take as long as it needs. In the meantime, I'll play around with the local storage, and some of the other odds and ends, as I keep putting in my annoying "But what about SVG?" "But what about RDF?" oar; probably helping to slow the development of the spec, even more.

In an interview at Tech Republic, HTML5 Editor Ian Hickson stated:

The second big controversy in recent history was over extensibility. There have been some requests to allow people to extend HTML without speaking to the committees working on HTML. We’ve provided a number of mechanisms for this (the class and rel attributes, the data-* attributes, the meta element for page-wide metadata, the script element for non-script data blobs, the embed element for plugins), but some people simply want the ability to invent their own elements and tag names. So far, we’ve managed to avoid that, and we’ll have to see if we can continue.

Yes, but we've still not resolved—at least, I'm not aware of any resolution—about how to incorporate MathML, RDFa, and SVG into HTML5. I can't help thinking we've spent more time trying to prohibit extensibility than we would if we just provided the mechanism.

In addition, I'm frankly confused about how we'll pull off a consistent model between HTML5, which is rigidly inflexible, and XHTML5, which is anything but. If what's incorporated into HTML5 differs from what's allowed in XHTML5, do we just...wing it?

The whole point of XML years ago was because of issues like this—how do we create a markup that can be extended without having to update the underlying specification/model with each new addition. Ever since, we've been running in horror from the Yellow Screen of Death—the negative aspect of XML we fixate on—while arguing, endlessly, about extensibility—the most beneficial aspect of XML. I can't help thinking that we should keep the extensibility and just get rid of the Yellow Screen of Death.

However, I'm not expert in these things. I am just a humble web developer, with simple needs. One such need is I don't want to lose what I have now.