Intent to Ship: baseline-source

227 views
Skip to first unread message

Ian Kilpatrick

unread,
Jan 9, 2023, 1:24:47 PM1/9/23
to blink-dev

Contact emails

ikilp...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-inline-3/#baseline-source

Summary

The "baseline-source" properties allows web developers to specify if an inline-level box should use the "first" or "last" baseline for alignment within an linebox. Today the default behaviour is confusing for web developers. Consider: test <div style="display: inline-block;">line1<br>line2</div> test <div style="display: inline-flex;">line1<br>line2</div> The "inline-block" will align to the last baseline, and the "inline-flex" will align to the first baseline. "baseline-source: auto" is the existing (confusing) behaviour. Web developers can specify "baseline-source: first" or "baseline-source: last" to directly determine how they want these boxes to align within a line-box.



Blink component

Blink>Layout>Inline

TAG review

Happy to file one if desired.

TAG review status

Not applicable

Risks



Interoperability and Compatibility



Gecko: No signal https://bugzilla.mozilla.org/show_bug.cgi?id=1805273

WebKit: No signal https://bugs.webkit.org/show_bug.cgi?id=249094

Web developers: Positive from my discussions. This has been a consistent source of frustration with developers trying to align content within a line-box.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Debuggability

Standard devtools CSS debugging.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

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

Yes https://wpt.fyi/results/css/css-inline/baseline-source?label=master&label=experimental&aligned&view=subtest&q=baseline-source

Flag name

--experimental-web-platform-features

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

M111



Anticipated spec changes

https://github.com/w3c/csswg-drafts/issues/8214 still needs to be resolved. We've implemented what we believe the "good" behaviour is. The CSSWG is a little backed up with issues at the moment, and may take a while to address. Trivial to switch behaviour.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5730575560736768

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpRe9mDOH4EV_-mo_-7NQL1cTZksivfs8X2oRHJ89YX82g%40mail.gmail.com


This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Jan 10, 2023, 7:48:23 AM1/10/23
to Ian Kilpatrick, blink-dev
On Mon, Jan 9, 2023 at 7:24 PM Ian Kilpatrick <ikilp...@chromium.org> wrote:

link seems down :/ 


Summary

The "baseline-source" properties allows web developers to specify if an inline-level box should use the "first" or "last" baseline for alignment within an linebox. Today the default behaviour is confusing for web developers. Consider: test <div style="display: inline-block;">line1<br>line2</div> test <div style="display: inline-flex;">line1<br>line2</div> The "inline-block" will align to the last baseline, and the "inline-flex" will align to the first baseline. "baseline-source: auto" is the existing (confusing) behaviour. Web developers can specify "baseline-source: first" or "baseline-source: last" to directly determine how they want these boxes to align within a line-box.



Blink component

Blink>Layout>Inline

TAG review

Happy to file one if desired.
Will we be the first to ship this? If so, I believe one is required. 

TAG review status

Not applicable

Risks



Interoperability and Compatibility



Gecko: No signal https://bugzilla.mozilla.org/show_bug.cgi?id=1805273

WebKit: No signal https://bugs.webkit.org/show_bug.cgi?id=249094

 


Web developers: Positive from my discussions. This has been a consistent source of frustration with developers trying to align content within a line-box.
Any links? 

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Debuggability

Standard devtools CSS debugging.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

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

Yes https://wpt.fyi/results/css/css-inline/baseline-source?label=master&label=experimental&aligned&view=subtest&q=baseline-source

Flag name

--experimental-web-platform-features

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

M111



Anticipated spec changes

https://github.com/w3c/csswg-drafts/issues/8214 still needs to be resolved. We've implemented what we believe the "good" behaviour is. The CSSWG is a little backed up with issues at the moment, and may take a while to address. Trivial to switch behaviour.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5730575560736768

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpRe9mDOH4EV_-mo_-7NQL1cTZksivfs8X2oRHJ89YX82g%40mail.gmail.com


This intent message was generated by Chrome Platform Status.

--
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/CAJL3UpSXHyzpVHet2rBKdK31n8s-f4zq9QrhWWVNHZ6oSbTuFQ%40mail.gmail.com.

Ian Kilpatrick

unread,
Jan 10, 2023, 7:19:50 PM1/10/23
to Yoav Weiss, blink-dev
On Tue, Jan 10, 2023 at 4:48 AM Yoav Weiss <yoav...@chromium.org> wrote:


On Mon, Jan 9, 2023 at 7:24 PM Ian Kilpatrick <ikilp...@chromium.org> wrote:

link seems down :/ 

 Yeah the csswg server is a little sporadic at the moment. Up at the moment. 


