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

On Thu, Apr 7, 2011 at 3:05 PM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:
> This is a very interesting point we edited the spec recently. There was a request from Chinese to split adjacent underlines visually[1]. The request was to add a new value, but instead, we chose to put following text in the spec[2]:
>
>> 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.)
>
> Your 2nd example, adjacent underlines, contradicts with this request.

Is any browser willing to implement this behavior?  I'd be surprised
if they are.  I'd expect it to add unsightly gaps to a lot of pages
that formerly rendered just fine.

> The 3rd example, nested underlines, is even more interesting. I tried to read expected behavior from the spec without much luck. I guess the underlines should split, just like adjacent underlines, but I'm not sure.

CSS specs tend not to be as precise as they should be, alas.

> CSS3 Text is still a working draft and the above paragraph was added only a few months ago, so I suspect no browsers have implemented this yet. But if they do, it breaks your use case.

I suspect they'd be unwilling.  If they are willing, I'd be interested
to hear it.

> Couldn't HTML editors merge two adjacent <u> elements when needed?

Yes, my execCommand() spec does that, but it's not always possible.
Like consider this:

    <u>Abc</u><span id=foo><u>def</u>ghi</span>

There's no way to restructure it so that there's only one <u> element,
without breaking the semantics in some other way.  Or similarly, how
about:

   <u class=foo>Abc</u><u class=bar>def</u>

You can't merge them while leaving the classes intact.  Although as I
said, I'm pretty sure this is moot, because I'd be surprised if
browsers would be willing to draw gaps at all as the spec suggests.

On Thu, Apr 7, 2011 at 3:34 PM, Ambrose LI <ambrose.li@gmail.com> wrote:
> I don’t agree with using Word as the model that we must follow. In
> terms of control of how the underline should behave it is falling very
> short of expectations of how underlines SHOULD behave in Chinese.

I don't have the expertise to comment on the Chinese use-cases.
Whatever those are, I don't think they should stand in the way of
underlines working as expected for English speakers.  If Chinese and
English speakers have different expectations, we'll need different
behavior.

> However, I do agree that we should, in most (but not all) cases,
> consider the entire run of text to determine correct underline
> positioning. However, this should not be enforced all the time, as
> there can be cases we don’t want this. This was discussed in the
> previous thread.

I can't recall what you're referring to.  Which cases are you thinking of?

>> The 3rd example, nested underlines, is even more interesting. I tried to read expected behavior from the spec without much luck. I guess the underlines should split, just like adjacent underlines, but I'm not sure.
>
> This would also be what I expect (as someone who considers U a
> semantic element instead of a visual element).

This would make it impossible to have a continuous underline in the
cases I gave earlier in this post, so I don't think it's workable.
Breaks between different underlines need to be opt-in somehow.

> <rant>
> Yes, I agree that this kind of behaviour—generation of tight HTML
> code—would solve a lot of problems.
> </rant>

My current execCommand() specification generates quite short code,
including merging and renesting elements as appropriate.  But the
problem remains.

Received on Friday, 8 April 2011 20:44:33 UTC