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: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Sun, 10 Apr 2011 04:49:22 -0400
To: fantasai <fantasai.lists@inkedblade.net>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AB3D55B61@MAILR001.mail.lan>
Thank you fantasai, it's much clearer now.

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"?

If it's difficult for backward compatibility or whatever other reasons, what do you think about adding "reapply-underline" value to the 'text-decoration-line' property just like we did "cancel-*" values? I guess implementing "reapply-*" is as much possible as "cancel-*" is.

I agree with Aryeh that changing color of part of an underline is not critical, but it's still a nice feature to have.

This doesn't resolve Aryeh's request to make his editor easier to implement, but at least it becomes implementable, while still making Chinese underlines happy.


[1] http://lists.w3.org/Archives/Public/www-style/2011Apr/0254.html

-----Original Message-----
From: fantasai [mailto:fantasai.lists@inkedblade.net] 
Sent: Sunday, April 10, 2011 10:26 AM
To: Koji Ishii
Cc: www-style@w3.org
Subject: Re: [css3-text] Adjacent and nested underlines (was Allow control of text-decoration width

On 04/09/2011 11:57 AM, Koji Ishii wrote:
> Here's a simplified version of Aryeh's example:
> .u { text-decoration: underline; }
> .r { color: Red; font-size:400%; }
> <p>Nested:<span class="u">a<span class="u r">b</span>c</span></p> 
> <p>Adjacent:<span class="u">d</span><span class="u r">e</span></p>
> The position and thickness must be the same throughout "each line", so 
> the question is what the "line" is. I think the spec doesn't state 
> this clearly, but I assume, a line starts by text-decoration-line: 
> underline, overline, or line-through and ends at the end of the given 
> element. If an element is already part of a line, it will not start a new line.

"each line" is meant to refer to the line box, actually. The position and thickness must be the same for a given text decoration application /per line box/. So the position and thickness can be different if the element applying the text decoration splits across multiple lines. If multiple elements use text-decoration within the same line box, they can be different.

> If this is correct interpretation, the nested version has single line, 
> and the adjacent version has two lines. Can someone confirm this, or 
> correct me if my interpretation differs from yours?

End result of the interpretation is correct. :)

> Next about the color and style:
> ]]
> 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.
> [[
> This time, the spec says "by a given element", not "each line". I 
> understand this as color and style changes for "b" in the nested example. It also changes for "e"
> in the adjacent example as lines are split.

Yes. But note that the "b" in the nested example is underlined *twice*, once by the parent <span>, once by the child. For a solid underline, if the position of the underline does not change, the inner underline paints over the outer underline. But if the vertical-alignment of the span is changed, for example, you can see that there are two underlines applied to the "b".

> If all these interpretations are correct, I assume the expected results are:
> * The position and thickness are the same for "abc".
> * The position and thickness for "d" and "e" could be different.
> * Underlines for "b" and "e" are in red.

This is correct.

> I'd appreciate if someone can confirm/correct this. If correct, it 
> might be good to add the clarification of "what the line is" to the spec.


Received on Sunday, 10 April 2011 08:51:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC