This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hi, according to D3E (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-type-load) all UIEvent type (like load, unload, abort, error, and select) should implemented different interface (Event or UIEvent - when generate frome user interface). D3E doesn't mention any specifics for "when generate frome user interface". HTML5 when using this event in most case link to this term: "Firing a simple event named e" (http://www.w3.org/html/wg/drafts/html/master/webappapis.html#fire-a-simple-event) << uses the Event interface Some spec. should define when occurs inheriting directly from the UIEvent (HTML5 or other more detailed). If event object inherit from UIEvent we get access to UIEvent.view and its helpful. I notice that Firefox and Chrome for select event (when I select some text in input element) firing event inheriting directly from Event, but IE from UIEvent. It will be better it this behaviour will precise. Without this all browser can make different implementations.
The HTML spec says to use Event, and seems pretty precise about it, no? (See http://whatwg.org/html for the most up to date version of the HTML spec, by the way.) Unless the majority of browsers are using a different interface than the HTML spec says, this seems to me like it would just be a bug in the DOM3 Events spec — it shouldn't be defining event names, it should just be defining interfaces, IMHO, or, if it does mention names, should be only using them in the context of a MUST requirement for firing the event, with precise timing, etc.
(In reply to Ian 'Hixie' Hickson from comment #1) > The HTML spec says to use Event, and seems pretty precise about it, no? If this is intentional and must be that then yes, sufficiently precise. Chrome, example, use always Event for this event type, but Firefox and IE have other behaviour (https://bugzilla.mozilla.org/show_bug.cgi?id=992703). I just wondering what is corelation betwen HTML and D3E spec., because we have some discrepancies. > Unless the majority of browsers are using a different interface than the > HTML spec says, this seems to me like it would just be a bug in the DOM3 > Events spec — it shouldn't be defining event names, it should just be > defining interfaces, IMHO, or, if it does mention names, should be only > using them in the context of a MUST requirement for firing the event, with > precise timing, etc. It looks sensible because again there is a discrepancy: For example, focus/blur event type implement FocusEvent interface (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-type-focus) and should have FocusEvent.relatedTarget property, but when I read HTML spec. I see, that this event is firing with Event interface (not FocusEvent), so we don't have access to this property << algo "focus update steps" - step 2.3 and 4.4. (http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus-update-steps) Anyway, all browser use FocusEvent, we don't have specification does specify behavior for FocusEvent.relatedTarget and each browser doing it differently. I assumed this topic to get some info, maybe in future the persons responsible for standards (like HTML and D3E) take common action to somehow normalize this situation. Now its difficult to report bugs for browser because we don't know what specification quote.
If the spec isn't matching the browsers, there's probably a bug in the spec. I wasn't aware of the FocusEvent issue; I'll have to fix that. 'resize' and 'scroll' are events in the CSSOM spec, cc'ing zcorpan for his FYI. Do you know of any other cases where the HTML spec says to use one interface but where multiple browsers use another?
> 'resize' and 'scroll' are events in the CSSOM spec I saw that, but this spec completely not talking about their interfaces, just "...queue a task to fire an event event named resize..." << oo, now saw unnecessary duplication "event" word. http://dev.w3.org/csswg/cssom-view/#resizing-viewports In D3E we have set out a clear inheritance (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#h2_event-interfaces), but I see in other spec firing event is to much simplified << just use only Event interface, eventually MouseEvent. >Do you know of any other cases where the HTML spec says to use one interface but where multiple browsers use another? At this point I stuck on a MouseEvent interface, but I plan to jump over all, so if I find something interesting I will write. The first small thing what I can now write is something about mousewheel event (http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#event-mousewheel). This event doesn't exist in D3E , we have wheel event and it's supported in all browser (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-type-wheel). Browsers make this event with WheelEvent interface, but from the HTML point it doesn't matter because you never send this event. So don't know why you recall this event. Can be delete or change to correct name in the list "The following features are defined in the DOM Events specification:" and maybe change all places where event handler onmousewheel exist (to onwhell handler, Chrome and Firefox support this handler, IE no - but we can use event listener). Second, if you plan to work around FocusEvent what about focusin and focusout event type? This type are supported by the Chrome and IE, in Firefox still underway (https://bugzilla.mozilla.org/show_bug.cgi?id=687787). HTML spec never mentions about this event (use only blur/focus). Third, in the near future may be required take into account InputEvent interface (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#interface-InputEvent), Firefox started work on it (https://bugzilla.mozilla.org/show_bug.cgi?id=993253).
(In reply to spiritRKS1910 from comment #4) > > 'resize' and 'scroll' are events in the CSSOM spec > I saw that, but this spec completely not talking about their interfaces, > just "...queue a task to fire an event event named resize..." That means the Event interface gets used. http://dom.spec.whatwg.org/#concept-event-fire > << oo, now saw > unnecessary duplication "event" word. > http://dev.w3.org/csswg/cssom-view/#resizing-viewports Thanks, filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=25322 (if you want to be listed in the acknowledgements, what name should I use? Please comment in that bug.) (In reply to Ian 'Hixie' Hickson from comment #3) > 'resize' and > 'scroll' are events in the CSSOM spec, cc'ing zcorpan for his FYI. They're both Event in Blink but scroll is UIEvent in Gecko. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=25323
(In reply to Simon Pieters from comment #5) > (In reply to spiritRKS1910 from comment #4) > > > 'resize' and 'scroll' are events in the CSSOM spec > > I saw that, but this spec completely not talking about their interfaces, > > just "...queue a task to fire an event event named resize..." > > That means the Event interface gets used. > http://dom.spec.whatwg.org/#concept-event-fire Now I see that "fire an event event" is linked, but why 'resize' points to the DOM spec (and we see that should be Event interface) but for 'scroll' first "fire an event event" points to the HTML spec (without this info, second "fire an event event" again use DOM spec.). Maybe only refer to the DOM spec?
(In reply to spiritRKS1910 from comment #6) > Maybe only refer to the > DOM spec? Thanks https://www.w3.org/Bugs/Public/show_bug.cgi?id=25328 (Though the rules in HTML should be unambiguous also.)
The HTML spec uses "fire a simple event" for Event events. If there's anything in the specification that uses an unqualified "fire" generically to create and dispatch an event in a normative context, that's a bug. mousewheel is mentioned because of onmousewheel, which is defined in terms of the mousewheel event. Only Firefox seems to not support this. I dunno anything about onwheel. Working on focus/blur now. Looks like Safari/Chrome use a plain Event when it's targetted at Window, but Firefox always uses FocusEvent.
(In reply to Ian 'Hixie' Hickson from comment #8) > mousewheel is mentioned because of onmousewheel, which is defined in terms > of the mousewheel event. Only Firefox seems to not support this. I dunno > anything about onwheel. I mention about mousewheel/onmousewheel because it list in "The following features are defined in the DOM Events specification: [DOMEVENTS]" but this event is not defined in D3E. Now we have standardized event wheel (support in Firefox, Chrome, IE) but at this moment handler onwheel works only in Firefox and Chrome. https://developer.mozilla.org/en-US/docs/DOM/DOM_event_reference/mousewheel https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel > Working on focus/blur now. Looks like Safari/Chrome use a plain Event when > it's targetted at Window, but Firefox always uses FocusEvent. Yup, Firefox and IE use FocusEvent, it looks like Safari/Chrome has a small bug.
Checked in as WHATWG revision r8621. Check-in comment: Spec relatedTarget for focus and blur http://html5.org/tools/web-apps-tracker?from=8620&to=8621
ok, fixed focus/blur and relatedTarget; anything else?
Hmm, maybe if you also set the view property will be better. Default view value is null but it always set to some Window object when UA send event. I check this in Firefox, Chrome and IE and all do this, even if we use blur() and focus(). https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#widl-UIEvent-view This also applies to mouse events. I see that for "Firing a synthetic mouse event named e" you set detail attribute (default was 0 and set 1), but forgot about view. Not big problem, but always accurate description.
So, in "fire a focus event", "fire a DnD event", and "firing a synthetic mouse event named e", I should add prose that initialises the "view" attribute. Right?
I'm not sure where exactly, in definition or in algo (when you refer to the definition). I'm not study yet all terminology around "browsing context", "nested browsing context" and coresponding Window object etc., but if definition somehow cover all possible cases you can set value of view property directly in definition.
Ok, I've tried to fix it. Don't hesitate to reopen if you find anything else wrong!
Checked in as WHATWG revision r8697. Check-in comment: Make sure places that use UIEvent define .detail and .view http://html5.org/tools/web-apps-tracker?from=8696&to=8697