[css-inline-3] Naming text-box-trim et al.

Just landed the edits to split text-box-edge into two properties and add a shorthand with text-box-trim in 7869dc6 ; see

We had left open some amount of syntax bikeshedding to follow up on, so before I publish the Editor's Draft I wanted to run the current state by the CSSWG.

Here's the syntax overview:

<text-edges> = [ text | cap | ex | ideographic | ideographic-ink ]
               [ text | alphabetic | ideographic | ideographic-ink ]?
<text-trim> = start | end | both

/* line box sizing property (inherited) */
line-fit-edge: leading | <text-edges>

/* leading-trim properties (non-inherited) */
text-box: normal | <text-trim> || <text-edges>
text-box-trim: none | <text-trim>
text-box-edge: auto | <text-edges>

Shorthand details:

text-box: normal sets to initial values (none/auto).
Setting only <text-trim> defaults text-box-edge to auto (initial value).
Setting only <text-edges> defaults text-box-trim to both (not initial value).

Additional details:

text-box-edge: auto copies from line-fit-edge, treating leading as text.
Reminder: line-fit-edge values other than leading opt into the newer line box sizing model (leading only on root inline, honoring margin/border/padding on inline boxes).

Consequences:

Defaulting this way enables trimming the leading by just setting a <text-trim> value.
If the author set something more aggressive and script-specific for the inherited line-fit-edge property, that gets passed through as the default trim edges.
They can alternatively set an explicit trim value in the text-box shorthand or cascade one independently with the text-box-edge longhand.
Shorthanding magic for text-box means that:
- text-box: both sets trimming to the default edge on both sides.
- text-box: cap alphabetic sets trimming to those edges on both sides.
- text-box: normal does the normal thing of not trimming the line box. :)

We should rename the trim keywords:
Having the text-box shorthand take start | end | both reads badly, suggest renaming these keywords to trim-start | trim-end | trim-both for two reasons:

Consistency with text-spacing-trim
The shorthand reads a lot more reasonably: text-box: trim-both rather than text-box: both which is weird.

Proposed Resolutions:

Adopt text-box/text-box-trim/text-box-edge properties as outlined above.
Rename start | end | both values of text-box-trim to trim-start | trim-end | trim-both.
Name the line-box sizing property (previously discussed as text-line-edge to contrast with text-box-edge) to line-fit-edge (for now), or to some alternative that people might suggest here.
Republish css-inline-3 as WD with these edits.

Rename start | end | both values of text-box-trim to trim-start | trim-end | trim-both.

To be consistent with margin-trim, I would suggest renaming trim-both to just trim.

Setting only <text-edges> defaults text-box-trim to both (not initial value).

I have concerns about this default behavior. It's an uncommon pattern that might cause issues when defining content with mixed languages.

Consider a scenario where we want to define text-edges for headlines or sections with different writing systems, allowing for trim based on another class:

<h1 class="ideographic">こんにちは</h1>
<h1 class="alphabetic">Hello</h1>

With the proposed default trimming, we would need to explicitly set text-box-trim: none:

.ideographic {
  text-box-edge: ideographic;
  text-box-trim: none;
}

The benefit of this default seems very small especially given that trimming can be set directly with the text-box shorthand:

.shorthand {
  text-box: trim ideographic;
}

I personally would prefer a simple solution where authors wouldn't have to think about such a side effect.

If you want to set the edges in one rule and the trim with another, you would use the longhands like this:

.ideographic { text-box-edge: ideographic; }
.alphabetic { text-box-edge: cap alphabetic; }
…
h2 { text-box-trim: trim-both; }

If you use the shorthand to set the edges (or if you set both the edges and the trim using the longhands as in your example), then whether the trim takes effect will depend on the cascade order of the declarations. Note in this example, the h2 selector has less specificity—it’s important that .ideographic not set the trim at all if we want the h2 rule to take effect.

Shorthands always set all their longhands, and I figure in most cases if you’re specifying the edges you’re wanting to trim to them also, not to reset the trim to none, hence the default to trim.

