W3C home > Mailing lists > Public > www-style@w3.org > May 2013

Re: [css-text-decor-3] determining position and thickness of line decorations

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 6 May 2013 23:15:49 -0700
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
Message-ID: <20130507061549.GA12721@crum.dbaron.org>
On Monday 2013-05-06 19:12 -0700, fantasai wrote:
> On 03/24/2013 09:39 PM, L. David Baron wrote:
> >http://dev.w3.org/csswg/css-text-decor-3/#line-position specifies
> >the following for determining the thickness of decorations:
> >
> >   # CSS does not define the thickness of line decorations. In
> >   # determining the thickness of text decoration lines, user agents
> >   # may consider the font sizes, faces, and weights of descendants
> >   # to provide an appropriately averaged thickness.
> >
> >I think this "may consider" is a bad suggestion, and I would prefer
> >that CSS specify that descendants do not affect the thickness.
> >
> >I think this attempt to determine a useful underline for a single
> >element is more likely to be harmful than helpful because it will
> >lead to underlines being inconsistent between elements.  And I
> >believe consistency of underlines between different underlined
> >elements is important in many designs.  For example, if one item
> >within a list (horizontal or vertical) or links contains some
> >superscripted text, I believe authors would expect it to have the
> >same style of underline as the other links.
> >
> >I'm also hesitant to break invariants that you get basically the
> >same thing if you split a single inline into multiple inlines -- an
> >invariant that I expect editing tools assume in a number of cases.
> >
> >
> >I believe these same invariants apply to the rules for positioning,
> >where the specification is substantially more complicated.  I
> >disagree with the entire premise of the rules, which I think are, as
> >with thickness, likely to lead (in the cases where the rules matter
> >at all) to ransom-note style underlining, which I believe designers
> >dislike.
> >
> >While these rules improve certain complex cases, I belive they hurt
> >more common cases, and they also add substantial complexity to the
> >specification.
> 
> Ok, what you're asking for would be a significant change from what 2.1
> specifies, which is, I quote:
> 
>   # In determining the position of and thickness of text decoration
>   # lines, user agents may consider the font sizes of and dominant
>   # baselines of descendants, but must use the same baseline and
>   # thickness on each line.

I don't think it's that significant.  It's essentially the same "may
consider" in 2.1, and I think it's a bad idea there too.  There are
plenty of things that are permitted in 2.1 that we're defining more
precisely (and thus disallowing) in newer modules.

> It's also quite different from the examples and illustrations in
> CSS3 Text that have been there since before I inherited the spec.

Those predate the *complete rewriting* of the entire text decoration
model between 2.0 and 2.1.  I'd like css3-text to be consistent with
the 2.1 model, which we spent a good bit of energy both developing
and implementing.

> I think I'm okay with requiring a consistent thickness as determined
> by the decorating element. However, I'm not really a fan of drawing
> underlines across a subscript, and I don't think that's what designers
> want, either. I guess it would be appropriate to ignore them in the
> positioning if they are being skipped however (via 'text-decoration-skip'),
> so I'll update the spec to say that.

I still think mixing of underlining and subscript (which you point
out browsers do suboptimally now) is a less important use case than
consistency of underline between elements (which is something that
browsers do well now, and the spec proposes to make worse).

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Tuesday, 7 May 2013 06:16:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 7 May 2013 06:16:14 UTC