Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re add inert #4288

Open
wants to merge 10 commits into
base: master
from

Conversation

3 participants
@alice
Copy link

commented Jan 14, 2019

Re-adds the inert attribute, and clarifies mouse pointer and event behaviour for the inert concept.

See https://github.com/WICG/inert/blob/master/explainer.md for justification.

Taken over from #1474.


/dom.html ( diff )
/form-control-infrastructure.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )

@alice

This comment has been minimized.

Copy link
Author

commented Jan 14, 2019

Replying to #1474 (comment)


The new text doesn't seem right though. It has the following normative consequence:

document.body.addEventListener("foo", () => console.log("foo event fired"));
document.body.inert = true;

document.body.dispatchEvent(new Event("foo")); // doesn't log anything

That actually seems right to me. @robdodson had the same reaction when I checked with him.

(Edited to add) Specifically, I think it would be more confusing for authors if some events worked, sometimes, than if events simply didn't work.

However, I just realised there's still an issue with event delegation as written, so some edits to UI events are still needed...

In addition it's a pretty heavy monkeypatch to the event dispatch algorithm, although I guess that was already true for the previous patch in some ways.

Agreed.

It seems like you're going for (3) in #1474 (comment), right? My stab at some text for that would be "User interactions which would otherwise cause events to be targeted at an inert element must instead do nothing". Not sure that's great either...

More like (2) (which was poorly worded) - the event fires, but nothing happens at the targeting phase. Capture/bubble work as normal.

@alice

This comment has been minimized.

Copy link
Author

commented Jan 14, 2019

However, I just realised there's still an issue with event delegation as written, so some edits to UI events are still needed...

Actually, I think we can avoid that. Will make some edits and ping this PR when ready.

@domenic

This comment has been minimized.

Copy link
Member

commented Jan 14, 2019

That actually seems right to me. @robdodson had the same reaction when I checked with him.

Hmm. I don't think this is OK. We can't have a high-level, UI/UX HTML-level content attribute interfere with foundational EventTarget-level technologies like dispatching custom events. We should only be changing UI interaction behavior, not general event functionality.

@alice

This comment has been minimized.

Copy link
Author

commented Jan 14, 2019

Ok, I'm convinced. Will look at UI Events.

@alice

This comment has been minimized.

Copy link
Author

commented Jan 15, 2019

Hm - so I had a chat to Gary K and apparently there's no easy place for it to hook in right now.

Some options:

  • Make a vague reference to UI Events, details to be filled in in that spec.
  • Spec what is currently implemented in Chrome, which is:
    • Element cannot be focused
    • Element cannot be selected
    • Element is not visible to hit testing - this seems quite difficult to actually spec, since I can't find where hit testing is defined.
@annevk

This comment has been minimized.

Copy link
Member

commented Jan 15, 2019

Element is not visible to hit testing

Hit testing is indeed not defined, but can be observed through various means (e.g., elementFromPoint()). Perhaps this can be defined in terms of the pointer-events CSS property? It seems if it cannot be hit tested or focused, you cannot get to it with UI Events either, right? So that would automatically be solved.

Focusing is defined in HTML, so could be patched there. Selection is in https://w3c.github.io/selection-api/.

@domenic

This comment has been minimized.

Copy link
Member

commented Jan 15, 2019

I don't think there's a great solution here in terms of creating a perfect spec, at least until w3c/uievents#200 is done. So we just need to focus practically on writing a good enough spec to get interop.

For that route, I would:

  • Hook into focus. Oh, this is already done in the spec today, yay! :)
  • Have a vague summary statement (like "the user agent must act as if the node was absent for the purposes of targeting user interaction events" but more accurate). Then help out by adding more details corresponding to what Chrome intends to implement. Some examples:
    • "The element is ignored for the purposes of "hit testing" (a not-yet-defined part of the web platform, related to the 'pointer-events' CSS property)"
    • Explicitly list the events that will never fire on the element.
    • Expand the current note about "may prevent the user from selecting text in that node" to also cover http://localhost:8080/#dom-textarea/input-setselectionrange (what does Chrome do for that method on inert elements?)

As for defining in terms of pointer-events, it appears that's not specced anywhere precisely because properly speccing it would require defining hit testing: https://wiki.csswg.org/spec/css4-ui#pointer-events :)

@annevk

This comment has been minimized.

Copy link
Member

commented Jan 16, 2019

