[selectors] propagation of the :focus pseudo

[frivoal]

Unearthed from an old mail by @fantasai:

I was just reviewing
https://hg.csswg.org/drafts/rev/2539f118cb22

I'm not sure if the conformance clause is on the host language spec
or directly on UAs. This needs to be clearer. If it's on the host
language, then it should probably be a should and not a must. And
if it's directly on UAs, then we've probably got a clash with HTML.
In which case we should be clearer about the fact that our spec is
asking to override the HTML spec.

[css-meeting-bot]

The CSS Working Group just discussed Propagation of focus.

The full IRC log of that discussion

<TabAtkins> Topic: Propagation of focus
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1240
<TabAtkins> Florian: This was raised by elika a while ago
<TabAtkins> Florian: Topical now because MOz and Blink are both implementing :focus-within, which depends on :focus, so we shoudl make sure we get :focus right.
<TabAtkins> Florian: We have wording attmpeting to say that "whatever magic HTML says to make :active propagate (to labeled controls, etc), it should apply to :focus too".
<TabAtkins> Florian: Elika says this is either useless or contradicting HTML.
<TabAtkins> Florian: I think you were saying that the way we phrased it doesn't make it clear whether we were placing a requirement on the HTML authors to fix this, or overriding them and defining it propagates differently.
<TabAtkins> Florian: Because in HTML :focus and :active do propagate differently.
<TabAtkins> Florian: So it's unfortunate if we disagree. Do we yield, or shout at them?
<TabAtkins> Florian: I think we wrote it this way because there was a parallel discussion about whether :focus and :active should prop from a form control to its label *and* vice versa; we at least agree that they should both act the same.
<TabAtkins> Florian: And we just filed an issue on HTML to figur eout if it should be bidirectional or not.
<TabAtkins> Florian: It was bidi in IE (not Edge).
<TabAtkins> Florian: Given that :focus-within is meant to do the same as :focus, and there's no compat baggage, we should put a stick in the ground and decide.
<TabAtkins> [need more time to think about this, we're dropping the topic for now]

[frivoal]

The discussion about HTML with the whatwg mentioned in the minutes above stalled here: https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jan/0018.html

Since then Edge, no longer supports bidirectional propagation of :hover and :active. Also, :focus does not propagate from the label to the labelled control (nor the other way around).

I still think bidirectional propagation of :hover and :active would be nice, but it looks like the consensus is going away from it, and that everybody agrees :active and :focus are supposed to propagate differently.

So the current phrasing in the spec seems wrong, and should be overturned.

I propose to replace this:

If the document language has defined additional ways by which an element can match :active, the same ways must apply to elements matching :focus as well, except that the parent of an element that matches :focus must not match :focus.

with that:

Document languages may define additional ways in which an element can match :focus, except that the parent of an element that matches :focus must not match :focus. (see :focus-within if matching on the parent is desired).

While we're at it, this part of the definition also seems wrong:

There may be document language or implementation specific limits on which elements can acquire :focus. For example, [HTML5] defines a list of activatable elements.

and should be replaced with

There may be document language or implementation specific limits on which elements can acquire :focus. For example, [HTML5] defines a list of focusable areas (https://html.spec.whatwg.org/multipage/interaction.html#focusable-area).

[frivoal]

Oh, missed that. There's still an open issue on the whatwg that relates to this

whatwg/html#1632

Even then, I think the changes above should be applied. As it is, the spec contradicts HMTL, which is not good. The above changes make it defer to HTML.

We might want instead to try and convince HTML that we want to take over the definition of these pseudo classes (or maybe not), but until then, the above should be an improvement over what's here now.

[css-meeting-bot]

The CSS Working Group just discussed propagation of the :focus pseudo.

The full IRC log of that discussion

<dael> Topic: propagation of the :focus pseudo
<dael> github topic: https://github.com//issues/1240
<dael> Florian: When we introduced focus-within we tried to clarify focus and active. What we attempted was to say active and focus propagate to/from the same time. The spec prose for that isn't very good. I think I authred that, sorry. It also contradicts HTML.
<dael> Florian: I think we should clarify we do what HTML does.
<dael> Florian: Secondary, I think we resolved on a preferred behavior which was also in disgreement with HTML. We should either try and convince HTML to change their behavior if we care about this. For now, we should point to thier propagation method.
<dael> astearns: Is their method well tested?
<dael> Florian: I think it is. I don't think it was fully interop before. IE or Edge didn't used to have it, but there's more interop now.
<dael> tantek: I haven't looked recently, but I thought most still propagates in Edge.
<tantek> s/tantek/???
<astearns> s/tantek /gregwhitworth /
<dael> Florian: I jsut tried recently and it didn't obviously propagate in the general case. I still think it would be better if it went both ways. There is an open issue on that in whatwg. I don't say we drop this, but having the contradiction isn't useful
<dael> astearns: So there's an open issue on whatwg.
<dael> tantek: Could have sworn I tried to bring that back to CSSWG. It seemed to most of the people in this group felt this want the right behavior. Id idn't want people not in the room superceeding that. I didn't want to lose that. I can test more throughly.
<tantek> s/tantek/gregwhitworth
<dael> Florian: IN spirit I agree, but focus is fairly complex. It's a bit of a rabbit hole and I don't think we want to take over all of that. If we want some part we need to figure out where to split.
<dael> Florian: Looks like we won't resolve, but please look @ GH
<dael> astearns: Ccan we resolve on removing the contradiction? Or is it better to keep it open so the issue gets more focus.
<fantasai> testcase: data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw+DQogIDxzdHlsZT4NCiAgICA6Zm9jdXMgeyBiYWNrZ3JvdW5kOiBvcmFuZ2U7fQ0KICA8L3N0eWxlPg0KICA8bGFiZWwgZm9yPXlvPkZvbzwvbGFiZWw+DQogIDxpbnB1dCBpZD15bz4=
<AmeliaBR> What's the publication status of Selectors 4? Does it need to be finalized?
<fantasai> ?
<dael> Florian: I thought it was better, but gregwhitworth argues that we could lose all control.
<fantasai> AmeliaBR: Lots of mess, iirc
<dael> gregwhitworth: I hadn't given it too much thought. Can we talk about this in Paris? Or next WG call with everyone on? Other imple were interested before.
<fantasai> +1 to f2f
<dael> astearns: Seems like bringing this to the F2F is a fair idea. It's not that far. Let's do that. I'll put the F2F tag on it.
<dael> astearns: Please do add information to both whatwg issue and ours as you find it.

[css-meeting-bot]

The CSS Working Group just discussed selectors 4 pub, and agreed to the following resolutions:

• RESOLVED: take changes outlined in 3rd comment in the issue https://github.com/w3c/csswg-drafts/issues/1240, with Tab's amendment re: must not match focus

The full IRC log of that discussion

<astearns> topic: selectors 4 pub
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Jul/0022.html
<tantek> scribenick: tantek
<tantek> dbaron: one of the reasons is that there was a section of text added in the editor's draft that I disagreed with and didn't have a chance to review it
<tantek> tab: I think we should update this four year old WD regardless
<tantek> fantasai: I'm co-editor of the spec and I don't know what's in the ED
<tantek> action fantasai: review current state of Selectors 4 and determine what if anything is blocking publishing a new WD
<trackbot> Created ACTION-854 - Review current state of selectors 4 and determine what if anything is blocking publishing a new wd [on Elika Etemad - due 2017-08-09].
<tantek> dbaron: I put a note in about ... but I think it might be wrong
<tantek> tab: I'm happy to review the algorithm, dealing with issues as they come. I don't think they should block anything
<tantek> dbaron: one other note, does bikeshed have a way to find specs that reference the term that I just removed?
<tantek> tab: not yet
<tantek> tab: I'd like to expose it
<tantek> tab: and give you a way to track it
<tantek> tab: it's imminently possible, just haven't done the actual work
<tantek> dbaron: I removed "evaluate a selector" and suggested replacement is ".... selector against a tree"
<tantek> dbaron: I put a suggestion in the changes section in a fragment, but that might not stay around
<tantek> dbaron: these are API hooks for other specs to reference
<tantek> astearns: anything else on Selectors 4?
<tantek> astearns: let's go onto the propagation of the :focus pseudo
<astearns> github: https://github.com//issues/1240
<tantek> Florian: we've discussed this a couple of times already
<tantek> Florian: we defined how :active works deferred to HTML, we did also for :focus but incorrectly deferred to HTML
<tantek> Florian: so our spec makes no sense
<tantek> Florian: easiest fix, leave :active as is, point :focus at the right thing
<tantek> Florian: or we could define what :focus does
<tantek> Florian: 3rd aspect, open issue on *how* it should work
<tantek> Florian: without being specific about hover and active but not focus propagate from a labeled form control to the form control but not back
<tantek> Florian: at some point we defined that all three should propagate both directions
<tantek> Florian: if we defer to them there, it overturns our prev resolution
<tantek> Florian: if we define it here, we may be able keep current resolution
<tantek> Florian: IE used to propagate both dirs, but Edge does not
<tantek> Rossen: we might've done something for interop
<tantek> Florian: I tested this a few months ago
<tantek> Florian: do we just defer to whichever group manages HTML these days? or do we takeover? How much do we takeover?
<tantek> TabAtkins: I think it is still a host language thing, I don't think we should take over
<tantek> TabAtkins: should be easy enough to get WHATWG to fix that
<astearns> testcase from previous discussion? data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw+DQogIDxzdHlsZT4NCiAgICA6Zm9jdXMgeyBiYWNrZ3JvdW5kOiBvcmFuZ2U7fQ0KICA8L3N0eWxlPg0KICA8bGFiZWwgZm9yPXlvPkZvbzwvbGFiZWw+DQogIDxpbnB1dCBpZD15bz4=
<tantek> TabAtkins: whether or not active and focus prop. to their ancestors is ... ?
<tantek> s/TabAtkins: whether/Florian: whether
<tantek> Florian: so in the gh issue I proposed a phrasing
<tantek> Florian: open issue to get them to fix it
<tantek> Florian: shall we do that or shall we takeover more
<tantek> TabAtkins: I disagree with your proposal
<tantek> TabAtkins: would prefer to defer to host language for parent element too
<tantek> TabAtkins: regarding prop. upward
<tantek> Florian: ok I can fix that
<tantek> TabAtkins: otherwise it seems pretty good
<tantek> Florian: is that a resolution? accept Florian's changes with Tab's fix?
<tantek> Florian: separately we may want to continue to debate whether not they prop. to label/form control?
<tantek> Florian: regarding whether we should make a statement to the WHATWG on this
<tantek> astearns: Tab's change is to ... ?
<tantek> astearns: is this in a draft?
<tantek> Florian: just in the issue, I can turn it into a pull request
<tantek> astearns: proposed resolution is to take changes outlined in 3rd comment in the issue, with Tab's amendment re: must not match focus
<tantek> astearns: any objections to taking Florian's change?
<tantek> RESOLVED: take changes outlined in 3rd comment in the issue https://github.com//issues/1240, with Tab's amendment re: must not match focus
<tantek> Florian: shall also discuss next issue? we have also resolved on not what the HTML spec says
<tantek> astearns: I'm unclear whether a group resolution would help
<tantek> astearns: they have our input already
<tantek> Florian: kinda. last time two people objected. one was bz with a well reasoned argument. and the other was ryosuke who said we don't need this because we have the :has selector - which we don't have , so that objection is invalid
<tantek> Florian: but bz objection is still valid
<tantek> astearns: can you update the issue that we made this change and are still waiting?
<tantek> Florian: a major part of the pushback from WHATWG is that for hover in particular this is expensive because hover events can fire a lot around the page
<tantek> Florian: some people say just active, and some say ... ?
<tantek> Florian: or the other thing with IDref (?) like selector?
<tantek> Florian: shall I write something?
<tantek> Florian: or does WG not care?
<tantek> tantek: I think we can't follow
<tantek> action Florian follow-up on the issue
<trackbot> Created ACTION-855 - Follow-up on the issue [on Florian Rivoal - due 2017-08-09].
<tantek> Florian: static vs dynamic profile?
<tantek> Florian: important to change the name
<tantek> Florian: everyone misunderstands static vs dynamic - as in this means JS or not
<tantek> TabAtkins: I agree - too much confusion - I want to change the names also
<tantek> Florian: this is related because it sounded like Apple engineers were confused

[frivoal]

@tabatkins Does this work better than the previous phrasing?

Document languages may define additional ways in which an element can match :focus, except that the :focus pseudo class must not propagate to the parent element (see :focus-within if matching on the parent is desired). Note: it may still apply to the parent element if made to propagate due to other mechanisms, but not merely due to being the parent.

[tabatkins]

"must not automatically propagate" and then 👍