W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2016

Re: [csswg-drafts] No way to set the underline width/thickness

From: Myles C. Maxfield via GitHub <sysbot+gh@w3.org>
Date: Tue, 29 Nov 2016 00:18:15 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-263437421-1480378693-sysbot+gh@w3.org>
(Migrated from https://github.com/w3c/csswg-drafts/issues/459)

Being able to control thickness of underline is something that we have
 often seen web authors request.

Designers often want to control the thickness and position of 
underlines. Typographically, these underlines often are the thickness 
of certain particular strokes inside glyphs, which browsers / text 
libraries have no concept of. Therefore, information required for 
higher quality sizing / placement must come from somewhere else.

Naively, this additional information could come from the "post" table 
inside font files. However, because this information is often unused, 
many font files have garbage data in these fields. (As an aside, I 
[committed](https://trac.webkit.org/changeset/176263) a patch to 
WebKit to use these fields, but had to 
[revert](https://trac.webkit.org/changeset/176298) it 7 hours later 
because of the low-quality data.)

Therefore, this information should come from page authors. There 
should be a new property:
`text-decoration-thickness: auto | <number> | file`

The `auto` value is the default, and represents browsers' current 
behavior. The `file` keyword means to use the values from the primary 
font file itself (where "primary" means "the same font file which 
determines the horizontal and vertical text metrics for the element").
 If a font file format is used which does not include these values, 
then `file` behaves like `auto`.

For the "number" value, a value of '1' represents 1px at font-size: 
16px, and scales linearly with font-size.


There was some discussion in 
https://github.com/w3c/csswg-drafts/issues/459 about creating CSS 
units which refer to the stroke width(s) of a font. However, that idea
 is separate from this one because, even with CSS units, this property
 is still required so that the units can be specified. In the proposal
 above, there is no <length> value accepted, but if new units are 
created, this property can be extended to accept a new <length> value.
 For now, though, this proposal doesn't include that piece.

GitHub Notification of comment by litherum
Please view or discuss this issue at 
using your GitHub account
Received on Tuesday, 29 November 2016 00:18:21 UTC

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