- 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
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:53 UTC