- From: Myles C. Maxfield via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Feb 2023 02:57:06 +0000
- To: public-css-archive@w3.org
litherum has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-inline-3] `text-edge` only has an effect by itself in corner cases == [This is one of a series of issues we're filing about the design feedback of `leading-trim` and `text-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.] When supplied alone, `text-edge` does nothing in the common case. But it can have an effect in certain situations. It is capable of producing a behavior change when supplied alone, when there’s an inline box on the line whose metrics are way larger than the root inline box’s metrics. The [spec says](http://w3c.github.io/csswg-drafts/css-inline-3/#text-edges): > The chosen metrics are used as the basis for the layout bounds of the inline box (if it is not the root inline box). The fact that the root inline box is excluded is the source of the problem. The line box stretches to include the tallest ascender and deepest descender of any line boxes on the line. In standards-mode (as opposed to quirks mode) this includes the metrics of the root inline box. So, if all the non-root inline boxes get smaller, but the root inline box stays the same, that won’t have any effect on the line! But, what happens if there’s a font fallback? Well, if the used font has smaller metrics than the primary font’s metrics, then, again, there will be no change on the line. If the used font’s metrics are slightly bigger than the primary font’s metrics, then the specified text edge of the inline box won’t exceed the leading bounds of the root inline box, and there won’t be any effect on the line either. You’ll get a behavior change if the used font’s metrics are SO much larger than the primary font’s metrics that the specified text edge of the inline box DOES exceed the leading bounds of the root inline box - at that point, the line box will grow. The fact that it does nothing in the common case means authors are more likely to sprinkle it around in places where it doesn’t belong. Authors don’t know which fallback fonts are picked by the browser, so having a behavior change occur only when the browser picks a particular fallback font seems like a footgun for portability. One potential solution is to make `text-edge` apply to the root inline box too. An alternative potential solution is to make `text-edge` always have no behavior change when applied alone, but instead have it just set some internal variable (kind of similar to how` currentColor` works) which can then be referenced by other properties like `leading-trim`. The use-case of wanting more rhythmic line positions (which is something that `text-edge` aspires to do today) could instead be worked into other properties - perhaps the properties in the rhythmic sizing spec, or maybe even the `line-height` property. These properties would be made to use this internal variable to achieve the use-case. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8475 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 20 February 2023 02:57:08 UTC