[css-text-decor-4] Variants of text-decoration-skip-spaces:end behavior, and initial value

[frivoal]

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…

[css-meeting-bot]

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]

tests: web-platform-tests/wpt#35780
firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1789266
webkit bug: https://bugs.webkit.org/show_bug.cgi?id=244813
chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1360067