[css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes #5303

fantasai · 2020-07-09T00:23:29Z

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?

The text was updated successfully, but these errors were encountered:

Loirooriol · 2020-07-09T12:02:40Z

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-height on Firefox, but on Chromium it does apply to text. Testcase

css-meeting-bot · 2020-10-22T16:00:12Z

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 text

The 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/

The CSSWG resolved in w3c/csswg-drafts#4568 that inherited properties that apply to text can be set on ::marker and should affect the marker text. And in w3c/csswg-drafts#5303 it resolved that 'line-height' applies to text (as it already does in Chromium). Therefore, this patch allows 'line-height' in ::marker. Note it was already possibly to set it to the list item and the ::marker would inherit it. Just letting authors set it directly to the ::marker. Bug: 1031667 TEST=external/wpt/css/css-pseudo/marker-line-height.html TEST=external/wpt/css/css-pseudo/parsing/marker-supported-properties-in-animation.html TEST=external/wpt/css/css-pseudo/parsing/marker-supported-properties.html marker-line-height.html fails in legacy because ::markers with 'content: normal' are not implemented with actual text. Change-Id: If63095d046150a2b5f76c40fce93fce1c0e7741c

The CSSWG resolved in w3c/csswg-drafts#4568 that inherited properties that apply to text can be set on ::marker and should affect the marker text. And in w3c/csswg-drafts#5303 it resolved that 'line-height' applies to text (as it already does in Chromium). Therefore, this patch allows 'line-height' in ::marker. Note it was already possibly to set it to the list item and the ::marker would inherit it. Just letting authors set it directly to the ::marker. Bug: 1031667 TEST=external/wpt/css/css-pseudo/marker-line-height.html TEST=external/wpt/css/css-pseudo/parsing/marker-supported-properties-in-animation.html TEST=external/wpt/css/css-pseudo/parsing/marker-supported-properties.html marker-line-height.html fails in legacy because ::markers with 'content: normal' are not implemented with actual text. Change-Id: If63095d046150a2b5f76c40fce93fce1c0e7741c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2438413 Commit-Queue: Oriol Brufau <obrufau@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#821293}

The CSSWG resolved in w3c/csswg-drafts#4568 that inherited properties that apply to text can be set on ::marker and should affect the marker text. And in w3c/csswg-drafts#5303 it resolved that 'line-height' applies to text (as it already does in Chromium). Therefore, this patch allows 'line-height' in ::marker. Note it was already possibly to set it to the list item and the ::marker would inherit it. Just letting authors set it directly to the ::marker. Bug: 1031667 TEST=external/wpt/css/css-pseudo/marker-line-height.html TEST=external/wpt/css/css-pseudo/parsing/marker-supported-properties-in-animation.html TEST=external/wpt/css/css-pseudo/parsing/marker-supported-properties.html marker-line-height.html fails in legacy because ::markers with 'content: normal' are not implemented with actual text. Change-Id: If63095d046150a2b5f76c40fce93fce1c0e7741c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2438413 Commit-Queue: Oriol Brufau <obrufau@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#821293}

…rty in ::marker, a=testonly Automatic update from web-platform-tests [css-pseudo] Support 'line-height' property in ::marker The CSSWG resolved in w3c/csswg-drafts#4568 that inherited properties that apply to text can be set on ::marker and should affect the marker text. And in w3c/csswg-drafts#5303 it resolved that 'line-height' applies to text (as it already does in Chromium). Therefore, this patch allows 'line-height' in ::marker. Note it was already possibly to set it to the list item and the ::marker would inherit it. Just letting authors set it directly to the ::marker. Bug: 1031667 TEST=external/wpt/css/css-pseudo/marker-line-height.html TEST=external/wpt/css/css-pseudo/parsing/marker-supported-properties-in-animation.html TEST=external/wpt/css/css-pseudo/parsing/marker-supported-properties.html marker-line-height.html fails in legacy because ::markers with 'content: normal' are not implemented with actual text. Change-Id: If63095d046150a2b5f76c40fce93fce1c0e7741c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2438413 Commit-Queue: Oriol Brufau <obrufau@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#821293} -- wpt-commits: 91da84149d57c560e3435866fd198d1910c22e3f wpt-pr: 25886

…ss-color-adjust] Be explicit about which properties apply to text. w3c#5303

frivoal · 2020-12-03T04:39:06Z

Proposed PR in #5761

…ss-color-adjust] Be explicit about which properties apply to text. w3c#5303

[css-text][css-text-decor][css-writing-modes][css-color][css-fonts][css-color-adjust] Be explicit about which properties apply to text. #5303

…ies to text. #5303

css-meeting-bot · 2020-12-09T17:15:57Z

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 · 2020-12-19T23:19:39Z

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.