I'm not sure I understand why not. It's commonly understood that most UI Events always goes through hit testing (keyboard stuff relies on focus). pointer-events affects hit testing and has a none value. So if we specified that user agents need to act as if pointer-events is none for the relevant element, that would be reasonably well-defined and even future proof (i.e., need no adjusting when UI Events is properly specified or even when hit testing is properly specified).

@domenic

This comment has been minimized.

Copy link
Member

commented Jan 16, 2019

@alice, can you comment on how Chrome's implementation of inert="" (or, alternately, the ideal implementation of inert="") maps onto Chrome's pointer-events implementation?

@alice

This comment has been minimized.

Copy link
Author

commented Jan 16, 2019

When checking whether a layout object/paint fragment is visible to hit testing, the associated Node is queried for both pointer events style and inertness.
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/layout_object.h?type=cs&sq=package:chromium&g=0&l=1709

pointer-events explicitly allows the "transparent to click events" behaviour, which I find frankly alarming if not paired with at least partial transparency.

@alice

This comment has been minimized.

Copy link
Author

commented Jan 17, 2019

I spoke to Tab about this, and he explained what pointer-events: none actually means, i.e. "no part (none) of the shape defined by this thing is visible to pointer events". This to me makes it seem like less of a good fit for inert, which Tab described as more "absorbing events", which I liked, and proposed that I could propose some kind of pointer-events-behavio[u]r property to go along with inert.

So, I think that's kind of back to the drawing board a little bit. I definitely want the "absorb events" behaviour rather than the "transparent to hit testing" behaviour. Will keep thinking about how that might be written.

@domenic

This comment has been minimized.

Copy link
Member

commented Jan 17, 2019

Sounds like the difference between the two will make for some good web platform tests! But yeah, writing up bespoke text that's clear enough to get interoperability for now, and later maybe grounding in a new CSS primitive, makes sense to me.

@alice alice referenced this pull request Mar 18, 2019

Open

Support? #7

@alice alice force-pushed the alice:re-add-inert branch from be0a03d to 84203ae Mar 18, 2019

@alice

This comment has been minimized.

Copy link
Author

commented Mar 18, 2019

I added a blacklist of events not to be fired, and a comment about setSelectionRange().

I decided the hit testing piece is probably unnecessary - for example, getElementsFromPoint() should probably still work for things like contrast ratio testing (used to figure out background colour).

@alice alice force-pushed the alice:re-add-inert branch from 380b9cd to ea7f64b Mar 19, 2019

@alice

This comment has been minimized.

Copy link
Author

commented Mar 19, 2019

On further thought, decided I did need to say something about hit testing - these elements will still show up for hit testing in general, but events which would be targeted by hit testing should be targeted at ancestors instead.

The wording is a little convoluted - my intention is to avoid the "click through to an unrelated element" scenario which pointer-events: none allows, and instead require that the event target be an ancestor, but still an ancestor which would be in elementsFromPoint.

@annevk
Copy link
Member

left a comment

Thanks for working on this!


<ul>
<li>
<p>the user agent must not fire any of the following events on the node:</p>

This comment has been minimized.

Copy link
@annevk

annevk Mar 20, 2019

Member
  1. When would this safelist apply? Does this only apply when the user agent is responsible for dispatching these events? Or would this also happen for synthetic events?
  2. It seems highly likely this safelist will go out-of-date when new events get added. What about pointer events for instance? I'd be much more comfortable with this kind of setup if there were some intrinsic properties on the event object that indicate whether to filter it as such.

This comment has been minimized.

Copy link
@alice

alice Mar 22, 2019

Author
  1. In either case.
  2. There's not really any good option here; I agree the blacklist will need to be kept up to date until we have some kind of way of referring to user input events as a class.

This comment has been minimized.

Copy link
@annevk

annevk Mar 22, 2019

Member

So then it should probably be defined as a modification of https://dom.spec.whatwg.org/#concept-event-dispatch?

Are pointer events in or out? That wasn't clear from your answer.

Does it apply regardless of what class the event implements? E.g., click with CustomEvent gets filtered?

A lot of that seems rather different from existing setups, so I'm not entirely convinced it's the design we want to use.

