Please change the subject as appropriate.
On Sun, 04 Sep 2011 18:49:02 +0200, Charles Pritchard <[email protected]>
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/
