[css-text-decor-4] Variants of text-decoration-skip-spaces:end behavior, and initial value #4653
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
added
Closed as Question Answered
|
The CSS Working Group just discussed 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
added a commit
to web-platform-tests/wpt
that referenced
this issue
Sep 5, 2022
|
tests: web-platform-tests/wpt#35780 |
frivoal
added
Tested
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
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:white-spaceispre-wrap, but notpreorbreak-spaceswhite-spaceispre-wrap, but notpreorbreak-spacesI wonder if we need to make the
endvalue (and maybe other values) smarter, or if we need anautoof some kind in addition, or if this is just historical accident and all UAs will align on the specified behavior ofendAlso, the spec says that the initial value of
text-decoration-skip-spacesisstart end, which is consistent with what level 3 said in prose. However, Chrome behaves as if the initial value wasnone, and Firefox / Safari behave as if the initial value wasmagic-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…The text was updated successfully, but these errors were encountered: