On 6/29/10 2:36 PM, Chris Wilson wrote:
See, this is exactly why we asked the question - because it seems that behavior is inconsistent, we're not sure what the expectation is.

Note that the Firefox behavior I described is irrelevant to specification efforts, because it's not visible to web pages....

I would really like to know (along the lines of the changed thread title) why other browsers are not, as it appears, interested in making this part of a specification effort.

Although there might not yet be interest to make some official standard for browser add-ons at this point, I would think that in this one crucial area, browsers could consider allowing extension authors and web developers the ability to have a common means, regardless of browser, of communicating back-and-forth in the same "protocol" by using custom DOM events in this way as Firefox currently does. It is no small functionality to allow websites the abiility to communicate with add-ons and in an extensible manner.

Despite being an advocate of open source and open formats myself, I strongly disagree with the sentiment I have heard some express, that the ability to make custom formats within X/HTML, whether through namespaced elements and attributes or processing instructions (both regrettably disallowed by HTML at present, in my view) or by custom DOM events, is only promoting proprietary formats.

On the contrary, I feel that such ability to experiment allows new standards to emerge which meet needs that HTML is not presently willing to implement.

Here are just a few use cases, though the list could really go on and on:
1) Allowing websites to interact with client-side chat clients for real-time collaboration by site visitors (as the Firefox extension SamePlace does) 2) Allowing websites to share and access each other's databases when permitted by the site (or even by the user alone) a) Adoption of more specific shared database formats in a specific genre like the ability to view, schedule, and edit meetings or events 3) Supporting the ability to query XML databases with powerful XQuery and update facilities through the browser.

While it is great that the big browsers have settled on avoiding too extreme a competition with their own new markup, going through standards bodies at least in cases like <video/> where there is no need for 1000 different ways to express the markup (even while the case could be made for allowing 1000 different namespaced attributes on the tag until standardization is complete), smaller sites or special interests if not bigger organizations as well, still need the ability to innovate. The web will clearly not settle for perpetually proprietary formats anyways, except in cases where the standards have not yet caught up. And "proprietary" here is a relative term since the underlying platform (DOM/XML) is still itself standardized.

Better to give the means for innovation in the first place but in a way which can be made to work cross-browser, rather than shut the door and treat web innovators and users paternalistically if not outright domineering them by maintaining exclusive control in the name of their supposed interest. While it is great that web authors have not been precipitously forced to use XML, it is a pity, in my view, that the extensibility of XML has not been carried over and embraced, even if a co-editor of XML himself (reasonably) suggested avoiding creating new dialects where possible. Please give us at least one means of extending functionality beyond what you currently happen to support or want to support...

Brett


Reply via email to