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