The CSSWG resolved in w3c/csswg-drafts#4568 that inherited properties that apply to text can be set on ::marker and should affect the marker text. And in w3c/csswg-drafts#5303 it resolved that 'line-height' applies to text (as it already does in Chromium). Therefore, this patch allows 'line-height' in ::marker. Note it was already possibly to set it to the list item and the ::marker would inherit it. Just letting authors set it directly to the ::marker. Bug: 1031667 TEST=external/wpt/css/css-pseudo/marker-line-height.html TEST=external/wpt/css/css-pseudo/parsing/marker-supported-properties-in-animation.html TEST=external/wpt/css/css-pseudo/parsing/marker-supported-properties.html marker-line-height.html fails in legacy because ::markers with 'content: normal' are not implemented with actual text. Change-Id: If63095d046150a2b5f76c40fce93fce1c0e7741c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2438413 Commit-Queue: Oriol Brufau <obrufau@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#821293} GitOrigin-RevId: cd65c12e6f6656135a93a57b339a4cffeb3684c1

fantasai added css-fonts-4 Current Work css-text-3 Current Work css-text-decor-3 Current Work labels Jul 9, 2020

fantasai mentioned this issue Jul 9, 2020

[css-pseudo] Which properties to reset in ::marker #4568

Open

fantasai added the Agenda+ F2F label Sep 28, 2020

astearns added Agenda+ TPAC and removed Agenda+ F2F labels Oct 15, 2020

astearns added this to the TPAC-2020-08-22 milestone Oct 16, 2020

atanassov assigned frivoal and fantasai Oct 22, 2020

astearns removed the Agenda+ TPAC label Oct 22, 2020

mozilla-apprentice mentioned this issue Oct 22, 2020

[css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes mozilla/wg-decisions#403

Open

chromium-wpt-export-bot mentioned this issue Oct 27, 2020

[css-pseudo] Support 'line-height' property in ::marker web-platform-tests/wpt#25886

Merged

frivoal added Closed Accepted by CSSWG Resolution Needs Edits Needs Testcase (WPT) labels Nov 3, 2020

fantasai added a commit to fantasai/csswg-drafts that referenced this issue Dec 2, 2020

[css-text][css-text-decor][css-writing-modes][css-color][css-fonts][c…

d3e3f44

…ss-color-adjust] Be explicit about which properties apply to text. w3c#5303

frivoal added Agenda+ Needs Review of Proposed Text and removed Needs Edits labels Dec 3, 2020

fantasai added a commit to fantasai/csswg-drafts that referenced this issue Dec 8, 2020

[css-text][css-text-decor][css-writing-modes][css-color][css-fonts][c…

1339a16

…ss-color-adjust] Be explicit about which properties apply to text. w3c#5303

svgeesus added a commit that referenced this issue Dec 9, 2020

Merge pull request #5761 from fantasai/applies-to-text

39ded77

[css-text][css-text-decor][css-writing-modes][css-color][css-fonts][css-color-adjust] Be explicit about which properties apply to text. #5303

fantasai added a commit that referenced this issue Dec 9, 2020

[css-writing-modes-3] Update text-combine-upright to say that it appl…

0b31fa9

…ies to text. #5303

fantasai removed Agenda+ Needs Review of Proposed Text labels Dec 9, 2020

fantasai closed this as completed Dec 9, 2020

TalbotG mentioned this issue Dec 13, 2020

Added 6 white-space-applies-to-text tests and references web-platform-tests/wpt#26877

Merged

fantasai added the Tracked in DoC label Dec 15, 2020

Loirooriol mentioned this issue Nov 22, 2021

[fill-stroke] Clarify property definitions applying to "inline boxes" #6823

Closed

SebastianZ mentioned this issue Nov 22, 2021

[fill-stroke-3] Replace "inline boxes" by "text" in Applies to w3c/fxtf-drafts#441

Merged

frivoal added Tested Memory aid - issue has WPT tests and removed Needs Testcase (WPT) labels Dec 30, 2022

Loirooriol mentioned this issue Jan 15, 2024

[css-pseudo][css-writing-modes] text-orientation and ::marker #9788

Open

Loirooriol mentioned this issue May 23, 2024

[css-lists] The cursor property should apply to ::markers #6203

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes #5303

[css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes #5303

fantasai commented Jul 9, 2020

Loirooriol commented Jul 9, 2020 •

edited

css-meeting-bot commented Oct 22, 2020

frivoal commented Dec 3, 2020

css-meeting-bot commented Dec 9, 2020

TalbotG commented Dec 19, 2020

[css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes #5303

[css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes #5303

Comments

fantasai commented Jul 9, 2020

Loirooriol commented Jul 9, 2020 • edited

css-meeting-bot commented Oct 22, 2020

frivoal commented Dec 3, 2020

css-meeting-bot commented Dec 9, 2020

TalbotG commented Dec 19, 2020

Loirooriol commented Jul 9, 2020 •

edited