(FWIW, we try to avoid using "whitelist" and "blacklist", preferring "safelist" and "blocklist": https://whatwg.org/style-guide#tone.)

This comment has been minimized.

Copy link
@alice

alice Apr 12, 2019

Author

Understood re language (and thanks for the pointer) - I meant more that it's a blocklist rather than a safelist, since these events will not fire.

I do think this is the design we want in terms of behaviour - in lay terms, we want any event which is or could be fired via a user interaction (which, yes, includes pointer events) not to be fired on an element which is inert. Perhaps I can find a better way to say that.

This comment has been minimized.

Copy link
@domenic

domenic Apr 12, 2019

Member

I really don't think this should change event dispatch or prevent people from doing dispatchEvent... I think instead inert should be about blocking user interaction from translating into events.

Stated another way, I think it's better if the base EventTarget class does not give special semantics to certain event names, or to whether the EventTarget is actually a HTML Element with a certain content attribute. That seems like a layering violation; EventTarget should just be concerned with a generic eventing system.

This comment has been minimized.

Copy link
@alice

alice Apr 12, 2019

Author

Hm, I'm not sure we'd want people to be able to dispatch click events programmatically on inert elements, would we?

This comment has been minimized.

Copy link
@domenic

domenic Apr 12, 2019

Member

I don't think we should stop them... programmatic event dispatch is basically just an indirect way of doing function calls, by coordinating everything through various strings. Whether those strings are named "click" or "myevent" shouldn't, IMO, effect whether this indirect-function-call mechanism works.

This comment has been minimized.

Copy link
@alice

alice Apr 12, 2019

Author

Hmmmm. I guess we could try this out, then:

  • Remove the list of forbidden events
  • Include the "topmost event target" re-targeting language
  • Include the existing language in https://html.spec.whatwg.org/#focus-processing-model about not focusing inert elements and note in the inert section that inert elements generally aren't focusable
  • Include the points about find in page and selection potentially being disallowed by the user agent.

That would make inert elements effectively unable to be interacted with via a user interaction, I think.

This comment has been minimized.

Copy link
@alice

alice Apr 12, 2019

Author

(Did that ☝️)

Show resolved Hide resolved source

<li><p>the user agent may prevent the user from selecting text in that node, and may prevent
code calling <code data-x="dom-textarea/input-setSelectionRange">setSelectionRange()</code>
on the node.</p></li>

This comment has been minimized.

Copy link
@annevk

annevk Mar 20, 2019

Member

This would be better defined as a modification of the setSelectionRange() algorithm, as currently it's unclear what this means.

This comment has been minimized.

Copy link
@alice

alice Mar 22, 2019

Author

Done.

<span data-x="inert">inertness</span>.</p>
named "inert". This section merely defines an abstract <em>concept</em> of <span
data-x="inert">inertness</span>. See <code data-x="attr-inert">inert</code> for an explanation of
the attribute of the same name.</p>

This comment has been minimized.

Copy link
@annevk

annevk Mar 20, 2019

Member

I'd make this something like "See also the inert attribute." if we think we need to keep this note at all.

This comment has been minimized.

Copy link
@alice

alice Mar 22, 2019

Author

Done.

@alice alice force-pushed the alice:re-add-inert branch 2 times, most recently from 104a982 to b9b3fb2 Mar 22, 2019

@alice alice force-pushed the alice:re-add-inert branch from f1d35a4 to 2dacebe Apr 12, 2019

@domenic
Copy link
Member

left a comment

This looks great to me. I made some minor editorial tweaks, but I am quite happy with the event dispatching changes. I know @annevk and @smaug---- are a bit more demanding there, so it'll be good to get their take. And of course web platform tests will help.

But from my perspective, this is ready to merge.

source Outdated
is omitted, it will be reset to be the platform default (none or forward).</p>
<p>If <var>element</var> is not <span>inert</span>, changes the selection to cover the given
substring in the given direction. If the direction is omitted, it will be reset to be the
platform default (none or forward).</p>

This comment has been minimized.

Copy link
@annevk

annevk Apr 16, 2019

Member

This is the non-normative description of the method. The normative description should also be changed, no?

This comment has been minimized.

Copy link
@alice

alice May 2, 2019

Author

Added an early return into the normative description.

This comment has been minimized.

Copy link
@annevk

annevk May 15, 2019

Member

So, reading this more closely, shouldn't this affect the other selection methods as well?

This comment has been minimized.

Copy link
@alice

alice May 15, 2019

Author

I moved it into the "set the selection range" algorithm, what do you think?

source Outdated
<li>
<p>If an event would be fired as a result of user input, such that the
<span>inert</span> element would be the <span data-x="topmost-event-target">topmost event
target</span>, an alternative <span data-x="event-target">event target</span> must be found as

This comment has been minimized.

Copy link
@annevk

annevk Apr 16, 2019

Member

Is topmost event target always an element? The earlier text suggests it could be a text node too.

This comment has been minimized.

Copy link
@alice

alice May 2, 2019

Author

https://w3c.github.io/uievents/#topmost-event-target says "[t]he topmost event target MUST be the element highest in the rendering order which is capable of being an event target", so it seems like we can assume it is always an element.

This comment has been minimized.

Copy link
@annevk

annevk May 14, 2019

Member

Maybe? Not sure UI Events can be trusted. But that means the earlier text is wrong, no?

This comment has been minimized.

Copy link
@alice

alice May 14, 2019

Author

Not necessarily. The following two points specifically concern text nodes:

The user interaction events, agent may ignore the node for the purposes of text search user interfaces (commonly known as "find in page"), page"); and

The user agent may prevent the user from selecting text in that node.

This comment has been minimized.

Copy link
@annevk

annevk May 14, 2019

Member

What is unclear is if the current text applies when it's not an element that is inert or if it should be ignored in that case. (Perhaps there's no way to get UI events to fire on non-elements though, but then it comes back to the synthetic cases and I've somewhat forgotten what we decided on there.) It's rather hard to revisit this every couple of weeks and remember all the various details. 😟

This comment has been minimized.

Copy link
@alice

alice May 15, 2019

Author

On reflection, I'm happy to change it to Node, seems like that would be the most inclusive and not inaccurate.

<li><p>Add <var>candidate</var> to <var>ineligible</var>.</p></li>
<li><p>Let <var>candidate</var> be the element which would be the <span
data-x="topmost-event-target">topmost event target</span> if all the elements in
<var>ineligible</var> were excluded from consideration.</p></li>

This comment has been minimized.

Copy link
@annevk

annevk Apr 16, 2019

Member

So you'd have to perform hit testing again? In particular, if a position a div under an inert element, that div element would become candidate?

Do we have tests for that?

This comment has been minimized.

Copy link
@alice

alice Apr 17, 2019

Author

Working on tests, yeah.

The intent is that if you position a div which is not an ancestor under the inert element, that div would not be targeted. The old wording, and indeed the old implementation in blink, would have targeted the event at the non-ancestor div, as does pointer-events: none.

This comment has been minimized.

Copy link
@alice

alice Apr 17, 2019

Author

Clarification, sorry - the div would become candidate, but would be added to ineligible as it is not an ancestor.

I've looked at implementing this in Blink, and it seems to be possible to do without performing redundant hit testing at least in our codebase - rather, you continue the hit testing process until a suitable candidate is found.

This comment has been minimized.

Copy link
@annevk

annevk Apr 17, 2019

Member

Ah right, thanks. Ideally this shares infrastructure with https://drafts.csswg.org/cssom-view/#dom-document-elementsfrompoint I think, which should use the same primitive.

This also needs to be rephrased a bit using "Set candidate to" as you already initialized it earlier.

This comment has been minimized.

Copy link
@alice

alice May 2, 2019

Author

Ideally this shares infrastructure with https://drafts.csswg.org/cssom-view/#dom-document-elementsfrompoint I think, which should use the same primitive.

Do you mean the implementation, or the spec? The implementation does indeed share infastructure.

This also needs to be rephrased a bit using "Set candidate to" as you already initialized it earlier.

Done, thanks.

(Edited because I originally pasted the wrong thing into my quote)

This comment has been minimized.

Copy link
@annevk

annevk May 14, 2019

Member

I meant both.

This comment has been minimized.

Copy link
@alice

alice May 14, 2019

Author

There is a lot of spec technical debt to be cleared up around hit testing.

UIEvents says:

The topmost event target MUST be the element highest in the rendering order which is capable of being an event target. In graphical user interfaces this is the element under the user’s pointing device. A user interface’s hit testing facility is used to determine the target. For specific details regarding hit testing and stacking order, refer to the host language.

As far as I know, "hit testing" is not defined for HTML.

The elementsFromPoint definition says:

For each layout box in the viewport, in paint order, starting with the topmost box, that would be a target for hit testing at coordinates x,y even if nothing would be overlapping it, when applying the transforms that apply to the descendants of the viewport, append the associated element to sequence.

without even attempting to define "hit testing" or "paint order".

<var>ineligible</var> were excluded from consideration.</p></li>
</ol>
</li>
<li><p>If <var>candidate</var> is not null, then fire the event using <var>candidate</var> as

This comment has been minimized.

Copy link
@annevk

annevk Apr 16, 2019

Member

Where can it become null?

This comment has been minimized.

Copy link
@alice

alice May 2, 2019

Author

Good question. Clarified the second step in the loop to explicitly set it to null in the case where no suitable element exists.

<li><p>Otherwise, do not fire the event.</p></li>
</ol>

<p class="example">For example, consider a page that consists of just a single

This comment has been minimized.

Copy link
@annevk

annevk Apr 16, 2019

Member

Nit: no need for "For example," as the class already takes care of that.

This comment has been minimized.

Copy link
@alice

alice May 2, 2019

Author

Done.

<li><dfn data-x="event-focusin" data-x-href="https://w3c.github.io/uievents/#event-type-focusin"><code>focusin</code></dfn> event</li>
<li><dfn data-x="event-focusout" data-x-href="https://w3c.github.io/uievents/#event-type-focusout"><code>focusout</code></dfn> event</li>

<li><dfn data-x="event-beforeinput" data-x-href="https://w3c.github.io/uievents/#event-type-beforeinput"><code>beforeinput</code></dfn> event</li>

This comment has been minimized.

Copy link
@annevk

annevk Apr 16, 2019

Member

Same.

This comment has been minimized.

Copy link
@alice

alice May 2, 2019

Author

Fixed.

source Outdated

<li><dfn data-x="event-compositionstart" data-x-href="https://w3c.github.io/uievents/#event-type-compositionstart"><code>compositionstart</code></dfn> event</li>
<li><dfn data-x="event-compositionupdate" data-x-href="https://w3c.github.io/uievents/#event-type-compositionupdate"><code>compositionupdate</code></dfn> event</li>
<li><dfn data-x="event-compositionend" data-x-href="https://w3c.github.io/uievents/#event-type-compositionend"><code>compositionend</code></dfn> event</li>

This comment has been minimized.

Copy link
@annevk

annevk Apr 16, 2019

Member

Same.

source Outdated
<li><dfn data-x="event-compositionupdate" data-x-href="https://w3c.github.io/uievents/#event-type-compositionupdate"><code>compositionupdate</code></dfn> event</li>
<li><dfn data-x="event-compositionend" data-x-href="https://w3c.github.io/uievents/#event-type-compositionend"><code>compositionend</code></dfn> event</li>

<li>The <dfn data-x="event-target" data-x-href="https://w3c.github.io/uievents/#event-target">event target</dfn> concept</li>

This comment has been minimized.

Copy link
@annevk

annevk Apr 16, 2019

Member

I don't think we should add this reference as it's rather confusing and duplicative of the DOM Standard.

This comment has been minimized.

Copy link
@alice

alice May 2, 2019

Author

Hm, the term event target is not actually defined in the DOM standard, and the way I'm using it refers specifically to the sense used in UIEvents.

This comment has been minimized.

Copy link
@annevk

annevk May 14, 2019

Member

Okay, but I think we need to find some other way as UI Events really shouldn't define this term and we shouldn't take a new dependency on that "flaw".

This comment has been minimized.

Copy link
@alice

alice May 14, 2019

Author

This doesn't seem like a reasonable objection, to be honest. I don't think there is another way (if you think of one, please let me know), and I don't think it affects implementability.

This comment has been minimized.

Copy link
@annevk

annevk May 15, 2019

Member

I'm happy to discuss this further, but I don't think adding a dependency on a bug in UI Events is a good strategy.

This comment has been minimized.

Copy link
@alice

alice May 15, 2019

Author

The bug being that UIEvents defines this term?

This comment has been minimized.

Copy link
@annevk

annevk May 15, 2019

Member

Per my understanding of the setup here all of this happens before the dispatch algorithm. The dispatch algorithm is handed a target and an event, but it might fiddle with these as it sees fit (e.g., to account for shadow trees).

The manipulation you define is therefore about the eventual input for the dispatch algorithm at which point you can't really speak about an event target. And UI Events also shouldn't define the term the way it does because that gives the impression you are able to manipulate it in this manner.

This comment has been minimized.

Copy link
@alice

alice May 15, 2019

Author

Hm. Leaving aside "topmost event target", the only references to "event target" are these two, in the retargeting rules:

... an alternative event target must be found as follows:

If candidate is not null, let candidate be the new event target.

I agree that the manipulation is about the eventual input for the dispatch algorithm. The input for these steps is what the UIEvents spec refers to as the "topmost event target" (really more a potential event target), and the output is the input to the dispatch algorithm.

I think this is correct; we only want to do this manipulation when there is hit testing involved, not as part of the dispatch algorithm in general. Effectively, we want to change the output of the hit testing.

source Outdated
<li><dfn data-x="event-touchend" data-x-href="https://w3c.github.io/touch-events/#event-touchend"><code>touchend</code></dfn> event</li>
<li><dfn data-x="event-touchmove" data-x-href="https://w3c.github.io/touch-events/#event-touchmove"><code>touchmove</code></dfn> event</li>
<li><dfn data-x="event-touchcancel" data-x-href="https://w3c.github.io/touch-events/#event-touchcancel"><code>touchcancel</code></dfn> event</li>

This comment has been minimized.

Copy link
@annevk

annevk Apr 16, 2019

Member

These events are also not mentioned anywhere.

This comment has been minimized.

Copy link
@alice

alice May 2, 2019

Author

Fixed.

source Outdated

<ul>
<li>
<p>If an event would be fired as a result of user input, such that the

This comment has been minimized.

Copy link
@annevk

annevk Apr 16, 2019

Member

It's not clear what this would count. E.g., form submission can be the result of user input, can that be prevented?

This comment has been minimized.

Copy link
@alice

alice May 2, 2019

Author

Would the form be the topmost event target in that case?

This comment has been minimized.

Copy link
@annevk

annevk May 15, 2019

Member

It's still not entirely clear to me what topmost event target means.

This comment has been minimized.

Copy link
@alice

alice May 15, 2019

Author

A better question, to help us figure this out: what user input would cause a form to be submitted?

This comment has been minimized.

Copy link
@annevk

annevk May 15, 2019

Member

There might be a click somewhere or some such (though I suppose even click is not technically user input).

This comment has been minimized.

Copy link
@alice

alice May 15, 2019

Author

I can read that in two ways:

  1. The user clicks at the location of the submit button within the form.
    • In that case, the submit button is the topmost event target, and since it is within the form and the form is inert, the click event is retargeted, possibly at the form's parent element (depending on the circumstances which led to the form being inert).
  2. The user clicks at the location of a non-inert button outside the form, which would have the effect of submitting the form due to javascript running in its click event handler.
    • In that case, the button is the topmost event target, and the click event is fired as a result of the user interaction since the button is not inert.

I'm guessing you're thinking of the second case? I guess you could argue that in that case, the form submission event is "as a result of user input", making "topmost event target" ambiguous, but I don't know that it would be a likely interpretation.

@alice

This comment has been minimized.

Copy link
Author

commented Apr 17, 2019

Just a quick comment to say thanks for the thorough review.

I'll be out for the next week and a half so it might take me a bit to get back to all of it, but just wanted to say it's well appreciated, and in particular that I'm planning to work on the WPT tests for the new behaviour (including retargeting) soon.

@alice alice force-pushed the alice:re-add-inert branch from a41817c to e6638e8 May 2, 2019

@alice

This comment has been minimized.

Copy link
Author

commented May 2, 2019

Sorry for all the noise, I am so bad at github. Anyway, I've tried to address all your comments (WPT tests are still WIP) - thanks again!

@alice

This comment has been minimized.

Copy link
Author

commented May 6, 2019

(Not sure why the build failed; it passed for me locally. Would it be possible to re-run?)

@domenic

This comment has been minimized.

Copy link
Member

commented May 7, 2019

Sorry for the delay; build re-started, and filed whatwg/html-build#194 to track making the script more resilient to network failures.

@robdodson robdodson referenced this pull request May 7, 2019

Open

Browser vendor feedback #69

source Outdated

<p>The following features are defined in the Touch Events specification: <ref spec=TOUCH></p>

<ul class="brief">
<li><dfn data-x-href="https://w3c.github.io/touch-events/#touch-interface"><code>Touch</code></dfn> interface</li>
<li><dfn data-x-href="https://w3c.github.io/touch-events/#dfn-touch-point">Touch point</dfn> concept</li>
<li><dfn data-x="event-touchstart" data-x-href="https://w3c.github.io/touch-events/#event-touchstart"><code>touchstart</code></dfn> event</li>

This comment has been minimized.

Copy link
@annevk

annevk May 15, 2019

Member

I don't see touchstart referenced anywhere.

This comment has been minimized.

Copy link
@alice

alice May 15, 2019

Author

Thanks for catching that; removed.

@alice alice force-pushed the alice:re-add-inert branch from 9db4047 to 3558938 May 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.