- From: Delan Azabani via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Jun 2023 12:12:53 +0000
- To: public-css-archive@w3.org
Unfortunately I wasn’t able to attend the call, but after reading the resolution and the underlying discussion, I think we’ve only really solved the problem for the root highlights. For highlights elsewhere in the tree, making 1em compute to 1rem means that if the text is any other size, 1em will have no connection with reality. I wonder if we can make ‘font-size’ and ‘line-height’ inherit from the originating element everywhere in the tree, like we did for ‘forced-color-adjust’ and forced colors mode in #7264. I actually misunderstood the resolution at first and thought that’s what we decided, and ended up implementing it that way in [CL:3818830](https://crrev.com/c/3818830) (though there’s currently a bug in how it interacts with [zero-cost inheritance](https://www.azabani.com/talks/2022-11-16-faster-style-and-paint-for-css-highlights/#/15), which I’ll have to figure out with @andruud). > \<heycam> dbaron: I was just thinking about the desired behavior here > \<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? > \<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 > \<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 > […] > \<heycam> fantasai: multiple pieces of highlight, each has an originating element > \<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 All of the approaches mentioned including 1. taking ‘font-size’ from initial values (16px) 2. taking ‘font-size’ from the originating element at the root only (42px) 3. taking ‘font-size’ from the originating element everywhere in the tree obey the principle that descendants should render the same way when the selection is expanded to include ancestors. That said, how big ‘1em’ is in a shadow depends on where in the tree the shadow was defined, because ‘1em’ is not inherited as ‘1em’, but rather whatever concrete size it computes to. For example, given a page with `div { font-size: 7em; }`… * `<html style="text-shadow: 1em 1em;">foo<div>bar` = foo is 1rem 1rem, bar is 1rem 1rem * and the same goes for `html::selection { text-shadow: 1em 1em; }` * `<html>foo<div style="text-shadow: 1em 1em;">bar` = foo is none, bar is 7rem 7rem * and the same goes for `div::selection { text-shadow: 1em 1em; }` * `<html>foo<div>bar` with `* { text-shadow: 1em 1em; }` = foo is 1rem 1rem, bar is 7rem 7rem * and the same goes for `*::selection { text-shadow: 1em 1em; }` -- GitHub Notification of comment by delan Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7591#issuecomment-1578649052 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 June 2023 12:12:55 UTC