W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2019

Re: [csswg-drafts] [css-text-decor] Limits on text-underline-offset to preserve semantic meaning (#4059)

From: Jen Simmons via GitHub <sysbot+gh@w3.org>
Date: Wed, 17 Jul 2019 17:19:49 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-512421819-1563383988-sysbot+gh@w3.org>
We were just discussing the possibility (after looking at the straw poll taken during the CSSWG call) that maybe we could settle on the following:

We do have a clamp (and it is a clamp, where the underline is always shown, not a clip where the underline disappears — as resolved on the call). And the clamp is at +/1 one-line-box. 

<img width="1309" alt="Underlining drawings 2019-07-17 13-14-57" src="https://user-images.githubusercontent.com/108474/61396082-e6a96c80-a894-11e9-8e68-6a70f7f35ea4.png">

In this case, the word "neighborhood" is underlined. And that underline could actually be allowed as high up as the top of the line box above or as low as the line box below, but no further. 

The idea is that....
- This would help browser engineers make sure performance wouldn't be a problem. 
- This might help Authors who accidentally wrote bad code (saying 15em, when they meant 15px), by keeping the line from being unexpectedly far away.
- This would not limit the creativity of Authors, because there's not a reasonable use case for going any further out.
- This would help accessibility by not allowing nonsense choices.

Of course, there are reasons to go for a "narrow clamp" instead — but the straw poll shows a lot of people wanting "A: no clamp", and this might be a better compromise. Allowing creativity and avoiding too narrowly defining a limit, while still also providing a way to limit performance drains or deep confusion. 

-- 
GitHub Notification of comment by jensimmons
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-512421819 using your GitHub account
Received on Wednesday, 17 July 2019 17:19:50 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:50 UTC