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

Re: [css3-text] Adjacent and nested underlines (was Allow control of text-decoration width

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Tue, 12 Apr 2011 13:43:45 -0400
Message-ID: <BANLkTinfmN4vBA8R-Wghz3SPtMMgEarobQ@mail.gmail.com>
To: Koji Ishii <kojiishi@gluesoft.co.jp>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Tue, Apr 12, 2011 at 3:52 AM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:
> With the help from fantasai, I have fixed a few words in "Line Decoration: Underline, Overline, and Strike-Through"[1] for clarifications, but not for nested case yet.
>
> I would like to propose to add one more sentence saying:
>
> | If the given element is part of a line applied to its ascendant elements,
> | the position and thickness must be the same as the position and thickness
> | of its ascendant elements.

I think you mean "ancestor", not "ascendant".  I don't know if this is
desired, though.  What about something like:

    <u><small>Foo</small><br><big>Bar</big></u>

Do we want to require that the underlines be the same thickness?  I
would say that instead of

"""
The UA should place the start and end of the line inwards from the
content edge of the decorating element so that, e.g. two underlined
elements side-by-side do not appear to have a single underline. (This
is important in Chinese, where underlining is a form of punctuation.)

In determining the position and thickness of text decoration lines,
user agents may consider the font sizes and dominant baselines of
descendants, but for a given element's decoration must use the same
position and thickness throughout each line box. The color and line
style of decorations must remain the same on all decorations applied
by a given element, even if descendant elements have different color
or line style values.
"""

we should say something like

"""
In determining the position and thickness of text decoration lines,
user agents should consider the font sizes and dominant baselines of
descendants, not just the element generating the line.  Any time two
adjacent characters in the same line box are affected by a text
decoration line (even of different color or style), the line must have
the same position and thickness for both, with no gap, even if the
lines were created by different elements.

As an exception, if an element and its previous sibling both create
separate underlines, the UA should leave a gap in between them, so
that the elements do not appear to have the same underline.  (This is
important in Chinese, where underlining is a form of punctuation.)

The color and line style of decorations must remain the same on all
decorations applied by a given element, even if descendant elements
have different color or line style values.
"""

> And also to 'underline', 'overline', and 'line-through' of the 'text-decoration-line' property[2],
>
> | Propagated *lines are inhibited.
>
> I originally thought the latter is not necessary, as the new line will paint over the propagated lines, but then I figured that we probably need this too for style changes (dotted, wavy, etc.)
>
> I'm not clear how bad this is from backward compatibility view point, or any other cons of this proposal. Opinions appreciated.

I'm not sure whether the compatibility break would be acceptable in
practice here.  I'd guess that browser implementers wouldn't be happy
to do it without very good reason.

> For the adjacent case you raised, I don't think it's a good idea to change the spec for reasons below:
> * The two lines are logically separated.
> * There's a contradicting request for Chinese proper nouns.
> * I can't find any workaround other than adding a new property for Chinese proper nouns, but in your case, HTML editors can be smarter to detect the case and rearrange the elements.
>
> If this proposal works for everyone, it will fix nested case for you, keeps Eric's technique working, supports Chinese proper nouns, but not for your adjacent scenario.

It would be okay with me, but I suspect implementers won't want to do
it, because I bet it would make a lot of pages out there look worse.
It would be a good idea to ask some of the major browser implementers
if they're interested in making this change.  If they aren't, then we
need a new property.
Received on Tuesday, 12 April 2011 17:44:33 GMT

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