Repository navigation
[css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes #5303
Description
We've historically only used the 'Applies to' lines to apply to boxes, but it seems we do need to distinguish whether something applies to an inline box vs. line box vs. text:
- For ::marker, a lot of properties don't apply to the marker box, because we don't know what kind of box an outside marker is yet. But they should inherit through to the text and apply there.
- For
display: contents, properties can be applied to an element that generates no box, but still be pass through to its text.
So I'm thinking we should update the propdef tables of properties that apply to text to say "and text", so we can better define how these cases work. I think the rough idea is to do that for:
color(and maybe all of css-color-adjust?)- all font properties
- all inheritable css-text-decor properties
- all properties in css-text that apply to inline boxes?
and, going forward, not do that for any properties that rely on knowing box geometry.
(See https://www.w3.org/TR/css-display-3/#intro for discussion of boxes/elements/text runs etc.)
Does this make sense?
Activity
Loirooriol commentedon Jul 9, 2020
My assumption was that all inherited properties that apply to inline boxes, also apply to text.
Seems my assumption was wrong in the case of
line-heighton Firefox, but on Chromium it does apply to text. Testcasecss-meeting-bot commentedon Oct 22, 2020
The CSS Working Group just discussed
Distinguish applying to text vs applying to boxes, and agreed to the following:RESOLVED: inheritable properties that apply to inlines also apply to textThe full IRC log of that discussion
<Rossen_> Topic: Distinguish applying to text vs applying to boxes<Rossen_> github: istinguish applying to text vs applying to boxes
<Rossen_> github: https://github.com//issues/5303
<fremy> fantasai: it's not super clear which property apply to text, and which apply to inline boxes
<fremy> fantasai: the specs sometimes says one when they mean the other
<TabAtkins> testcase from oriol showing off the distinction:
<TabAtkins> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Asection%20%7B%20border%3A%201px%20solid%20%7D%0Adiv%20%7B%20line-height%3A%204%3B%20display%3A%20contents%20%7D%0A%3C%2Fstyle%3E%0A%3Csection%3E%3Cdiv%3Eline-height%20inherited%20by%20text%3C%2Fdiv%3E%3C%2Fsection%3E%0A%3Csection%3E%3Cdiv%3E%3Cspan%3Eline-height%20inherited%20by%20inline%20box%3C%2Fspan%3E%3C%2Fdiv%3E%3C%2Fsection%3E
<fremy> fantasai: but for some properties we need a distinction
<TabAtkins> chrome renders the two boxes the same, firefox doesn't apply line-height to the first (where there is no box to apply to, only text)
<fremy> fantasai: I propose to make a mass update to say "text" vs "inline boxes" vs "inline boxes and text"
<fremy> fantasai: text decoration, color, etc...
<fremy> fantasai: this will require some auditing of the existing propdef tables
<fremy> florian: I initially agreed
<chris> seems good to me, I think it is clearer
<fremy> florian: but oriol made a test case and it confused me
<fremy> florian: because content makes an anonymous inline
<fremy> florian: so what's the difference between the two concepts, I am not sure
<fremy> fantasai: is there an anonymous inline? really?
<fremy> TabAtkins: as far as I know, there is not
<fremy> florian: ah ok, then we need to specify
<fremy> emilio: webkit allows display:contents on text, but we don't in gecko
<fremy> TabAtkins: do you think this makes a different except line-height?
<fremy> emilio: no, apart from that, I don't think there is a difference
<fremy> florian: and the whitespace property?
<fremy> florian: if there is no inline box? how would that work?
<fremy> emilio: I would have to test
<fremy> emilio: I remember we used to apply only the closest inline container
<fremy> emilio: and we changed this, but I don't recall the specifics
<Rossen_> q
<fremy> oriol: one of the principles we should try to follow is to use inheritance as a rule
<fremy> oriol: otherwise there could be differences if you have or not the inline
<fremy> TabAtkins: that sounds like a reasonable rule to me
<fremy> TabAtkins: and whitespace works in firefox
<fremy> Rossen_: so could line-height be a bug in gecko?
<fremy> florian: did the list you made match oriol rule?
<fremy> fantasai: I think so, but the list was very rough I didn't take a full look
<fremy> fantasai: there might be issues with alignment
<fremy> fantasai: but we can take a look later
<fremy> florian: I support resolving oriol rule then
<fremy> florian: and we can revisit if needed later
<fremy> Rossen_: and we need to add this rule?
<fremy> florian: yes, we should indeed do that, there is no text now
<fremy> Rossen_: ok, sounds go
<fremy> Rossen_: who will do that?
<fremy> florian: it could be me, but I am not sure when
<fremy> fantasai: ok I will take this
<fremy> Rossen_: ok, thanks
<fremy> Rossen_: do we need a resolution for oriol's rule?
<fremy> fantasai: yes, if we need exceptions we will revisit?
<fremy> Rossen_: ok, any objections to add this rule?
<fremy> fantasai: and update the propdef tables
<fremy> RESOLVED: inheritable properties that apply to inlines also apply to text
<florian> s/ but I am not sure when/ but it doesn't have to/
[css-pseudo] Support 'line-height' property in ::marker
[css-pseudo] Support 'line-height' property in ::marker
[css-pseudo] Support 'line-height' property in ::marker
8 remaining items
[css-text][css-text-decor][css-writing-modes][css-color][css-fonts][c…
Merge pull request #5761 from fantasai/applies-to-text
[css-writing-modes-3] Update text-combine-upright to say that it appl…
css-meeting-bot commentedon Dec 9, 2020
The CSS Working Group just discussed
[css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes.The full IRC log of that discussion
<dael> Topic: [css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes<dael> github: https://github.com//issues/5303
<dael> fantasai: Looks like chris mirged the PR. This will change applies to line for as many specs as I can think of. I guess heads up it's merged. There were questions about writing modes where so far text-combine-upwrite does apply
<dael> fantasai: css 3 text we're getting toward 0 issues. If i18n and tag sign off I'll ask to transition next week
<chris> s/mirged/merged/
<dael> florian: On testing front we're doing pretty good. Large amount of tests and gaps documented. We have test for many things. Don't need all for CR.
<dael> astearns: Any other bits on this?
<fantasai> s/does apply/does apply and writing-mode does not/
<dael> astearns: It was just informative? No resolutions?
<fantasai> https://github.com//issues/5303
<dael> fantasai: I guess if we want to close 5303 which is the bug
<dael> astearns: Since PR is merged yes I assume
<dael> florian: Might have missed some, but none was wrong. Can open new issue for anything missed
TalbotG commentedon Dec 19, 2020
CSS3Text property (white-space) that applies to inline boxes also apply to text
Tests:
http://www.gtalbot.org/BrowserBugsSection/CSS3Text/white-space-applies-to-text-007.html
http://www.gtalbot.org/BrowserBugsSection/CSS3Text/white-space-applies-to-text-008.html
References:
http://www.gtalbot.org/BrowserBugsSection/CSS3Text/reference/white-space-applies-to-text-007-ref.html
http://www.gtalbot.org/BrowserBugsSection/CSS3Text/reference/white-space-applies-to-text-008-ref.html
I will update PR26877 in a few min.
Bug 1668270 [wpt PR 25886] - [css-pseudo] Support 'line-height' prope…