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.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
M111
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.
Contact emails
ikilp...@chromium.orgExplainer
NoneSpecification
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>InlineTAG review
Happy to file one if desired.
TAG review status
Not applicableRisks
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)?
YesIs 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-sourceFlag name
--experimental-web-platform-featuresRequires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1399711Estimated 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/5730575560736768Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpRe9mDOH4EV_-mo_-7NQL1cTZksivfs8X2oRHJ89YX82g%40mail.gmail.comThis 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.
On Mon, Jan 9, 2023 at 7:24 PM Ian Kilpatrick <ikilp...@chromium.org> wrote:Contact emails
ikilp...@chromium.orgExplainer
NoneSpecification
https://drafts.csswg.org/css-inline-3/#baseline-sourcelink 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>InlineTAG 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 applicableRisks
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=249094Can you file for https://bit.ly/blink-signals?
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?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVjgqw4cjNDEDHrsgYXafWNtUXcKuC-yNzrmbamor2xxg%40mail.gmail.com.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_ov_41p1M%3DqW965FXnURKkW8ochTM3H0aFB-5OMXy7eg%40mail.gmail.com.
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
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/727Yep, 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?
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/727Yep, 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).
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
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.
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.