This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I think it would be best to remove the entire section; I expect that DOM4 will require those feature strings that are interoperably implemented. If it is preferred that D3E also defines those that are related to events, that's fine with me too. However, the new feature strings that are currently introduced should be dropped (note that this was one of the objections raised in <http://www.w3.org/mid/4EA1D937.1080500@gmail.com>, which, I believe, the WG agreed with).
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".
While it may "seem useful", this has rarely come up as a problem in practice in my experience. Usually there's a new event object or some other correlated feature that can be tested for.
(In reply to comment #2) > While it may "seem useful", this has rarely come up as a problem in practice in > my experience. Usually there's a new event object or some other correlated > feature that can be tested for. So, is the objection just centered around having a new feature in D3E that only "seems useful"? Is there any other technical objection?
Well yes, that feature detection in this way is broken. hasFeature has not been reliable since it was invented and virtually everyone agrees it has to go.
Travis, I objected to this last time, and the WG agreed with me. If you decide to leave it in, I'll object again. I believe it would save time for everyone involved if you just implemented the decision that was made.
(In reply to comment #5) > Travis, I objected to this last time, and the WG agreed with me. If you decide > to leave it in, I'll object again. I believe it would save time for everyone > involved if you just implemented the decision that was made. Per the working group decision, I have removed this section entirely from the spec. There is no more hasFeature requirements anywhere in the spec (I pulled the various "feature" commentary from each of the major event interface sections as well.) This change should address the bug/LC comment.