Summary

The "baseline-source" properties allows web developers to specify if an inline-level box should use the "first" or "last" baseline for alignment within an linebox. Today the default behaviour is confusing for web developers. Consider: test <div style="display: inline-block;">line1<br>line2</div> test <div style="display: inline-flex;">line1<br>line2</div> The "inline-block" will align to the last baseline, and the "inline-flex" will align to the first baseline. "baseline-source: auto" is the existing (confusing) behaviour. Web developers can specify "baseline-source: first" or "baseline-source: last" to directly determine how they want these boxes to align within a line-box.



Blink component

Blink>Layout>Inline

TAG review

Happy to file one if desired.
Will we be the first to ship this? If so, I believe one is required. 

Done - It's a very small improvement to an existing API set so unclear but filed one anyway.


TAG review status

Not applicable

Risks



Interoperability and Compatibility



Gecko: No signal https://bugzilla.mozilla.org/show_bug.cgi?id=1805273

WebKit: No signal https://bugs.webkit.org/show_bug.cgi?id=249094

 



Web developers: Positive from my discussions. This has been a consistent source of frustration with developers trying to align content within a line-box.
Any links? 

This is primarily discussions I've had with developers with frustration with the current behaviour. No public links unfortunately.

一丝

unread,
Jan 10, 2023, 11:13:35 PM1/10/23
to Ian Kilpatrick, Yoav Weiss, blink-dev

Ian Kilpatrick <ikilp...@chromium.org> 于2023年1月11日周三 08:19写道：
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpQiiLzkbyySG3KBGqP4L6qPto-pV3E%3D_bo9n7-bt2HQug%40mail.gmail.com.

Rick Byers

unread,
Jan 11, 2023, 10:28:09 AM1/11/23
to 一丝, Ian Kilpatrick, Yoav Weiss, blink-dev
Given the lack of signals from other implementers, any other indication on the maturity of the spec? I searched for open bugs and found only this one which sounds fairly minor to me - likely resolvable without major compat implications.

Regardless, I agree this is quite minor, seems reasonable to ship absent any known objections or significant outstanding issues.

Thanks,
   Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-d5ZoTwmT2xSuqAevHCp4T9ja6wjX8L6Vf8GkgcKtFF21NCQ%40mail.gmail.com.

Ian Kilpatrick

unread,
Jan 11, 2023, 11:14:59 AM1/11/23
to Rick Byers, 一丝, Yoav Weiss, blink-dev
On Wed, Jan 11, 2023 at 7:28 AM Rick Byers <rby...@chromium.org> wrote:
Given the lack of signals from other implementers, any other indication on the maturity of the spec? I searched for open bugs and found only this one which sounds fairly minor to me - likely resolvable without major compat implications.

We got a positive signal from the Firefox folks here: https://github.com/mozilla/standards-positions/issues/727
 

Regardless, I agree this is quite minor, seems reasonable to ship absent any known objections or significant outstanding issues.

Yeah this is a very minor feature all things considered.
 

slightlyoff via Chromestatus

unread,
Jan 11, 2023, 11:56:23 AM1/11/23
to blin...@chromium.org
LGTM1

Rick Byers

unread,
Jan 11, 2023, 11:58:15 AM1/11/23
to Ian Kilpatrick, 一丝, Yoav Weiss, blink-dev
On Wed, Jan 11, 2023 at 11:14 AM Ian Kilpatrick <ikilp...@google.com> wrote:

On Wed, Jan 11, 2023 at 7:28 AM Rick Byers <rby...@chromium.org> wrote:
Given the lack of signals from other implementers, any other indication on the maturity of the spec? I searched for open bugs and found only this one which sounds fairly minor to me - likely resolvable without major compat implications.

We got a positive signal from the Firefox folks here: https://github.com/mozilla/standards-positions/issues/727

Yep, that's great. But what I was asking was that you're not aware of any outstanding design debates or bugs which might cause future compat issues, right? 

Ian Kilpatrick

unread,
Jan 11, 2023, 12:13:41 PM1/11/23
to Rick Byers, 一丝, Yoav Weiss, blink-dev
On Wed, Jan 11, 2023 at 8:58 AM Rick Byers <rby...@chromium.org> wrote:
On Wed, Jan 11, 2023 at 11:14 AM Ian Kilpatrick <ikilp...@google.com> wrote:

On Wed, Jan 11, 2023 at 7:28 AM Rick Byers <rby...@chromium.org> wrote:
Given the lack of signals from other implementers, any other indication on the maturity of the spec? I searched for open bugs and found only this one which sounds fairly minor to me - likely resolvable without major compat implications.

