Re: DOM3 Key events

>>>
>> There seem to be only three options: a) we do not standardize in the
>> area, b) we standardize whatever is implemented, c) browser vendors
>> change their browsers, probably sacrificing web site compatibility in
>> the process.
>
> I don't think A is a realistic choice.  We have this mess now  
> because it wasn't standardized.
Agreed.

> B is only possible if there is already interoperability, since  
> anything else means that at least one browser will have to change;  
> in fact, Oliver reports that WebKit is already changing in this  
> regard.
>
> As politically unpopular as it is, I think we should give a serious  
> look at C; we should figure out what the scope of any possible  
> damage would be (both in terms of raw numbers of pages, and in how  
> badly they would be broken), and minimize that.
>
> Pages can usually be changed, especially if we offer a coherent  
> transition strategy (that is some sort of tutorial that explains how  
> to get the functionality they need).    If we can get all vendors to  
> work interoperably going forward, it's worth a small amount of  
> legacy breakage.

That's a faulty argument.  The problem is a user can't distinguish  
between a non-standards compliant webpage, and a browser not working  
when another one does.  So then the user goes "this browser is broken,  
i'll go to this other browser which actually works", and the standards  
compliant browser slowly fades from existence.  As now browser wants  
to stop existing a really compelling reason is needed to justify  
dropping old behaviour.  So coming up with a standard that is  
incompatible with the existing behaviour is a no go.

The best we can do in the current situation is come up with something  
that is as sane as possible without fundamentally changing event  
ordering, etc.

As a nice example:
* calling preventDefault on a keydown in Firefox still fires a  
keypress event, but (effectively) the keypress event is initialised as  
though preventDefault has already been called, so no text input occurs.
* calling preventDefault on a keydown in IE prevents the keypress from  
firing, and results in no text input occuring.

How should this be standardised?  If it's standardised to IE behaviour  
that means Firefox should no longer fire the keypress event is  
preventDefault is called on the keydown.  For the most part this has  
no effect as the purpose of preventDefault on a keydown is to stop  
text entry. But any site expecting a keypress is now broken (the  
wonderful http://tryruby.hobix.com is a great example of this).

In the eyes of users the Firefox release that did this would be  
"broken".

When determining the correct behaviour for WebKit, the Firefox  
behaviour allows sites that would otherwise be Firefox only to be  
usable in WebKit based browsers.  As the purpose of calling  
preventDefault on a keydown event is to prevent text from being  
entered, which is still accomplished in the firefox model.  The  
additional keypress event has not been demonstrably bad anywhere, and  
we used to have much worse behaviour.

> So, realistically, the choice lies somewhere between B and C, where  
> we specify the most coherent model from what browsers already do and  
> what behavior pages rely on (which may not be exactly the same thing).
Yup, the important thing is that any changes necessary should only  
*improve* compatibility, and not break anything.

--Oliver

>
> Regards-
> -Doug Schepers
> W3C Staff Contact, SVG, CDF, and WebAPI
>

Received on Thursday, 2 August 2007 04:29:00 UTC