W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2011

[DOM] Extensibility

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 05 Sep 2011 16:41:13 +0200
To: "Doug Schepers" <schepers@w3.org>, "Charles Pritchard" <chuck@jumis.com>
Cc: public-webapps <public-webapps@w3.org>, "Adrian Bateman" <adrianba@microsoft.com>, "Jacob Rossi" <jrossi@microsoft.com>, "Arthur Barstow" <art.barstow@nokia.com>, "Chaals McCathieNevile" <chaals@opera.com>, www-dom@w3.org
Message-ID: <op.v1ca2zzq64w2qv@annevk-macbookpro.local>
Please change the subject as appropriate.

On Sun, 04 Sep 2011 18:49:02 +0200, Charles Pritchard <chuck@jumis.com>  
wrote:
> 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  
recently.


> 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
http://annevankesteren.nl/
Received on Monday, 5 September 2011 14:41:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT