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: Ambrose LI <ambrose.li@gmail.com>
Date: Fri, 8 Apr 2011 17:07:40 -0400
Message-ID: <BANLkTi=GCBpVdh8sLD_7+AOSbp3-K6X-LQ@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Koji Ishii <kojiishi@gluesoft.co.jp>, "www-style@w3.org" <www-style@w3.org>
2011/4/8 Aryeh Gregor <Simetrical+w3c@gmail.com>:
> 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.

That'd be, IMHO, precisely why additional attributes were proposed.


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

It was a use case that someone else was 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.

This was discussed in the previous thread I mentioned. In short,
additional attributes were proposed (not by me) but it was felt that
they are not necessary and since then dropped.

Also, if U is semantic (and I strongly believe they are), then how the
U elements are nested would determine whether underlines will be
continuous or not, and that would be the reason why I was not the
person who proposed additional attributes, because in my model of how
things should work would not require the additional attributes.

-- 
cheers,
-ambrose

my thoughts on HTML5: http://goo.gl/vhv5F + http://goo.gl/leonq
(thanks and no thanks)
Received on Friday, 8 April 2011 21:08:08 GMT

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