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/8829 below:

[css-inline-3] It's impossible to use `text-box-trim` without changing line progression within the paragraph · Issue #8829 · w3c/csswg-drafts · GitHub

https://drafts.csswg.org/css-inline-3/#leading-trim

Name: text-box-trim Value: none | start | end | both

...
start
For block containers: trim the block-start side of the first formatted line to the corresponding text-box-edge metric of its root inline box.

The two properties text-box-trim and text-box-edge have very different purposes. One changes the spatial relationship of blocks with respect to each other, whereas the other changes the progression of lines within a block. At a fundamental level, these purposes are orthogonal. If an author just wants to change their blocks' positions, they shouldn't have to change the progression of lines within their blocks.

Philosophically, there is no reason to connect text-box-trim and text-box-edge the way they're linked in the spec now. Instead, we'd like to propose changing the grammar to be something like (cribbed from the text-box-edge property):

Name: text-box-trim Value: leading | [ text | cap | ex | ideographic | ideographic-ink ] [ text | alphabetic | ideographic | ideographic-ink ]?

This would allow text-box-trim and text-box-edge's behavior to be orthogonal to each other.


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.3