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.

The CSS Working Group just discussed Propagation of focus.

<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]

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).

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.

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

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

@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.

"must not automatically propagate" and then 👍