-
Notifications
You must be signed in to change notification settings - Fork 679
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-text-3][css-fonts-3][css-text-decor-3] Distinguish applying to text vs applying to boxes #5303
Comments
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 |
The CSS Working Group just discussed
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}
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
…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
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
The CSS Working Group just discussed 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 |
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-008.html References: 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
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:
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?)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: