- From: Jen Simmons via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Jul 2019 01:13:24 +0000
- To: public-css-archive@w3.org
Jonathan Kew at Mozilla pointed something out to me that made me realize I think I've been misunderstanding what Safari's current implementation does. He said: > According to my testing, it's not exactly that negative values cause the underline to disappear, what's happening is that once the underline crosses the baseline of the text, `skip-ink` behavior kicks in and makes it disappear. If you make the offset so negative that it moves above the letters, it starts to appear again (skipping ascenders etc at first), and sometimes you'll see bits of it in between letters even when it's mostly hidden "behind" them. I had thought Safari made the underline disappear for any offset value less than 0 — that the line was disappearing because it was being clipped. That's not the case. Instead, this raises the point that without `text-decoration-skip-ink: none` the line does appear to get clipped. Safari needs to implement `text-decoration-skip-ink: none` to make the toolset complete. (And Firefox needs to implement `text-decoration-skip-ink` in general. We hope to do so as we implement the rest of these properties for styling underlines.) I don't know that this realization affects the decision before us, but it's true that Authors will need to learn to always pair an explicit `text-decoration-skip-ink: none` every time the want to use `text-underline-offset: [negative value]` — or the line will seem to disappear, and that might be confusing. Apparently it was for me. -- GitHub Notification of comment by jensimmons Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-514439786 using your GitHub account
Received on Wednesday, 24 July 2019 01:13:26 UTC