Skip to content
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-decor-4] Variants of text-decoration-skip-spaces:end behavior, and initial value #4653

Closed
frivoal opened this issue Jan 7, 2020 · 2 comments
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. css-text-decor-4 Tested Memory aid - issue has WPT tests

Comments

@frivoal
Copy link
Collaborator

frivoal commented Jan 7, 2020

Safari and Firefox both have built-in default behavior that's sort of like text-decoration-skip-spaces: end, but not quite the same as the one specified, and not quite the same as each other:

  • Safari skips all preserved U+0020 (but not  , or U+3000, or U+2007) on the end side if white-space is pre-wrap, but not pre or break-spaces
  • Firefox skips overflowing preserved U+0020 (but not  , or U+3000, or U+2007) on the end side if white-space is pre-wrap, but not pre or break-spaces

I wonder if we need to make the end value (and maybe other values) smarter, or if we need an auto of some kind in addition, or if this is just historical accident and all UAs will align on the specified behavior of end

Also, the spec says that the initial value of text-decoration-skip-spaces is start end, which is consistent with what level 3 said in prose. However, Chrome behaves as if the initial value was none, and Firefox / Safari behave as if the initial value was magic-end (see previous point) and don't skip leading spaces at all. Not sure if the spec should align with the browsers or the other way around, but the discrepancy is worth noting. We do have a resolution in favor of what the spec says, so it's probably just a matter of writing tests and filing bugs…

@frivoal frivoal added Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. Needs Testcase (WPT) and removed Agenda+ F2F labels May 6, 2020
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Variants of text-decoration-skip-spaces:end behavior, and initial value.

The full IRC log of that discussion <astearns> topic: Variants of text-decoration-skip-spaces:end behavior, and initial value
<astearns> github: https://github.com//issues/4653
<TabAtkins> florian: text-decoration-skip-spaces has a start and end value, meant to make the browser not undelrine spaces at the start and end of the line
<TabAtkins> florian: Spec is specific about what exactly you're supposed to skip
<TabAtkins> florian: In the first approximation it's "all the whitespace"
<TabAtkins> florian: Implemennted in Safari and Firefox, which do differetn from the spec and each other
<TabAtkins> [florian, please fill in these Safari details]
<TabAtkins> florian: In Firefox, it's not only doing (Safari's behavior), it's only skipping them if they're overflowing, not if they fit in the line
<TabAtkins> florian: Possibly they're bugs and need to be fixed, but double-checking that the spec is indeed what we want, given the variants.
<TabAtkins> florian: Also the initial value is different across browsers.
<TabAtkins> florian: Spec says default is "start end"; Level 3 didn't have this as a property but specified it in prose.
<TabAtkins> florian: Chrome behaves as if initi8al value is "none", Safari/Firefox behave as their special variants of "end"
<TabAtkins> florian: So possibly spec is fine and impls are buggy, but if it's intentionally deviating, we should consider that
<TabAtkins> myles: Safari's behavior was implemented before this property existed, I don't think it should influence this.
<TabAtkins> astearns: Action here might just be to file bugs
<myles> s/Safari/WebKit/
<TabAtkins> astearns: And ahve those discussion with implementors
<TabAtkins> astearns: If need be, we can come back to spec changes after
<TabAtkins> fantasai: Yeah, reason to file was just to check that, given the variances, we really wanted the spec behavior.
<TabAtkins> astearns: Any input from Firefox?
<TabAtkins> jkew: I don't currently have an opinion.
<TabAtkins> florian: Okay, so I'll file bugs, assume the spec is good, and we can circle back if there are complaints.
<myles> ScribeNick: myles

@frivoal frivoal closed this as completed Sep 5, 2022
@frivoal frivoal added Tested Memory aid - issue has WPT tests and removed Needs Testcase (WPT) labels Sep 5, 2022
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Sep 24, 2022
…testonly

Automatic update from web-platform-tests
Add test for underline edge skipping

As per w3c/csswg-drafts#4653

--

wpt-commits: 249e1eb8e6542731f41738ab11def2aae4548375
wpt-pr: 35780
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Sep 27, 2022
…testonly

Automatic update from web-platform-tests
Add test for underline edge skipping

As per w3c/csswg-drafts#4653

--

wpt-commits: 249e1eb8e6542731f41738ab11def2aae4548375
wpt-pr: 35780
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. css-text-decor-4 Tested Memory aid - issue has WPT tests
Projects
None yet
Development

No branches or pull requests

3 participants