Re: text-decoration-skip-ink auto should continue past behavior - 30+ years of underline behavior changed by latest CSS draft

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.

On Feb 21, 2018 10:55 PM, OwN-3m-All <own3mall@gmail.com> wrote:
> CSS 2.x
> Appendix E. Elaborate description of Stacking Contexts, E.2 Painting order
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_CSS21_zindex.html-23painting-2Dorder&d=DwIBaQ&c=tlFs99Fl3Rlo51LXUBQcug&r=0EiowWGy_guXKQ942nOV_0QFgUOSiAEKMBr5Y0tPiuQ&m=B0nhn48Seuf1GHWxArlZvjOKALBdlREhQJTZvHZqMXY&s=gytdYYDs2_53Hn67SvI5jXLoOhMJUmYPGDwQlNuXu0M&e=

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_CSS22_zindex.html-23painting-2Dorder&d=DwIBaQ&c=tlFs99Fl3Rlo51LXUBQcug&r=0EiowWGy_guXKQ942nOV_0QFgUOSiAEKMBr5Y0tPiuQ&m=B0nhn48Seuf1GHWxArlZvjOKALBdlREhQJTZvHZqMXY&s=OL5vxxfGrhDWlfbHlaFdrVIHBGnQYeVi7q1QgRtLzTs&e=

> states that underline text-decoration is painted first and then glyphs are
> painted. Therefore, glyphs with descenders (gjpqy) will paint over an
> underline. Since underline and glyphs often use the same color, this will
> give the visual impression that underline cut through descenders.

That sounds right!  Not rendering the underline under or above (I'm
fine with either as long as the line isn't broken apart) certain
descending characters makes no sense and is inconsistent with how
underlined text has ALWAYS worked in the NORMAL world.



________________________________

This email is intended only for the use of the party to which it is
addressed and may contain information that is privileged,
confidential, or protected by law. If you are not the intended
recipient you are hereby notified that any dissemination, copying
or distribution of this email or its contents is strictly prohibited.
If you have received this message in error, please notify us immediately
by replying to the message and deleting it from your computer.

Any tax advice in this email is for information purposes only. The content
of this email is limited to the matters specifically addressed herein
and may not contain a full description of all relevant facts or a
complete analysis of all relevant issues or authorities.

Internet communications are not assured to be secure or clear of
inaccuracies as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. Therefore,
we do not accept responsibility for any errors or omissions that are
present in this email, or any attachment, that have arisen as a result
of e-mail transmission.

Received on Thursday, 22 February 2018 16:23:37 UTC