Made mouseover/out/enter/leave event firing independent of corresponding PEs #56
Conversation
| @@ -450,14 +450,14 @@ | |||
| <td>Sync</td> | |||
| <td>Yes</td> | |||
| <td>Yes</td> | |||
| <td>Varies: when the pointer is primary, all default actions of <code>mouseover</code></td> | |||
| <td>None</td> | |||
| </tr> | |||
There was a problem hiding this comment.
Please call out these changes in the description also (since they're only tangentially related). I.e. that since UI Events says these mouse events have no default action, we can just say the same for the pointer events.
|
The basic approach here seems good to me. @teddink any concerns? I think this is closer (but still not exactly) to what Edge is doing today and makes more conceptual sense IMHO. |
mustaqahmed
changed the title
| @@ -819,20 +819,26 @@ | |||
| </section> | |||
| </div> | |||
| <section> | |||
| <h2 id="tracking-legacy-mouse-pos">Tracking the effective position of the legacy mouse pointer</h2> | |||
| <div> | |||
| <p>While only <a href="#the-primary-pointer">primary pointers</a> can produce compatibility mouse events, <a href="#multiple-primary-pointers">multiple primary pointers</a> can be active simultaneously, each producing its own stream of compatibility mouse events. Since all these compatibility events would appear to MouseEvent code to be coming from a single mouse device, user agents are encouraged to guarantee that the compatibility mouse events are consistent from a single device perspective. For mouse transition events (i.e., <code>mouseover</code>, <code>mouseout</code>, <code>mouseenter</code> and <code>mouseleave</code>), this means the entry/exit state for every event target is valid as implied by [[!DOM-LEVEL-3-EVENTS]]. Users agents SHOULD guarantee this by maintaining the <dfn id="dfn-legacy-mouse-pos">effective position of the legacy mouse pointer</dfn> in the document as follows.</p> | |||
There was a problem hiding this comment.
sorry another for "each producing its own stream of compatibility mouse events" I'd suggest removing the "stream of". "own stream" sounds like they're really independent streams. The whole point of this section is to say that, although each device produces compat mouse events, it's a single logical stream.
There was a problem hiding this comment.
Again you should avoid use any hrefs in your internal <a> links. ReSpec handles this automatically for you. For example see the various other places in the spec which do simply <a>primary pointer</a>. When necessary you can use data-lt on the a tag to specify a definition name that's different from the anchor content (eg. see examples like <a data-lt="Chorded Button Interactions">). I don't know why this is really any better than using <a href=...> but we should at least be consistent across the spec.
mustaqahmed
force-pushed
the
gh-pages
branch
9 times, most recently
from
4b18ac0
to
813d1af
Compare
| @@ -374,7 +374,7 @@ | |||
| <dt>primary pen input</dt><dd>A pointer representing pen input is considered the <i>primary pen input</i> if its <code>pointerdown</code> event was dispatched when no other active pointers representing pen input existed.</dd> | |||
| </dl> | |||
| <div class="note" id="multiple-primary-pointers">When two or more pointer device types are being used concurrently, multiple pointers (one for each <code>pointerType</code>) are considered primary. For example, a touch contact and a mouse cursor moved simultaneously will produce pointers that are both considered primary.</div> | |||
| <div class="note">In the case where there are multiple <a href="#the-primary-pointer">primary pointers</a>, | |||
| <div class="note">In the case where there are multiple <a data-lt="The Primary Pointer">primary pointers</a>, | |||
There was a problem hiding this comment.
Oh, it looks like the uses of <a>primary pointer</a> I was looking at are actually broken! I think that's just because <dfn>The Primary Pointer</dfn> should be The <dfn>Primary Pointer</dfn>. If you change that, then I think you can avoid the data-lt here and elsewhere.
|
On the call we agreed this was nearly good to merge, just blocked on some editorial feedback from @patrickhlauke. |
|
wondering if the entire paragraph
should be moved to the very start of the section, right after the "Compatibility Mapping with Mouse Events" heading. this would make it a bit more immediately clear right from the start when a reader delves into the section that this is optional, rather than burying the lede in between two notes. Perhaps even wrapped as a note (though this would make it non-normative?) or some other form of styling change/block-out if available. |
|
Done. |
|
Sorry, you're right @mustaqahmed ... your update slipped me by. At the risk of sounding nitpicky, I'd say that now the rationale for why there's even compatibility mapping is a bit buried. I'd suggest ripping out the first paragraph or the rationale and grafting it right at the start, so something like: and then leaving the rest as you have it. |
|
ptal. Thanks for the suggestion, the rationale is clearer now. |
|
LGTM (once merge conflicts are resolved) |
|
Thanks Patrick. I will resolve the merge conflict after adding the boundary condition handling (see @RByers's comments on May 3). |
mustaqahmed
force-pushed
the
gh-pages
branch
2 times, most recently
from
e1428ae
to
7e7cb4e
Compare
|
@RByers, I have updated the algorithm in Sec11.1 to handle unset values correctly. |
The spec currently suggests that compatibility mouse transition events (i.e. mouseover, mouseout, mouseenter and mouseleave) should be fired right after firing the corresponding PointerEvents, implying a 1:1 correspondence between the PointerEvents vs the compatibility MouseEvents. This 1:1 correspondence breaks the consistency of MouseEvent sequence itself when two or more primary pointers (of different types) are active at the same time. For example, mouseover events can be sent to two different targets without a mouseout in-between, which can possibly break the UIs based on legacy MouseEvents, e.g., by opening two menu items at the same time. (Issue This patch fixes the problem by omitting the 1:1 correspondence altogether. More precisely, it suggests to fire the compatibility mouse transition events right before a pointerdown/up/move event. In addition, this patch modifies the default actions of pointerover, pointerout, pointerenter and pointerleave events to "none". This keeps the spec effectively unchanged since the original default action was "the default action of corresponding MouseEvent" but the UI Event Spec defines those default actions as "none".
|
On today's call @teddink said it was their intention to have Edge's behavior match this PR but it'll take them some time to try coding it up and understand the full impact in practice. |
|
Sorry for the delay (fell off my notifications list somehow), looks good to me. As discussed in the call today, let's merge (we can always continue to tweak the details as needed of course). |
The spec currently suggests that compatibility mouse transition events (i.e. mouseover, mouseout, mouseenter and mouseleave) should be fired right after firing the corresponding PointerEvents, implying a 1:1 correspondence between the PointerEvents vs the compatibility MouseEvents. This 1:1 correspondence breaks the consistency of MouseEvent sequence itself when two or more primary pointers (of different types) are active at the same time. For example, mouseover events can be sent to two different targets without a mouseout in-between, which can possibly break the UIs based on legacy MouseEvents, e.g., by opening two menu items at the same time. (Issue #35.)
This patch fixes the problem by omitting the 1:1 correspondence altogether. More precisely, it suggests to fire the compatibility mouse transition events right before a pointerdown/up/move event.
In addition, this patch modifies the default actions of pointerover, pointerout, pointerenter and pointerleave events to "none". This keeps the spec effectively unchanged since the original default action was "the default action of corresponding MouseEvent" but the UI Event Spec defines those default actions as "none".