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

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.

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.

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.

Does this sound reasonable?


Regards,
Koji

[1] http://dev.w3.org/csswg/css3-text/#line-decoration

[2] http://dev.w3.org/csswg/css3-text/#text-decoration-line


-----Original Message-----
From: simetrical@gmail.com [mailto:simetrical@gmail.com] On Behalf Of Aryeh Gregor
Sent: Monday, April 11, 2011 5:55 AM
To: Koji Ishii
Cc: fantasai; www-style@w3.org
Subject: Re: [css3-text] Adjacent and nested underlines (was Allow control of text-decoration width

On Sun, Apr 10, 2011 at 4:49 AM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:
> I'm worried Eric's hack[1] might stop working as browsers implement smarter thickness/position, because it becomes more likely that multiple underlines are not painted over for different font/size. Is drawing multiple underlines to the same text important? If not, could we change the semantics of such case to "keep the same position and thickness, but re-apply color and style"?

The use-case I can think of offhand is if you want to underline a superscript or subscript for some reason, like

    1<sup><u>o</u></sup>

(which is maybe used in French or something?).  Then if the text happens to be underlined for some other reason, like

    <u>1<sup><u>o</u></sup></u>

I guess you do actually want both underlines to be drawn in this case, because they're logically separate.  This is what the current spec requires, and it's what Gecko and Opera do.

IE9 draws a single underline to be drawn under both of them, contrary to the current spec.  I guess you could argue that it's just deciding for some reason to place the superscript's underline at the same place as the outer underline, but it's a stretch.  It does make some sense, despite being against the spec.

WebKit here draws one underline under the "o", at the correct height for the superscript, without extending the underline from under the "1" at all, which seems undesirable across the board as well as being against the spec.


For my use-case I'd only really care that

    <u>1</u><sup><u>o</u></sup>

renders the same as

    <u>1<sup>o</sup></u>

which it doesn't per spec and Gecko/Opera, but does per IE/WebKit.  If they can render differently, then there's no reasonable way to un-underline safely except by sticking in <span
style="text-decoration: cancel-underline">, which is not only long and ugly but has bad back-compat and doesn't work with non-CSS UAs at all.

I'm not sure whether my use-case is enough to trump the extra flexibility that the current spec allows, with the possibility of multiple underlines under a single character.  Half the major rendering engines don't allow that anyway -- has there been any pressure on them to change?  I really think IE's approach is simplest to understand and looks nicest.

Received on Tuesday, 12 April 2011 07:55:06 UTC