W3C home > Mailing lists > Public > www-style@w3.org > March 2011

[css3-text] Allow control of text-decoration width

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Fri, 25 Mar 2011 17:22:15 -0400
Message-ID: <AANLkTina4jR077FmbAwLnUv+qkX6NHZ434X9YZN6cn55@mail.gmail.com>
To: www-style@w3.org
The current CSS 3 Text draft allows control of text-decoration style
and color, but not width.  Width is still left undefined.  Authors
might want to control the width of a text-decoration directly, either
for stylistic reasons or to just achieve consistency between UAs.  (It
seems text-decorations in WebKit are always one pixel thick, for
instance, which looks a bit silly at large font sizes.)

For the third time, this feedback is really motivated by trying to
spec execCommand("underline") (although the same logic applies to
line-through and overline).  If you have some markup like

  <u>Foo <span id="x" style="font-size: 2em">bar baz quz</span></u>

and the user tries to remove the underline from "baz", one natural
result would be

  <u>Foo </u><span id="x" style="font-size: 2em"><u>bar </u>baz<u>
quz</u></span>

But the specification allows this to change the width of the underline
on "bar " and " quz", which the user didn't ask for.  If we had a
text-underline-width property or similar, we could check the computed
value of the original underline's width and the new underlines' width,
and force the new underlines to the old width if they didn't match.
We could use the new cancel-underline value instead in this case, but
that doesn't degrade gracefully: legacy UAs will just display the
de-underlined text as still underlined.  text-underline-width degrades
to just having the wrong width.

For this to be effective, though, the default value of
text-underline-width should be given explicitly, not left undefined as
now.  Is there any reason why we shouldn't have interop here?
Non-WebKit browsers seem to roughly agree on the underline thickness,
which I assume is just a multiple of the font-size or some similarly
simple thing.
Received on Friday, 25 March 2011 21:23:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT