On 4/20/21 06:47, Alice Boxhall wrote:
> On Fri, Apr 16, 2021 at 5:39 AM Emilio Cobos Álvarez <emi...@mozilla.com
> On 4/15/21 14:07, Manuel Rego Casasnovas wrote:
> > I'm also supportive of "inert", it's nice to see it coming to the
> > I'm curious about the interop status, the feature hasn't shipped in
> > Firefox yet so I'm not sure if this reflects the reality or not:
> > Are Chromium and Firefox implementations interoperable?
> > Apart from that, we haven't asked for signals to WebKit yet
> > (https://bit.ly/blink-signals
> * Firstly, I think that pointer-events: none in HTML is a mis-feature.
> That might be something I just have to get over, since it's now
> deeply entangled with all of our hit-testing logic, but my reasons
> for feeling this way are:
> o It can create a bad user experience if opaque content with
> pointer-events: none is positioned over clickable content, since
> you can now click content you can't see.
> o The naming doesn't make sense when (as in HTML, but not in SVG
> where it originated) the only options are auto or none. It makes
> it appear as though "none" refers to the /events/, rather than
> the box, and sets an expectation that it's going to swallow
> pointer events, rather than make the element "transparent" to
> events (which makes sense if and only if the element /is/
> visually transparent, which was the intent of the feature in SVG
> as far as I can tell).
So, I disagree that stuff affecting hit-testing doesn't belong to CSS
fwiw, but I agree with the other comments. There are existing issues in
the CSSWG repo to add more values to pointer-events that do something
closer to what you want to do for inert, I think.
> * Secondly, the value of inert is largely that it makes content
> non-interactive for /all/ modalities, rather than just pointers.
> This is a deliberate choice, because vast amounts of content is
> built exclusively considering the needs of users who used
> pointer-based devices, creating poor experiences for users of other
> modalities. I would like to encourage authors to use inert/instead
> of/ pointer-events: none (or pointer-events: inertif/when such a
> thing eventuates) as much as possible.
Sure, this I totally agree with! But that doesn't mean that inert
shouldn't be implemented in terms of other pre-existing primitives like
user-select, pointer-events, etc when those are already available, IMO.
> * Thirdly, I haven't seen an urgent use case for authors needing a way
> to detect when (inert) content matches pointer-events: none. That
> doesn't mean that it doesn't exist, but that I don't see any reason
> to consider not having it to be a blocking issue. Even if it does
> ship later, the risk that code could depend on inert content
> /not/ matching pointer-events: none seems non-existent.
I think that seems fair. To be clear that we can't think of an use case
for it doesn't mean that that doesn't exist, but I agree it's probably
not a blocking issue.
We can probably define the precise hit-testing behavior we want
somewhere like in this CSSWG issue, and then using it from inert?
I _think_ you're part of the working group so should be able to add that
to the agenda, but if not I or some of the Chromium rendering folks can
probably do it, just let me (or them) know :)
> All of that said: it does seem that some recent refactoring has subtly
> broken the event retargeting code in ways I hadn't tested for, so I'm
> planning to admit defeat and revert to the original (pointer-events:
> none-like) behaviour, both in the spec and in the code. If someone would
> like to make further changes such that it matches pointer-events: none
> I'm not going to stand in their way, as long as my reasoning above is
Alright, that sounds great. I think it makes sense for inert to change
computed styles (both from an authoring and implementation point of
view), but I agree it's probably not a huge deal, as long as the
behavior matches what authors can accomplish via CSS and other means.
I think it'd be ideal to not ship with this difference, but
in any case I agree the risk for interop issues is relatively low,
specially if the hit-testing behavior will actually match across browsers.
> There also seems to be some other rather important spec issues that
> haven't been resolved like , which I think we should get
> consensus on
> before shipping.
> The spec actually doesn't state an opinion (and in fact it has no way to
> do so) on whether inert nodes should be exposed to assistive technology
> (AT) APIs. We can and frequently do make changes to how content is
> exposed to AT to improve the user experience.
I guess I'm not so familiar with how a11y features are usually
standardized, but given that behavior is not directly web-exposed I
guess that might be fair? I think ideally we'd all agree on how to
expose stuff to ATs though...
> >> <mailto:mk...@chromium.org
> >> I also think this looks quite reasonable, and I think it's
> a good
> >> addition to the platform. That said, I think Yoav's
> questions about
> >> the details and Mozilla's approach are good ones. Alice, how do
> >> you think we should handle them?
> >> -mike
> >> On Thu, Apr 8, 2021 at 12:45 AM 'Alex Russell' via blink-dev
> >> <blin...@chromium.org
> >> On Tuesday, March 30, 2021 at 5:58:24 AM UTC+2
> A Boxhall
> >> wrote:
> >> Contact emails
> >> abox...@chromium.org
> >> To view this discussion on the web visit
> >> <mailto:blink-dev+...@chromium.org
> >> <mailto:blink-dev+...@chromium.org