We got a positive signal from the Firefox folks here: https://github.com/mozilla/standards-positions/issues/727

Yep, that's great. But what I was asking was that you're not aware of any outstanding design debates or bugs which might cause future compat issues, right? 

Oh sorry - missed that part of your question. No not particularly - the open issue which we raised (https://github.com/w3c/csswg-drafts/issues/8214) is surrounding a clarification to the spec for a somewhat edge case. We've implemented what we think is the best behaviour but wanted to double check with the broader group. We'll be able to change this specific behaviour safely after we ship if needed as it is a relative edge case.

(The case in question is that the "inline-block" baseline algorithm contains a lot of quirks and counter intuitive behaviour, e.g. tables get skipped in some cases, and for things with "overflow: hidden" the baseline is ignored, the behavour we've implemented uses the baseline behaviour from flex/grid - see https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11177 for an explicit example).

Rick Byers

unread,
Jan 11, 2023, 12:20:35 PM1/11/23
to Ian Kilpatrick, 一丝, Yoav Weiss, blink-dev
On Wed, Jan 11, 2023 at 12:13 PM Ian Kilpatrick <ikilp...@google.com> wrote:


On Wed, Jan 11, 2023 at 8:58 AM Rick Byers <rby...@chromium.org> wrote:
On Wed, Jan 11, 2023 at 11:14 AM Ian Kilpatrick <ikilp...@google.com> wrote:

On Wed, Jan 11, 2023 at 7:28 AM Rick Byers <rby...@chromium.org> wrote:
Given the lack of signals from other implementers, any other indication on the maturity of the spec? I searched for open bugs and found only this one which sounds fairly minor to me - likely resolvable without major compat implications.

We got a positive signal from the Firefox folks here: https://github.com/mozilla/standards-positions/issues/727

Yep, that's great. But what I was asking was that you're not aware of any outstanding design debates or bugs which might cause future compat issues, right? 

Oh sorry - missed that part of your question. No not particularly - the open issue which we raised (https://github.com/w3c/csswg-drafts/issues/8214) is surrounding a clarification to the spec for a somewhat edge case. We've implemented what we think is the best behaviour but wanted to double check with the broader group. We'll be able to change this specific behaviour safely after we ship if needed as it is a relative edge case.

(The case in question is that the "inline-block" baseline algorithm contains a lot of quirks and counter intuitive behaviour, e.g. tables get skipped in some cases, and for things with "overflow: hidden" the baseline is ignored, the behavour we've implemented uses the baseline behaviour from flex/grid - see https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11177 for an explicit example).

Makes sense, thanks, LGTM2. 

fantasai

unread,
Jan 12, 2023, 4:24:08 PM1/12/23
to Ian Kilpatrick, blink-dev, Rick Byers
On 1/9/23 13:24, Ian Kilpatrick wrote:

Contact emails

ikilp...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-inline-3/#baseline-source

Summary

The "baseline-source" properties allows web developers to specify if an inline-level box should use the "first" or "last" baseline for alignment within an linebox.

...


This property is a longhand of `vertical-align`, alongside `baseline-shift` and `alignment-baseline`. Are you planning to ship this set together? (It's probably fine to drop newer values from the other longhands, but their relationships should be implemented correctly, imho.)

~fantasai


Ian Kilpatrick

unread,
Jan 12, 2023, 4:28:34 PM1/12/23
to fantasai, blink-dev, Rick Byers
No just the baseline-source longhand for the moment - there is additional complexity/risks with the vertical-align mapping that we'd like to analyze separately.

Ian

Ian Kilpatrick

unread,
Jan 12, 2023, 5:21:38 PM1/12/23
to fantasai, blink-dev, Rick Byers
Some additional context for folks:

 - `vertical-align` currently (in all browsers) doesn't map to any other properties, it supports a bunch of keywords, *or* a <length> for adjusting position within a line-box as well as some historical alignment within a table-cell.

 - The css-inline-3 spec addresses some additional use-cases via. mapping `vertical-align` onto three properties (`baseline-shift`, `alignment-baseline`, and `baseline-source`). Specifically this creates some additional capability being able to specify `vertical-align: text-top 10px` for example which isn't supported at the moment. There is a (very) small compat risk here.

 - Two of these properties already exist today (and this intent would ship the third). The first part of the complexity here is that `baseline-shift`, `alignment-baseline` *only* work on SVG elements today, and `vertical-align` doesn't. A (very) small compat risk exists that `vertical-align` would start working for some SVG elements, and the `baseline-shift`, `alignment-baseline` properties would start working on other elements as well (2nd part of compat risk here).

 - To support this there is a lot of subtle work involved in supporting these properties within the inline code, (and arguably table code), it isn't a "simple" mapping `vertical-align` onto these new properties. Lots of work needs to be done, lots of tests, etc, we'd like to do this as a separate phase/project. 

 - Shipping the `baseline-source` property separately (this intent) doesn't increase/decrease forwards compat risk in a material way - specifying it would "win" over anything specified in `vertical-align` once we support that mapping, and addresses a large web developer concern.

Ian

fantasai

unread,
Jan 12, 2023, 9:20:59 PM1/12/23
to Ian Kilpatrick, blink-dev, Rick Byers
On 1/12/23 17:21, Ian Kilpatrick wrote:
> Some additional context for folks:
>
>  - Shipping the `baseline-source` property separately (this intent) doesn't
> increase/decrease forwards compat risk in a material way - specifying it would
> "win" over anything specified in `vertical-align` once we support that
> mapping, and addresses a large web developer concern.

This is incorrect. In an implementation that implements the shorthanding
relationship vs an implementation that doesn't, the following two declarations
will have different effects:

.x {
baseline-source: first;
vertical-align: 10px; /* resets baseline-source to auto, or not */
}

~fantasai

Ian Kilpatrick

unread,
Jan 12, 2023, 10:56:13 PM1/12/23
to fantasai, blink-dev, Rick Byers
Ah true! I didn't consider the <length> values here.

To mitigate this forward compat concern we can apply a partial mapping, e.g. if the current `vertical-align` property is set, it'll set the `baseline-source` to `auto`.

This should mitigate any forward compat concern here. I'll send a patch to do this tomorrow. This will allow us to perform the larger (complex, and risky) vertical-align changes in one shot later.

Ian

fantasai

unread,
Jan 17, 2023, 6:48:34 PM1/17/23
to Ian Kilpatrick, blink-dev, Rick Byers
On 1/12/23 22:55, Ian Kilpatrick wrote:
> Ah true! I didn't consider the <length> values here.
>
> To mitigate this forward compat concern we can apply a partial mapping, e.g.
> if the current `vertical-align` property is set, it'll set the
> `baseline-source` to `auto`.

I think that helps, yeah.

> This should mitigate any forward compat concern here. I'll send a patch to do
> this tomorrow. This will allow us to perform the larger (complex, and risky)
> vertical-align changes in one shot later

One concern I'd have here is that *if* we cannot ship the currently-specced
shorthanding relationship among these properties, we might have to change that
relationship, which could change how vertical-align and baseline-source
interact as well.

So it would be good to know if we can actually ship the
vertical-align -> alignment-baseline + baseline-shift ( + baseline-source)
mapping or not, even if the additional values are not yet supported.

~fantasai

Ian Kilpatrick

unread,
Jan 18, 2023, 12:38:03 PM1/18/23
to fantasai, blink-dev, Rick Byers
On Tue, Jan 17, 2023 at 3:48 PM fantasai <fantasa...@inkedblade.net> wrote:
On 1/12/23 22:55, Ian Kilpatrick wrote:
> Ah true! I didn't consider the <length> values here.
>
> To mitigate this forward compat concern we can apply a partial mapping, e.g.
> if the current `vertical-align` property is set, it'll set the
> `baseline-source` to `auto`.

I think that helps, yeah.

> This should mitigate any forward compat concern here. I'll send a patch to do
> this tomorrow. This will allow us to perform the larger (complex, and risky)
> vertical-align changes in one shot later

One concern I'd have here is that *if* we cannot ship the currently-specced
shorthanding relationship among these properties, we might have to change that
relationship, which could change how vertical-align and baseline-source
interact as well.

I'm not concerned about this compared to the other compat risks with the expanded vertical-align mapping (for other folks listed above).
This only becomes an issue if we are unable to ship the vertical-align mapping at a later date, and we decide that baseline-source shouldn't be attached to vertical-align at all.


So it would be good to know if we can actually ship the
   vertical-align -> alignment-baseline + baseline-shift ( + baseline-source)
mapping or not, even if the additional values are not yet supported.

I would actually be worried more about as a forward compat risk supporting additional values later vs. the risk removing the mitigation above for example.

TAMURA, Kent

unread,
Jan 18, 2023, 7:04:17 PM1/18/23
to Ian Kilpatrick, 一丝, Yoav Weiss, blink-dev, Rick Byers
LGTM3.

I don't think the issue of vertical-align shorthand isn't a blocker.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8oW-sn6LJ16MOR4JW3%3Dgnf2DKQ68KVrEJPDbCh_MGjNA%40mail.gmail.com.


--
TAMURA Kent
Software Engineer, Google


Reply all
Reply to author
Forward
0 new messages