Intent to Prototype: CSS inline leading-trim

[Lingqi Chi]

Contact emails

lin...@chromium.org, ko...@chromium.org

Explainer

None

Specification

https://w3c.github.io/csswg-drafts/css-inline-3/#propdef-leading-trim

Summary

Specifies whether and how browsers should remove vertical spacings above and below the text content from the first and last lines of block text. This feature allows developers to have precise control over spacing, and ensures font metrics are respected during layout in terms of spacing.

Blink component

Blink>Layout>Inline

Motivation

Developers and designers sometimes find the texts are not visually aligned, as browsers would pad extra spaces to ensure line height without taking the font-reserved space into account. This feature aims to improve this.

Initial public proposal

https://github.com/w3c/csswg-drafts/issues/3240 

TAG review

N/A

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: Preview

https://webkit.org/blog/13839/release-notes-for-safari-technology-preview-163/ 

Web developers: 

  The issue was proposed in 2018[1], and got many responses. 

[1] https://github.com/w3c/csswg-drafts/issues/3240 

Other signals:

WebView application risks

No. 

Debuggability

Is this feature fully tested by web-platform-tests?

No. Will add more. 

Flag name

CSSLeadingTrimBasic

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1411581

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5174589850648576

[David Baron]

Does this also involve implementing the text-edge property (which leading-trim depends on)?

It also seems like it may be worth starting a discussion in the CSS Working Group about implementation status, given that the spec says "Do not implement (yet)".

I also think the summary of the issues WebKit implementors filed was informative.

-David

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B99URLC-V9Zrscj8F%3D%3DkGmnmp0OmNhGB11Uyy%2B-y5ZExSK5MQ%40mail.gmail.com.

[Una Kravets]

Hi all, FYI these properties were renamed to `text-box-trim` and text-box-edge` last week. (Spec may not be updated yet)

[Lingqi Chi]

Hi David, 

hanks for the comments! 

My initial plan is to implement the following items as the first step:

• Normal: When applied to an inline box, specifies that the over/under content edges coincide with the text-over/text-under baselines regardless of text-edge (which nonetheless still affects line box sizing).
  
• End, start, and both: For inline boxes:  treat all as if text-edge is "text" (it should be "trims the block-end side of the box to match its content edge to the metric specified by text-edge (treating leading as text)."

I'm not sure if I would encounter any problems after starting with this status. If anyone foresee the potential risks, I'd appreciate it! 

 > It also seems like it may be worth starting a discussion in the CSS Working Group about implementation status, given that the spec says "Do not implement (yet)".

> I also think the summary of the issues WebKit implementors filed was informative.

Thanks for sharing! After I read these issues I will start a new discussion thread.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Lingqi Chi]

(Sorry, I'm not familiar with it and click the wrong button..)

Hi David, 

Thanks for the comments! 

My initial plan is to implement the following items as the first step:

• Normal: When applied to an inline box, specifies that the over/under content edges coincide with the text-over/text-under baselines regardless of text-edge (which nonetheless still affects line box sizing).
  
• End, start, and both: For inline boxes:  treat all as if text-edge is "text" (it should be "trims the block-end side of the box to match its content edge to the metric specified by text-edge (treating leading as text)."

I'm not sure if I would encounter any problems after starting with this status. If anyone foresee the potential risks, I'd appreciate it! 

[Lingqi Chi]

Thanks Una for the information! 

It looks like the name is finalized! I will update the crbug/feature status/I2P/CLs.