Re: Deprecated vs. obsolete

Hi, Krzysztof-

Krzysztof Maczyński wrote (on 9/19/09 4:54 PM):
>
> In the first sentence I stated that I was going to suggest deprecation
> (in the other sense, whose understanding outside this ED and usefulness
> also for this ED I expounded) applied to something in addition (indeed,
> I already did in [1]).

I am not convinced that this is a compelling enough use case to account 
for... the 'click' event is a pretty crazy and krufty legacy feature, 
but it's just not going to go away.  I have no intentions to deprecate 
it (in any sense of the word), and I suspect the implementers would find 
it laughable if I did anyway.

I could define it better, if that helps.  I could even add some detail 
to allow authors to distinguish between user-generated and synthesized 
clicks, if implementers would agree to that.

If you want to introduce a new clickish event, you'll have to come up 
with use cases that can't be solved with the existing 'click' event... 
and a better name than 'click2', which is a little too close to 
'dblclick'. :)


> In the second part I concurred with the need for the notion that currently
> the ED uses the term deprecated for, including a paraphrase of part of
> that definition. Above I argued that it be called obsolete instead of deprecated.
> HTML5 is not a good example because, if I recall correctly, the word deprecated
> was deemed politically incorrect when it was decided not to use it, so
> I didn't take HTML5's usage of obsolete into account.

I find it hard to believe that the editor of HTML5 was being politically 
correct. :)


>The Wikipedia article
> says "Although deprecated features remain in the current version (…) deprecation
> may indicate that the feature will be removed in the future. Features are
> deprecated—rather than being removed—in order to provide backward compatibility",
> so, as I understand it, it's exactly like I wrote - MUST implement, SHOULD
> NOT use.

I interpret it like this:
"Although deprecated features remain in the current version *of the 
specification* (...) deprecation may indicate that the feature will be 
removed in the future *versions of the specification*."

Though we strive for interoperability, there is a distinction between 
W3C Recommendations and implementations, and the definition of 
"deprecated" refers to the spec, not to the implementations.

The spec has to account for multiple independent implementations, so not 
all features of DOM3 Events are going to be implemented in all 
browsers... the compromise we have struck is to mark those that we know 
won't be universally implemented as deprecated, while still retaining 
them (in this version) to legitimize and promote interoperability for 
those implementations that do continue to support those features.


>  I didn't oppose to deprecating (or, as I would prefer it to be
> called in, obsoleting) anything in particular. Although I have my doubts
> whether a decent replacement for mutation events is being produced. Have
> you got any specific work in progress on your mind?

There has been some email discussion about this, and I believe Microsoft 
is working on a proposal for it.  It would not be based on events, but a 
more lightweight mechanism that would allow for better performance.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Saturday, 19 September 2009 21:43:05 UTC