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

Re: remedy for click event

From: Doug Schepers <schepers@w3.org>
Date: Sun, 20 Sep 2009 05:04:43 -0400
Message-ID: <4AB5F02B.1010406@w3.org>
To: www-dom@w3.org
Hi, Anne-

Anne van Kesteren wrote (on 9/20/09 4:39 AM):
> On Sun, 20 Sep 2009 02:07:10 +0200, Doug Schepers <schepers@w3.org> wrote:
>> For reasons I've already stated, I respectfully disagree with your
>> interpretation of "deprecated", and I don't intend to apply it in the
>> case of DOM3 Events. While I am writing the spec for both authors and
>> implementers, the implications of deprecation most directly impact
>> implementers. I already use the term "deprecated" in what I see as a
>> specific and pragmatic approach throughout the spec, and unless I hear
>> from implementers that they disagree with that use, I'm not going to
>> change it.
>
> FWIW, I do find it somewhat confusing. I'm mostly familiar with this
> term due to HTML4 and there the end result was that UAs had to implement
> the deprecated features. This might not be the meaning HTML4 gave to it,
> I wouldn't know, but that is what it effectively meant.

I suspect that was more of a market decision by browsers than a matter 
of specification conformance.


> I haven't checked the new DOM3 Events draft yet, but if not done so
> already, maybe explicitly indicate for each deprecated feature that it
> is also OPTIONAL for UAs to implement.

I've steered away from explicitly labeling features "optional", because 
I didn't want to have a spec with optional features, especially for test 
suite purposes.  But, effectively, I admit that I do intend the 
deprecated features to be optional for new implementations.  Sigh.

Obviously, this is ultimately up to the working group to decide.  I link 
to the definition of "deprecated" for every deprecated feature, and that 
definition describes it pretty explicitly.  I suppose I could duplicate 
that for each deprecated feature, but I'd like to think it's not necessary.


> Having said that, while such an approach certainly works, I would
> personally prefer it if in the end we had a specification that does not
> include the optional features or explicitly excludes them from certain
> conformance classes, or something like that.

I could define a conformance class that does not include deprecated 
features.  That seems reasonable, and I think some implementers would 
like that idea... they can still claim to be conforming, while not 
implementing those features.

What do people think?  Should I do this?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Sunday, 20 September 2009 09:04:52 GMT

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