To be consistent with margin-trim, I would suggest renaming trim-both to just trim.

margin-trim doesn’t have a trim value though?

To be consistent with margin-trim, I would suggest renaming trim-both to just trim.

margin-trim doesn’t have a trim value though?

Yes, margin-trim does not have a trim value but does have both a block and inline values which could work in the same way.

trim value can mean both trim-start & trim-end.

Margin trim example:
...
margin-trim: block;
margin-trim: block-start;
margin-trim: block-end;

margin-trim: inline;
margin-trim: inline-start;
margin-trim: inline-end;

https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim

The proposal looks fine to me, thank you.

I'm also fine with either trim-both or trim, mildly prefer trim.

@kojiishi

@kojiishi Should we change text-spacing to match?

The CSS Working Group just discussed [css-inline-3] Naming text-box-trim et al., and agreed to the following:

RESOLVED: name of properties are text-box-edge and text-box-trim
RESOLVED: Use trim-start and trim-end instead of start and end
RESOLVED: the value "trim-both" for property "text-box"
RESOLVED: "text-box" shorthand with value "normal" set the longhands default
RESOLVED: Republish as WD

The full IRC log of that discussion

<matthieud> fantasai: we took resolution to split text-box-edge
<matthieud> fantasai: one for line box sizing, one for triming block container
<matthieud> fantasai: we need to discuss some details about the syntax, the names of the properties, names of the values
<matthieud> fantasai: there is a new property line-fit-edge which inherits
<matthieud> fantasai: and also text-box-edge not inherited initial value auto which compute to the value of the line-fit-edge
<matthieud> fantasai: and shorthands for them together
<matthieud> fantasai: with a "normal" keyword for the shorthand which compute to "none" and "auto"
<astearns> seems OK to me, no better idea for line-fit-edge
<matthieud> florian: which part is resolved and which part is your invention ?
<matthieud> no resolved name for line-fit-edge, no resolved on the new keyword, no discussion for the shorthand text-box syntax
<matthieud> fantasai: no resolved name for line-fit-edge, no resolved on the new keyword, no discussion for the shorthand text-box syntax
<chrishtr> Koji from my team reviewed and thought it was fine, so good from Chrome's POV
<ntim> lgtm for the whole proposal
<matthieud> chrishtr: names of properties are fine
<matthieud> chrishtr: line-fit-edge details might need more discussion about behavior
<matthieud> Rossen4: we can resolve on the names ?
<ntim> I think these are already resolved on
<matthieud> RESOLVED: name of properties are text-box-edge and text-box-trim
<matthieud> fantasai: the shorthand is text-box but for the values there is a new normal keyword but the rest is weird like text-box-start ... etc
<matthieud> fantasai: maybe we should rename some values to add trim-start trim-end trim-both
<matthieud> fantasai: would be consistent with text-spacing
<matthieud> fantasai: or maybe trim instead of trim-both
<matthieud> florian: seems a bit hard to understand how they relate, so in favor of those changes
<fantasai> text-box: normal | <'text-box-trim'> || <'text-box-edge'>
<fantasai> but text-box: start (e.g.) is pretty weird, so suggest text-box: trim-start
<fantasai> Precedent: text-spacing: space-all | normal | space-first | trim-start | trim-both | trim-all
<ntim> trim is ambiguous whether it's trim-both or trim-all
<matthieud> Rossen4: what is the difference between trim-both and trim-all
<matthieud> fantasai: trim-all trim all characters, trim-both only trim only the start edge and end edge
<matthieud> florian: the important is that stuff that trim is prefixed by trim-*
<matthieud> florian: in the text-box case the difference between both and all doesnt exist so they have the same behavior
<matthieud> florian: so "trim" makes sense in the text-box case
<matthieud> fantasai: trim and trim-both makes sense, do we want to make the keyword shorter or not
<fantasai> s/makes sense/both make sense/
<fantasai> s/or not/or compatible with text-spacing/
<TabAtkins> I think the `trim-*` names sound reasonable, pesonally
<fantasai> sure, but between `trim` and `trim-both`?
<TabAtkins> Ah, trim-both, if it's less than trim-all
<fantasai> OK. But for text-box there's no trim-all in this case, just in text-spacing
<TabAtkins> Sure, but consistency is good across the props
<fantasai> RESOLVED: Use trim-start and trim-end instead of start and end
<fantasai> POLL: text-box: trim; or text-box: trim-both;
<ntim> B
<astearns> b
<kbabbitt> B
<florian> 0 (ok either way)
<TabAtkins> b
<schenney> B
<fantasai> (clear property is clear: none | left | right | both)
<Rossen4> B
<fantasai> 0
<miriam> 0
<ChrisL> abstain
<matthieud> 0
<fantasai> kojiishii: A
<ntim> We should resolve on the fact the `text-box` exists as a shorthand fwiw
<matthieud> RESOLVED: the value "trim-both" for property "text-box"
<fantasai> s/text-box/text-box-trim/
<matthieud> fantasai: the initial value of text-box-edge is auto, but text-box-trim is none. What would be the one for text-box ?
<florian> +1 to the name and to the normal keyword
<astearns> +1 to what florian +1ed
<matthieud> PROPOSED RESOLUTION: "text-box" shorthand with value "normal" set the longhands default
<ntim> +1
<fantasai> s/What would be the one for text-box ?/That leaves 'text-box: none' or 'text-box: auto' for setting the initial value, and both of these read very weirdly, so I added a normal keyword to the shorthand/
<matthieud> RESOLVED: "text-box" shorthand with value "normal" set the longhands default
<fantasai> https://drafts.csswg.org/css-inline-3/#changes
<matthieud> fantasai: I will republish the working draft
<fantasai> RESOLVED: Republish as WD
<matthieud> TabAtkins: don't have anything ready for republication

