A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/w3c/csswg-drafts/issues/8476 below:

[css-inline-3] The interaction of `text-box-edge` with `line-height` is not predictable by authors · Issue #8476 · w3c/csswg-drafts · GitHub

[This is one of a series of issues we're filing about the design feedback of leading-trim and text-box-edge. As far as we know, these properties are unimplemented in any browser, which means now is a good time to give feedback on their overall design. For each of the issues we're filing, we don't have a fully-formed proposal that would solve the problem, but we do have some avenues of potential mitigation in mind, and we're offering these ideas as a starting point for further discussion.]

There’s a threshold, where if the line-height is above that threshold, it is ignored, but if it’s below that threshold, it’s applied.

The spec says:

... giving an effective ascent above the baseline of A′ = A + L/2, and an effective descent of D′ = D + L/2. However, if text-box-edge is not leading and this is not the root inline box, if the half-leading is positive, treat it as zero.

We’re assuming this indicates that, if the half-leading is negative, text-box-edge is disregarded.

However, negative half-leading is pretty common: authors don’t go so far as to make their lines collide, but most fonts are constructed such that the ink doesn’t actually reach all the way up to the top of the ascent for most text. In places where space on the page is tight, it’s fairly common for a CSS author to tighten up the line height more than the line gap metric so the lines are more snug.

An author writing a web page doesn’t know exactly where the ascent and descent metrics of their font lie. They don’t know whether or not their half-leading is positive or not. They just tweak line-height until the lines look good. It will be frustrating to an author to adjust their content’s line height, but their adjustments stop working at some magical value, because some other property (text-box-edge) was specified somewhere else. (Recall that text-box-edge is inherited.)

One potential solution is to make one of the two always win when both are applied to the same element.

Another potential solution is described in #8478.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4