[DOM] Extensibility

Please change the subject as appropriate.

On Sun, 04 Sep 2011 18:49:02 +0200, Charles Pritchard <chuck@jumis.com>  
> It seems to me that the following section documents DOM Core's proposed  
> improvements to DOM3Events:
> http://www.w3.org/TR/domcore/#dom-events

It probably requires some updates at this point, I have not re-reviewed it  

> What are the current restrictions in Event.type that are concerning you?  
> As I understand it, there is no normative list for event types, though  
> vendors -may- restrict them. There are strict restrictions for  
> null/empty string types.
> http://www.w3.org/TR/DOM-Level-3-Events/#event-types

Those were it. A previous draft had whitespace restrictions as well. I  
think this distinction is gone with the latest draft of DOM Level 3 Events.

> I do see that in 9.2, DOM Core attempts to clean-up some older  
> namespaces. "Implementations conforming to this specification will not  
> support them".
> That seems to me, the primary reason for labelling DOM3Events as  
> "obsolete".
> Is it common for a specification to explicitly state that conforming  
> implementations will -not- support legacy specs?

It seemed better to be explicit. HTML has some notes to that effect as  
well. E.g. http://www.whatwg.org/C#dom-head-profile

> There's this bit of related text as well:
> "Vendor-specific proprietary extensions to this specification are  
> strongly discouraged. Authors must not use such extensions, as doing so  
> reduces interoperability and fragments the user base, allowing only  
> users of specific user agents to access the content in question."
> That seems in conflict with the following, in the mutations section:
> "We encourage experimentation with that proposal, as well as alternative  
> proposals"

That first section also says: "If vendor-specific extensions are needed,  
the members should be prefixed by vendor-specific strings to prevent  
clashes with future versions of this specification." So I think we are  
fine here.

> I understand DOM Core to be encouraging a tidy and easy-to-use API. It  
> does not seem to leave room, with some of these statements, for legacy  
> compatibility, nor much experimentation.

We want backwards compatibility to the extent that is needed for deployed  
content. If not needed, it is better to remove the attribute/method. If it  
turns out we were to aggressive we will get feedback and the feature will  
be added back in.

Anne van Kesteren

Received on Monday, 5 September 2011 14:41:53 UTC