

HTML Nerds: Read the Distributed Extensibility Proposal from Microsoft - evdawg
http://lists.w3.org/Archives/Public/public-html/2009Sep/att-1216/MicrosoftDistributedExtensibilitySubmission.htm

======
hellotoby
The problem I have with this, is that the examples provided, e.g.

 _A HTML document editor adds information about tool settings so that a
subsequent editing session can continue with the same settings._

 _A JavaScript library processes custom tags in a browser and turns them into
custom controls dynamically on the page._

 _A browser wants to allow custom behaviors to be defined in one module and
attached automatically to custom elements._

 _An author includes processing instructions in the document that will be
processed by a server before delivering the document to a user agent._

 _An author runs a tool on a document to add numbering to headings and a table
of contents. Running this tool leaves custom metadata tags intact._

can already be pretty easily achieved with the technology we already have.

I don't really see the need for namespaces in HTML. If you need custom tags
and attributes surely you are better off going straight to XML and then
parsing your data in any number of ways that are already available (XSLT,
Javascript, PHP etc. etc.)

~~~
mbrubeck
I'd agree with this if we were designing something in a vacuum, but XML
namespaces already exist, and HTML-only browsers already exist. It's a pain to
have this mechanism available in XHTML only. To illustrate why, I think I have
a better example than the ones from the proposal:

If you want to use just one namespace-based extension like MathML, then you
have to make the whole page XHTML. That changes the way CSS and JavaScript
work. It turns previously-uncaught syntax errors into site downtime. It makes
legacy browser support more difficult (because, for example, the DOM API is
incompatible between browsers that support XHTML and ones that don't).

This proposal would allow me to use HTML for my entire site so that I can
support legacy browsers reasonably, but also add inline MathML to some pages
for browsers that support it, while using the same stylesheets and scripts
across all pages.

It also lets me use namespace-based extensions within content management
systems where I don't control the doctype, and it generally improves the ease
of moving or sharing content between XHTML and HTML web sites.

~~~
thristian
That's a pretty good example... except that HTML5 already requires that
browsers support SVG and MathML elements in HTML documents without any
namespacing at all.

The other problem with adding namespaces to HTML for machine metadata is that
HTML5 already supports arbitrary opaque content in attributes whose names
begin with "data-". Sure, it doesn't solve the extensibility problem as
thoroughly as namespaces would, but it takes a good bite out of Microsoft's
use-cases, and maybe the 80% solution is Good Enough.

------
megaduck
In the abstract, I like the idea of HTML namespacing. However, their proposed
implementation gives me a nasty feeling in the pit of my stomach.

It seems that this proposal would contort HTML to better accomodate XML data,
just as other interchange formats like YAML and JSON are taking the stage.
Also, a lot of the scripting advantages are already taken care of with HTML 5
custom data attributes. I just don't see the need.

Plus, some of these changes would seriously break compatibility with legacy
parsers. The only purpose for this proposal seems to be making life easier for
Microsoft programmers.

------
akamaka
Sounds nice in theory, but then again, so do most proposals about making stuff
more extensible.

There's more examples out there of how extensibility went wrong rather than
right. (for example, OpenGL 1.x extensions vs. Direct3D's continually updated
core API)

With this kind of proposal, I'd be more convinced if I was presented with
practical arguments based on how real people and organizations would use the
extensions, rather than theoretical technical advantages of slightly different
approaches.

~~~
mbrubeck
We've had several years of experience with the proposed extensibility syntax,
since it's taken directly from XML 1.0 (and XHTML 1.0). Some common real-world
uses include SVG and MathML on web pages, and Creative Commons license data
(using RDFa) for HTML documents.

The main reason for this general approach is that it works with current (and
future) XML vocabularies like SVG.

~~~
akamaka
I see.

I'm under the impression that Microsoft doesn't support SVG in IE for
political and competitive reasons, and that this proposal isn't going to
change that, so I really don't see the point.

I guess I don't really know how proposals like this help move things forward.
I'm just your average web developer frustrated by the lack of progress in
compatibility between browsers.

------
onewland
This seems like it could so easily be used for evil.

It literally seems like they're requesting their own custom, proprietary
extensions on HTML builtin to the standard.

~~~
mbrubeck
They're requesting the ability for _anyone_ to extend the standard without
risking incompatibility with future versions—in exactly the same way that
anyone can _already_ extend XHTML 1.0 and XHTML5.

It's not just Microsoft. Sam Ruby of IBM has been requesting it since 2007
when he made a very similar proposal:
[http://intertwingly.net/blog/2007/08/02/HTML5-and-
Distribute...](http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-
Extensibility)

Sam was appointed co-chair (with Chris Wilson of Microsoft) of the HTML
working group in January 2009, and I expect he'll be a prominent supporter of
some version of this proposal. But the primary editor of HTML5 (Ian Hickson of
Google; his co-editor is David Baron of Apple) has so far preferred more
limited additions that address specific use cases, such as the "data-"
attributes in current drafts, or hard-coded support for specific W3C
vocabularies like SVG. His reasons are similar to yours; he hopes that by
forcing all extensions to go through the HTML working group, the W3C might
prevent implementors from fragmenting HTML into mutually incompatible
dialects.

