[csswg-drafts] [css-text-decor] text-decoration-thickness & text-underline-position properties

litherum has just created a new issue for 

== [css-text-decor] text-decoration-thickness & 
text-underline-position properties ==
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 | <length> | 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`.

In addition, two new values should be added to 
`text-decoration-thickness`, thereby making the syntax:
`text-decoration-position: auto | [ under || [ left | right ] ] | 
<length> | file`

With this syntax, it is impossible to specify both a `<length>` as 
well as `under`, which is on purpose. The `<length>` only applies to 
regular underlines, not to overlines, under-underlines, nor 

In addition, because of the semantic meaning of text decorations, 
browsers should be able to clamp these values to 
implementation-dependent sane ranges.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/459 using your GitHub 

Received on Saturday, 10 September 2016 19:44:40 UTC