Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 10:49 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson <ian@hixie.ch> wrote:
>> Hear hear. Indeed, a large part of moving to a "living standard" model is
>> all about maintaining the agility to respond to changes to avoid having to
>> make this very kind of assertion.
>
> See http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg232
> for why we added a warning to the specification. It was thought that
> if we made a collective effort we can steer people away from depending
> on this. And I think from that perspective gradually phasing it out
> from the specification makes sense. With some other features we take
> the opposite approach, we never really defined them and are awaiting
> implementation experience to see whether they can be killed or need to
> be added (mutation events). I think it's fine to have several
> strategies for removing features. Hopefully over time we learn what is
> effective and what is not.
>
> Deprecation warnings have worked for browsers. They might well work
> better if specifications were aligned with them.

I generally agree with Anne here. As a browser developer it is
frustrating when attempts to remove old "cruft" from the web is met
with pushback from authors with the argument "you can't
remove/deprecate this features because the spec says that this feature
must be there".

Obviously many authors are just using this as an argument when what
they really mean is "you can't remove/deprecate this feature because I
use it".

However I've also noticed that it's true that authors are much more
willing to deal with features being removed when they know it's not
happening on the whim of a single browser vendor, and that it might be
reverted in the future, but rather that it's an agreed upon change to
the web platform with an agreed upon other solution.

I also don't think that simply updating a spec once multiple browser
vendors have removed a feature helps. It's the process of removing the
feature in the first place which is harder if the spec doesn't back
you up.

But possibly this can be better expressed than what's currently in the
spec. I.e. if we say that the feature is deprecated because it leads
to bad UI, and that since the expectation is that eventually
implementations will remove support for the feature it is already now
considered conformat to the spec to throw an exception. However many
websites still use the feature, so implementations that want to be
compatible with such websites need to still keep the feature working.

/ Jonas

Received on Wednesday, 3 September 2014 21:10:11 UTC