WebKit supports more of DOM 3 Events than DOMImplementation.hasFeature claims to This isn't particularly important, since hasFeature detection is *super* error prone. But we should make some minimal effort to have our hasFeature results match reality. I was most entertained by the fact that DOM 3 Events has a long discussion about why hasFeature detection is broken, and then goes on to say how they've slapped some lipstick on the pig, and now it's perfect: http://www.w3.org/TR/DOM-Level-3-Events/#feature-detection
Oh, and we also don't support the new lipstick (extended feature strings) yet. Although should be simple to do so.
There are 5 IETC tests which break due to this: http://samples.msdn.microsoft.com/ietestcenter/domevents/domevents_harness.htm?url=TextEvent.hasFeature.html http://samples.msdn.microsoft.com/ietestcenter/domevents/domevents_harness.htm?url=WheelEvent.hasFeature.html http://samples.msdn.microsoft.com/ietestcenter/domevents/domevents_harness.htm?url=MutationEvent.hasFeature.html http://samples.msdn.microsoft.com/ietestcenter/domevents/domevents_harness.htm?url=hasFeature.Events.html http://samples.msdn.microsoft.com/ietestcenter/domevents/domevents_harness.htm?url=hasFeature.feature.string.html
I don't think we should extend this further. See http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0073.html.
> I don't think we should extend this further. See http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0073.html. Those seem to be instructions for authors. Does DOM4 have advice for implementors? Are these requirements going to be removed from DOM3 events?
(In reply to comment #4) > > I don't think we should extend this further. See http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0073.html. > > Those seem to be instructions for authors. Does DOM4 have advice for implementors? Are these requirements going to be removed from DOM3 events? AIUI, at the last F2F, the WebApps WG agreed to address my objections, and the presence of these requirements was one of them.
> AIUI, at the last F2F, the WebApps WG agreed to address my objections, and the presence of these requirements was one of them. Great!
(In reply to comment #4) > > I don't think we should extend this further. See http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0073.html. > > Those seem to be instructions for authors. Does DOM4 have advice for implementors? Are these requirements going to be removed from DOM3 events? My point was more that there's an unresolved conflict between DOM4 and DOM3 events. From DOM4: "Specifications may define which DOM features a user agent is to support, as well as an associated list of one or more case-sensitive strings representing version numbers, and under which circumstances, when necessary for compatibility (i.e. because of historical use). Specifications must not introduce new DOM features or new versions for existing features." I agree with this for WebKit. We should only add things here as required by web compat.
> I agree with this for WebKit. We should only add things here as required by web compat. Maybe we should add a comment to this code to that effect so that folks don't fall into this trap in the future?
I'm not sure "trap" is the right word. :) I'm fully aware that hasFeature is a bad idea. I think if we can get it killed, that's the best. But if it's going to continue to limp along, we should consider making our less completely out of touch.
(In reply to comment #9) > I'm not sure "trap" is the right word. :) I'm fully aware that hasFeature is a bad idea. I think if we can get it killed, that's the best. But if it's going to continue to limp along, we should consider making our less completely out of touch. Out of touch with what? I'm not sure we can completely kill the feature, but we can stop expanding it and let it be one of the warts that we're stuck with.
(In reply to comment #10) > (In reply to comment #9) > > I'm not sure "trap" is the right word. :) I'm fully aware that hasFeature is a bad idea. I think if we can get it killed, that's the best. But if it's going to continue to limp along, we should consider making our less completely out of touch. > > Out of touch with what? I'm not sure we can completely kill the feature, but we can stop expanding it and let it be one of the warts that we're stuck with. The results that hasFeature returns are different from what specs tell us they should, as well as different from FF and IE. One approach would be simply to make our hasFeature responses exactly match FF or IE, regardless of how they correlate to reality. Another might be to make our hasFeature always return false. Another might be to come up with (ask a spec to come up with) the limited set of strings for which we should return "true" and otherwise return false. :) What I'm saying is this won't be the last time we touch hasFeature. I'm not seeking to encourage perfect matching of the specs. (Since we've decided that is a non-goal.) But since perfect matching of the specs is not the goal, we should figure out what the goal is, besides just keeping the code exactly as it happens to be today. :)
(In reply to comment #11) > The results that hasFeature returns are different from what specs tell us they should, The specs disagree. > as well as different from FF and IE. To make an informed decision, it would be helpful to see what FF and IE support. I'd also like to see what IE8 supports since modern IE will almost certainly just implement what's in the current spec. > Another might be to make our hasFeature always return false. If we could do that without hurting web compat, I'd support it. I have no idea if we can or not. > Another might be to come up with (ask a spec to come up with) the limited set of strings for which we should return "true" and otherwise return false. :) This is the most promising approach. I think the discussion at TPAC leaned towards DOM4 hard-coding this list. I don't know if there was a resolution though.
In the specific case of this bug, though, we don't want to add the strings from DOM3 events because it looks likely that DOM3 events will be changed to not have those strings.
(In reply to comment #12) > (In reply to comment #11) > > Another might be to come up with (ask a spec to come up with) the limited set of strings for which we should return "true" and otherwise return false. :) > > This is the most promising approach. I think the discussion at TPAC leaned towards DOM4 hard-coding this list. I don't know if there was a resolution though. Hmm, I thought we did that already; apparently DOM4 only has Core and XML at this point. I've filed <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15555>.
http://www.whatwg.org/specs/web-apps/current-work/#dom-feature-strings
Great! I'm happy to remove all the other strings...