[Bug 16507] Update or remove 1.3 Feature Detection

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16507

Travis Leithead [MSFT] <travil@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |annevk@opera.com,
                   |                            |travil@microsoft.com

--- Comment #1 from Travis Leithead [MSFT] <travil@microsoft.com> 2012-04-06 20:22:27 UTC ---
Here's my thoughts and plan for this bug.

First, it seems useful to have an API for detecting if a given implementation
supports firing a *trusted* event type of a given name (for whatever the
scenario associated with the event may be in whatever specification).

For example, consider a new spec that adds a "pagedown" event (humor me,
please). Web authors love this new event because it simplieifes a bunch of
pageYOffset logic they were using. However, the web page wants to have graceful
fallback (or they don't want to have their fallback code load if the browser
will fire this event). So, what are there options?

1. They know that this event is supported in the latest versions of FOO
browser. So, they have a browser-detect with version number compare.
2. They set a "pagedown" handler, and then try to programatically scroll the
page to see if the event fires (this may not be possible depending on how the
new event is spec'd to work). If the event fires, they know it's supported.
3. They check for an onpagedown IDL attribute on some object. This may work if
the host language defined an IDL event handler for this event (but again, thay
may not have, e.g., not present for mutation events nor DOMContentLoaded, etc.

I can't think of any others offhand, but there may be.

Options 2 & 3 are hit-and-miss options. They MIGHT work, but this isn't
guaranteed nor enforced in any way across new events that are defined in the
web platform. That really leaves only option 1, which is not a recommended
practice and has really harmed IE's progress over the last several releases.
So, basically I conclude that none of the available options are good ones.

The goal of this hasFeature "extended feature strings" was to provide a
reliable solution to the above problem. You put in "Events.pagedown" and get
back a true/false.

The risk to such a technique, of course, is that an implementation maintains a
separate list for the event types to report for the hasFeature API, than it
does for the addEventListener API. If the two lists get out of sync or
implementors forget to update both lists in parallel, then the API will
immediately lose it's value.

Recognizing that potential problem, IE9 shipped support for this technique and
bound the API to the same internal list used everywhere for the set of known
event types in the platform. In this way, the list is always current and
up-to-date.

It may be somewhat unfortunate that the existing "hasFeature" API was re-used
for this purpose.

If the primary objection to the event type detection is the integration with
the legacy hasFeature API, than I'm open to minting a new API for this purpose
(that would be much simpler). However, if the objection is based on the
principle of feature detecting event types in general, then I think we shall
have a good discussion and see what happens.

The way forward for me (assuming minimal friction on the previous topic), is to
re-work section 1.3 so that it's much more clear what the intent and scope of
the "extended feature strings" is, and then drop everything else, including the
"for backwards compatibility" stuff (e.g., "Events.KeyboardEvent"). After the
re-write, I want to move this entire section into the 5.1 Event Types section
so that it becomes "5.1.2 Event Type Feature Detection".

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 6 April 2012 20:22:34 UTC