- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Jul 2023 16:32:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo] highlight pseudos and non-applicable properties`, and agreed to the following:
* `RESOLVED: If a unit (or similar value) relies on the value of a property that's not appicable to highlights to resolve itself, it uses the value from the originating element.`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> schenney: this issue arises when properties in highlights, like shadow blur radius, etc<br>
<TabAtkins> schenney: use property value s that have font-dependent metrics<br>
<TabAtkins> schenney: or any ohter type of context-dependent value that can only be resolved from outside the highlight<br>
<TabAtkins> schenney: like, you can't set font-size on a highlight, but if you use 1em in the highlight we need to look that up somehow<br>
<TabAtkins> schenney: Currentl the spec would have us walk the highlight chain for a font-size proeprty, never find one, and use the initial value<br>
<TabAtkins> schenney: So the proposal is that property-depedent metrics you find in a highlight property, you take from the originating element<br>
<TabAtkins> schenney: font size, line height, etc<br>
<delan> q+<br>
<florian> q+<br>
<TabAtkins> schenney: So if you use the same property on the el and the highlight you'd get the same behavior<br>
<Rossen_> ack delan<br>
<TabAtkins> delan: a few extra notes<br>
<TabAtkins> delan: font-size and line-height are, as the issue title says, they're not applicable properties for highlights<br>
<TabAtkins> delan: can't actually change them in highlights, we odn't want highlighting to change the font size<br>
<TabAtkins> delan: so when you highlight *in practice* it takes the font-size and line-height from what it would be when it wasn't selected<br>
<TabAtkins> delan: So we're trying to make the font-relative units consistent with that, matching the acutal used font-size and line-height<br>
<TabAtkins> delan: rather than some arbitrary initial value<br>
<TabAtkins> delan: Also, we had a previous resolution for this a while back<br>
<TabAtkins> delan: but it seemed muddled, there were other issues mixed in<br>
<TabAtkins> delan: But all we're really trying to do is resolve what happens when you use em/etc units<br>
<TabAtkins> delan: not really changing anything else here about how shadows or decorations work in highlights, just what happens with those units<br>
<Rossen_> q?<br>
<Rossen_> ack florian<br>
<TabAtkins> florian: So we're not *really* discussing property inhertiance, just unit resolution<br>
<TabAtkins> fantasai: I support this proposal and think it's the right thing, and the fact that it's implemented is great<br>
<Rossen_> q?<br>
<florian> +1<br>
<Rossen_> ack florian<br>
<Rossen_> ack fantasai<br>
<TabAtkins> emilio: can't we just... could we fix the previous issue the same way<br>
<delan> q+<br>
<schenney> q+<br>
<fantasai> TabAtkins: That was the 'don't inherit custom props at all, just from originating element'. That runs into you expect custom props to inherit<br>
<fantasai> TabAtkins: [missed]<br>
<delan> q-<br>
<fantasai> TabAtkins: it ends up being a lot weirder in a lot of cases<br>
<fantasai> TabAtkins: We talked about that solution earlier, i.e. not inheriting custom props at all and inheriting from originating element<br>
<schenney> q-<br>
<fantasai> TabAtkins: that ends up being more confusing, because you can't set custom props on highight a tall, you have to rely on light DOM to inherit<br>
<fantasai> TabAtkins: was confusing that you could set a var() but not set it in the same place<br>
<Rossen_> q?<br>
<fantasai> TabAtkins: Because resolution is off a completely different element<br>
<schenney> q+<br>
<fantasai> TabAtkins: basically it's confusing<br>
<TabAtkins> `::highlight { --foo: 1; --bar: var(--foo); }` would *not* do what you think<br>
<Rossen_> ack schenney<br>
<TabAtkins> schenney: Yeah I think the previous behavior would be the bad author behavior, using differnet metric values than what you'd see if you used that property on the originating element<br>
<Rossen_> q?<br>
<TabAtkins> Rossen_: so do we still have a proposed resolution?<br>
<delan> q+<br>
<TabAtkins> schenney: I propose that font and other metrics that used in highlights, where that value isn't available from a highlight-applicable property, use the originatig element to resolve that unit<br>
<dbaron> dbaron: Just to clarify: that's about whether the property in question is *valid* for highlights, not whether it's used.<br>
<dbaron> schenney: yes<br>
<TabAtkins> delan: I wonder if this could be phrased more simply as "in a highlight pseudo, the values of font-relative metrics come from the originating element"<br>
<TabAtkins> schenney: I'm concerned that any other cases where this problem arises need a general resolution<br>
<TabAtkins> delan: fair<br>
<Rossen_> q?<br>
<Rossen_> ack delan<br>
<delan> q+<br>
<TabAtkins> dbaron: i think there's a very slight risk in the opposite direction, where a unit depends on a combo of proeprties where some are valid in highlights, and there you probably want it from the originating element still and not try to mix things<br>
<delan> q-<br>
<TabAtkins> dbaron: maybe there's no example of that right now<br>
<TabAtkins> Rossen_: so returning to the resolution, any objections?<br>
<TabAtkins> RESOLVED: If a unit (or similar value) relies on the value of a property that's not appicable to highlights to resolve itself, it uses the value from the originating 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-1642405339 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 July 2023 16:32:59 UTC