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

You could do this:

  .nu { text-decoration: cancel-underline; }
  <u><span id=x><span class="nu">foo</span>bar</span>baz</u>

I was thinking, in your example, underlines for "bar" and "baz" will not match if they have different font and/or size if implementation is font/size aware, but then I figured out that fantasai's last proposal[1] would solve the case as well. That's nice, I think we should take that.

> I don't think it's compatible with the needs of Western typography.

Every font has left/right side bearings, so I think making edges slightly inwards actually works better for Western typography too, although, I agree that it makes such edge case a little more complicated.

> I'll contact some implementers to see
> what they think about this CSS 3 Text requirement,
> and CC www-style.

Thank you, that is really helpful.


Regards,
Koji

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


-----Original Message-----
From: simetrical@gmail.com [mailto:simetrical@gmail.com] On Behalf Of Aryeh Gregor
Sent: Thursday, April 14, 2011 11:35 PM
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 Tue, Apr 12, 2011 at 5:16 PM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:
> I abandon this part as I figured out that authors can write:
>  text-decoration: underline cancel-underline wavy; and this will solve 
> painting wavy lines over solid lines, so we don't have to change the spec.

That's fine by me.

> For the proposed wordings, I have a few concerns.
> * "adjacent characters" may not be accurate, as underlines may be drawn to other objects than characters. I don't think we have a good terminology for it.

Yeah, I see what you mean.

> * There are more cases than "siblings" for Chinese case; e.g., <span><u>a</u></span><u>b</u>. Current spec covers this, but the proposed text doesn't.

But in those cases, the underlines can't always be merged automatically.  If you have the markup

    <span id=x>foo<u>bar</u></span><u>baz</u>

how are you supposed to rewrite it so that the underline looks continuous?  You can't do

    <span id=x>foo</span><u><span id=x>bar</span>baz</u>

Or similarly, let's say you have

    <a href=x>foo<u>bar</u></a><u>baz</u>

with styles like (this kind of link style is common)

    :link { text-decoration: none }
    :link:hover { color: yellow }

Then if you rewrote it as

    <a href=x>foo</a><u><a href=x>bar</a>baz</u>

it would change the behavior, because if you hovered over "foo" it wouldn't change the color of "bar".

I think the only way we can feasibly satisfy the Chinese use-case is to introduce new properties or property values.  I don't think it's compatible with the needs of Western typography.  I'll contact some implementers to see what they think about this CSS 3 Text requirement, and CC www-style.

On Wed, Apr 13, 2011 at 4:37 AM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:
> A use case exists to render multiple underlines. When author specified:
>  sup { text-decoration: underline; }
>  <u>1<sup>st</sup></u>
> It is expected that "st" has two underlines at different position, so we cannot change this semantics.
>
> Her proposal at this point was that all underlines for a given baseline position must be at the same position and thickness in any given line box regardless of font size.

IE and WebKit do not currently do this (although Gecko and Opera do), and it's not supported in any word processor that I'm aware of.  I'm not sure it's actually a significant enough use-case to be worth supporting, given that it means there's a difference between

    <u>1</u><sup><u>st</u></sup>

and

    <u>1<sup>st</sup></u>

which intuitively you'd think should be the same, and which are in fact the same for nearly any other formatting command (<b>, <i>, font-variant, etc. etc.).  I still think there would be major advantages to adopting IE's behavior here.  But I can see we're unlikely to come to agreement on that, and the proposed text would be better than what we have now.

> With this, as long as vertical-alignment are the same, descendants paint over. We don't break Eric's technique[1]. For styles, authors (or WYSIWYG editors) need to specify 'cancel-underline' though.

cancel-underline wouldn't work for my WYSIWYG editor use-case.  That would get you two different underlines at different heights.  With your proposed text, there'd be no way to have <u>1</u><sup><u>st</u></sup> have one continuous underline, other than merging the <u> tags (which is not always possible, as I've said).
cancel-underline would work to get you WebKit's behavior, not IE's, and WebKit's behavior is the worst of all worlds.

Received on Thursday, 14 April 2011 15:30:16 UTC