- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Sep 2022 16:43:06 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `highlight pseudos and non-applicable properties`, and agreed to the following: * `RESOLVED: Properties that don't apply on highlight pseudos are ignored` * `RESOLVED: for the highlight pseudos on the root element, all of the font settings are taken from the element` <details><summary>The full IRC log of that discussion</summary> <heycam> Topic: highlight pseudos and non-applicable properties<br> <heycam> github: https://github.com/w3c/csswg-drafts/issues/7591<br> <heycam> fantasai: look at the example in the issue<br> <heycam> ... it's showing a ::highlight with a text-shadow with an offset expressed as 1em<br> <heycam> ... there's a parent selection pseudo with a font-size:69px, and the actual element has a font-size:42px<br> <heycam> ... font-size does not apply to ::highlight, so the actual font is going to be 42px<br> <heycam> ... the question is, when we're computing the value of 1em, are we using the font-size assigned to the selection even though it doesn't apply, and cannot apply, or do we ignore that font-size and use the value from the originating element?<br> <dandclark> q+<br> <heycam> s/::highlight/::selection/<br> <heycam> fantasai: implementations do various things. Blink uses the initial value, which is 16px<br> <heycam> ... the question is what do we want to do?<br> <heycam> ... using the actual font-size would give the most expected results from the author perspective<br> <heycam> dandclark: I agree with that<br> <Rossen_> ack dandclark<br> <emilio> q+<br> <heycam> ... definitely seems the most intuiitive thing here, i.e. the font-size of the originating element<br> <heycam> ... anything else seems strange to me<br> <Rossen_> ack emilio<br> <heycam> emilio: we have precedent for this<br> <heycam> ... things like ::placeholder already ignore a bunch of properties, and they do so by ignoring the declarations<br> <heycam> ... so as if the font-size declaration wasn't there<br> <heycam> ... I htink that's what's being proposed here, and I think that's reasonable<br> <heycam> fantasai: proposed resolution is we use the actual, effective font-size (and font-family, etc.) here<br> <heycam> emilio: can we word it as declarations of not supported properties are ignored instead?<br> <heycam> fantasai: it inherits from the parent selection<br> <heycam> emilio: that's trickier then<br> <heycam> fantasai: we can say both things<br> <heycam> emilio: I think that's weird<br> <heycam> ... I'd rather keep it simple and ignore the declarations<br> <heycam> astearns: if we ignore the declarations, and just do the normal inheritance, even though the value is ignored, don't we get what we want?<br> <heycam> fantasai: you get the initial font-size<br> <heycam> emilio: or the root element's font-size<br> <heycam> ... weird to add another source of inputs here<br> <heycam> Rossen: if we don't do that what makes most sense?<br> <heycam> ... on one hand we have the default 16px<br> <heycam> ... that seems less useful<br> <heycam> astearns: don't understand why we get the initial font-size<br> <heycam> ... the pseudo is on an element that has a font-size<br> <heycam> fantasai: but it doesn't inherit from that element<br> <heycam> ... ::highlight inherits from the parent element's selection<br> <heycam> ... we rewired highlight inheritance like this<br> <heycam> Rossen: the intiial font-size, is that because you simply end up with the root size?<br> <heycam> fantasai: yes<br> <Rossen_> ack dbaron<br> <heycam> dbaron: I was just thinking about the desired behavior here<br> <heycam> ... if you have a selection with text-shadow that's got a 1em in it, and that selection crosses elements with different font sizes, do you actually expect that the shadow has a different offset or spread as the selection crosses those elements?<br> <heycam> fantasai: maybe, maybe not<br> <heycam> ... depends on what you were aiming for with the effect<br> <heycam> ... I think having it be consistent across them is not unreasonable<br> <heycam> Rossen: what do we do for outline?<br> <heycam> fantasai: that doesn't inherit<br> <heycam> dbaron: one of the other factors here is that a principle about selection styling is that you shouldn't get different results depending on where the selection starts<br> <JakeA> q+<br> <heycam> ... so if your selection starts further up ancestor, which has a different font-size, versus a narrow selection scoped to a descendant with a different font size, those descendants shouldn't render differently<br> <heycam> fantasai: I think both proposals follow that principle<br> <Rossen_> ack JakeA<br> <heycam> JakeA: is currentColor an issue here? for the same reason?<br> <heycam> fantasai: currentColor inherits as its own keyowrd, and resolves on each element<br> <heycam> ... for highlights it has some special behavior<br> <heycam> ... I think maybe it's just on the color property? it doesn't look as its parent, it looks at its originating element<br> <heycam> Rossen: I think following David's principle, that principle is satisfied<br> <heycam> ... from the user's PoV this is arguably what you want<br> <heycam> ... to Jake's point, if we model this on the same way color / currentColor works ...<br> <heycam> fantasai: color inherits from the parent selection, not the originating element<br> <heycam> ... currentColor on all other properties than color, looks at color<br> <heycam> ... normally color:currentColor is like inherit, but for highlights it takes the originating element's color<br> <heycam> ... so if you have a highlight where you're only doing say underlining, it gives you a way to "use the original color"<br> <heycam> ... rather than parent's color<br> <heycam> Rossen: so for em resolution<br> <heycam> ... seems like we could have the same behavior<br> <JakeA> q+<br> <fantasai> heycam: If you set font-size:inherit...<br> <fantasai> heycam: analog is, you're using the currentColor keyword on a property other than color, is the analogy is for having em values in some other property<br> <fantasai> heycam: if you used em values in the font-size property, that's more of an analog to using currentColor in color property<br> <Rossen_> ack JakeA<br> <heycam> JakeA: when you talk about the originating element of the highlight<br> <heycam> ... what happens in the case where the highlight spans multiple elements?<br> <heycam> fantasai: multiple pieces of highlight, each has an originating element<br> <heycam> ... if we consider dbaron's comment, making font relative values always resolve against the initial values seems to be most consistent with the principle<br> <heycam> Rossen: I'd argue from a user PoV that makes no sense<br> <heycam> ... [something about highlight sizes]<br> <heycam> fantasai: the size of the highlight doesn't change<br> <heycam> dbaron: I tend to be in favor of what Elika just proposed<br> <miriam> q+<br> <heycam> ... the alternative seems like it would be hard to implement<br> <fantasai> proposal was that, since having consistent resolution from 1em is not unreasonable in many cases, and is already implemented in Blink, then we should resolve on that<br> <heycam> ... and I don't think we've heard any good use cases for the alternative, i.e. do people really have demands for em offsetted text-shadow that varies on elements<br> <heycam> miriam: would it be closer to author intent to use root ems instead of browser default?<br> <heycam> emilio: that's the behavior you get when you ignore declarations<br> <Rossen_> ack miriam<br> <heycam> fantasai: I think the spec is a bit unclear on that<br> <heycam> ... so whatever we decide here is how we'll clarify it<br> <heycam> Rossen: hearing consensus forming around Elika's proposal, with using root ems intead of the initial value of font-size<br> <heycam> ... any other proposals?<br> <heycam> dandclark: should this be more general than font-size?<br> <heycam> ... lots of other properties that don't apply to highlights<br> <heycam> fantasai: we're applying it to all font properties, taken from the root<br> <heycam> ... all of the decalrations on pseudos that are defined not to apply are ignored<br> <heycam> fantasai: proposed resolution: declarations on highlight pseudos defined as not applied are ignored, and font properties are all taken from the root element<br> <heycam> RESOLVED: Properties that don't apply on highlight pseudos are ignored<br> <heycam> fantasai: I think we say that for the ::selection on the root element (and therefore inheriting down into other highlights), all of the font settings are taken from the root element<br> <heycam> RESOLVED: for the highlight pseudos on the root element, all of the font settings are taken from the element<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7591#issuecomment-1248353705 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 September 2022 16:43:08 UTC