- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Tue, 12 Apr 2011 13:43:45 -0400
- To: Koji Ishii <kojiishi@gluesoft.co.jp>
- Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Tue, Apr 12, 2011 at 3:52 AM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote: > 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. I think you mean "ancestor", not "ascendant". I don't know if this is desired, though. What about something like: <u><small>Foo</small><br><big>Bar</big></u> Do we want to require that the underlines be the same thickness? I would say that instead of """ 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.) In determining the position and thickness of text decoration lines, user agents may consider the font sizes and dominant baselines of descendants, but for a given element's decoration must use the same position and thickness throughout each line box. 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. """ we should say something like """ In determining the position and thickness of text decoration lines, user agents should consider the font sizes and dominant baselines of descendants, not just the element generating the line. Any time two adjacent characters in the same line box are affected by a text decoration line (even of different color or style), the line must have the same position and thickness for both, with no gap, even if the lines were created by different elements. As an exception, if an element and its previous sibling both create separate underlines, the UA should leave a gap in between them, so that the elements do not appear to have the same underline. (This is important in Chinese, where underlining is a form of punctuation.) 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. """ > 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. I'm not sure whether the compatibility break would be acceptable in practice here. I'd guess that browser implementers wouldn't be happy to do it without very good reason. > 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. It would be okay with me, but I suspect implementers won't want to do it, because I bet it would make a lot of pages out there look worse. It would be a good idea to ask some of the major browser implementers if they're interested in making this change. If they aren't, then we need a new property.
Received on Tuesday, 12 April 2011 17:44:33 UTC