W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2020

Re: [csswg-drafts] [css-inline-3] About the central baseline (#5177)

From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
Date: Tue, 16 Jun 2020 16:16:49 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-644865399-1592324207-sysbot+gh@w3.org>
On the web, I don't think we have consistent enough implementations to worry about slight pixel changes to a certain baseline alignment, so long as `central` still provides reasonably centered results.

However, since `central` was mostly recommended for ideographic alignment (e.g., as the default for vertical alignment), I'd prefer keeping it to the correct centered ideographic alignment when the font data is available, and only make changes as necessary to define a consistent fallback for when those baselines aren't specified.

(Unless there's a widespread issue with fonts that have those baselines specified, but poorly?)

I'm trying to understand the fallback issue.

The [SVG 1.1 definition](https://www.w3.org/TR/SVG11/text.html#BaselineAlignmentProperties) was:

> This identifies a computed baseline that is at the center of the EM box. This baseline lies halfway between the text-before-edge and text-after-edge baselines.

If I understand the linked issue, the problem is that the “em box” itself isn't defined, except as the pair of ascent/descent metrics relative to the coordinate system origin, and different rendering engines use different font metrics to compute ascent/descent, and in broken fonts the various ascent/descent metrics aren't always consistent?

But the broken examples have basic alignment broken, too, so what are we really trying to optimize for by defining a consistent `central` alignment if everything else about the alignment is broken?

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5177#issuecomment-644865399 using your GitHub account
Received on Tuesday, 16 June 2020 16:16:52 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:28 UTC