Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

> 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

Received on Thursday, 1 July 2010 02:08:53 UTC