[csswg-drafts] Issue: [css-text-decor] text-decoration-thickness & text-underline-position properties marked as i18n-tracking

r12a has just labeled an issue for https://github.com/w3c/csswg-drafts
 as "i18n-tracking":

== [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-underline-position`, thereby making the syntax:
`text-underline-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 
strikethroughs.

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


See https://github.com/w3c/csswg-drafts/issues/459

Received on Thursday, 17 November 2016 11:43:36 UTC