- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 28 Feb 2018 11:06:07 +0700
- To: www-style@w3.org
On 02/22/2018 08:48 PM, Plumb-Larrick, C. Andrew wrote: > Okay. You don't like it. So set the property the way you want it on your sites or in a user stylesheet. In all your posts I > haven't really seen an argument on the merits about this -- just about your preference (hey, that's what css directives are > for!) And a sort of out-of-context caricature of the argument for bias against changing defaults. > > My impression is that underlining is relatively rare in professional typography outside of the Web, where best-practices > generally confine its usage to hyperlinks. (Otherwise, it is usually a substitute for italic, originally driven by the > limitations of typewriters.) So I haven't been informed by the research into existing typographic practices that the committee > has done, and that inform their draft. But I have no reason to doubt it. (I think *if* you have the germ of a good argument it > would have something to do with this special case of link-marking calling for different behavior than normal typographic best > practices.) > > Because of this relatively limited use case for underline, I'm also relatively unconcerned about the outcome. On this side, > noting only the need for an eye toward the concern (stated by others, not you) about some 'non-ink' underlines looking like > two links. I think this is mostly unlikely to present an issue (such breaks will usually be within one word, and there are > generally other link cues like hover colors, etc). But it IS a very useful point and highlights something for designers to > attend to in the real world. > > In light of what has been stated to be the research from underline usage in typography, I have no reason to doubt that the > proposed default for this property is the correct choice on balance -- particularly in light of the vast overall improvement > in browser typography support that we've seen. I think a related problem is also quality-of-implementation. If the browser skips too far on either side of the descender, the resulting underline looks disjointed and is harder to distinguish as an underline; the position of the underline affects how badly the line is disrupted. Etc. There's a parallel thread about this on the blink-dev mailing list right now. The CSS specs currently leave these decisions up to the UA: it's allowed to skip, but not required, and the details of the behavior are unspecified: https://drafts.csswg.org/css-text-decor-3/#line-decoration ~fantasai
Received on Wednesday, 28 February 2018 06:49:42 UTC