[css-inline-3] Add trim- prefix to text-box-trim keywords #10675

Bug 1913122 [wpt PR 47599] - [text-box-trim] Add `text-box` shorthand…

@yisibl

@yisibl The behavior of white-space-trim is a bit different than text-box-trim or text-spacing-trim: the discard-before and discard-after values discard space outside the box.

[text-box-trim] Rename `text-box-trim` values

[text-box-trim] Rename `text-box-edge` values

[text-box-trim] Add `text-box` shorthand

Bug 1913025 [wpt PR 47595] - [text-box-trim] Rename `text-box-trim` v…

Bug 1913041 [wpt PR 47598] - [text-box-trim] Rename `text-box-edge` v…

Bug 1913122 [wpt PR 47599] - [text-box-trim] Add `text-box` shorthand…

Bug 1913025 [wpt PR 47595] - [text-box-trim] Rename `text-box-trim` v…

Bug 1913041 [wpt PR 47598] - [text-box-trim] Rename `text-box-edge` v…

Bug 1913122 [wpt PR 47599] - [text-box-trim] Add `text-box` shorthand…

Bug 1913025 [wpt PR 47595] - [text-box-trim] Rename `text-box-trim` v…

Bug 1913041 [wpt PR 47598] - [text-box-trim] Rename `text-box-edge` v…

Bug 1913122 [wpt PR 47599] - [text-box-trim] Add `text-box` shorthand…

Navigation Menu

Repository navigation

[css-inline-3] Naming text-box-trim et al. #10675

17 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-inline-3] Naming text-box-trim et al. #10675

Description

Activity

nileshprajapati commented on Aug 2, 2024

jantimon commented on Aug 5, 2024

fantasai commented on Aug 6, 2024

fantasai commented on Aug 6, 2024

nileshprajapati commented on Aug 6, 2024

kojiishi commented on Aug 6, 2024

fantasai commented on Aug 7, 2024

css-meeting-bot commented on Aug 7, 2024

17 remaining items

fantasai commented on Aug 20, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions