Intent to ship: Gutters in flexbox: row-gap and column-gap properties

341 views
Skip to first unread message

David Grogan

unread,
May 6, 2020, 4:03:30 PM5/6/20
to blink-dev

Contact emails

dgr...@chromium.org


Explainer

https://developer.mozilla.org/en-US/docs/Web/CSS/column-gap#Flex_layout


Spec

https://www.w3.org/TR/css-align-3/#column-row-gap


TAG review
None. This was discussed in CSSWG in 2017, has been in the spec since, and has shipped in Firefox.


Summary

This css property allows you to specify spacing between flex items and/or flex lines.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/VU1zkDOL3bc/AU9FjKl2DQAJ


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

Yes


Demo link

argyle@ has a WIP devrel blog post but it is not yet published.


Debuggability

Just the generic layout panel in devtools. There's a bug to implement auto-completion of the css property.


Risks

Interoperability and Compatibility

Compat:
This is practically* the same behavior of Firefox so should not have compat problems. Also, probably not many sites use this property because it's only worked in Firefox.
Interop:
The main interop risk is that WebKit doesn't implement.

* There's an edge case we don't yet implement that Firefox does. https://github.com/w3c/csswg-drafts/issues/4664

Edge: No public signals
Web developers: Positive (https://crbug.com/762679) 400+ stars

Ergonomics

This feature should be familiar to developers because it already works in multi-col and grid layouts.


Activation

Simple: use any of the three CSS gap properties on flexboxes.


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. https://wpt.fyi/results/css?label=master&label=experimental&aligned&q=flex%20gap


Entry on the feature dashboard

https://www.chromestatus.com/feature/6031643502444544


Manuel Rego Casasnovas

unread,
May 6, 2020, 5:12:26 PM5/6/20
to David Grogan, blink-dev

On 06/05/2020 22:03, 'David Grogan' via blink-dev wrote:
> Interoperability and Compatibility
>
> Compat:
> This is practically* the same behavior of Firefox so should not have
> compat problems. Also, probably not many sites use this property because
> it's only worked in Firefox.
> Interop:
> The main interop risk is that WebKit doesn't implement.
>
> * There's an edge case we don't yet implement that Firefox
> does. https://github.com/w3c/csswg-drafts/issues/4664

What's the rationale to ship this with a known bug?

This has been shipped in Firefox with this behavior since Firefox
started supporting gaps in Flexbox, and in Grid Layout in Chromium since
mid-2018. So I believe developers are going to get confused due to the
different behavior in flex vs grid.

Why we don't implement the behavior from the spec for rows too?
Not doing it now and implementing it in the future would imply that some
sites might have issues.
Grid was not very widely used when we applied the spec change for this
in 2018 and some sites got affected by the change [1], I guess the same
will happen if we do this later.
Also Firefox hasn't implemented this for grid rows yet (they implement
it only for gaps), and we are getting some interop bugs every now and
then due to that.

Bye,
Rego

[1]
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/_TBhjGLfAwAJ

David Grogan

unread,
May 6, 2020, 6:04:15 PM5/6/20
to Manuel Rego Casasnovas, blink-dev
On Wed, May 6, 2020 at 2:12 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 06/05/2020 22:03, 'David Grogan' via blink-dev wrote:
> Interoperability and Compatibility
>
> Compat:
> This is practically* the same behavior of Firefox so should not have
> compat problems. Also, probably not many sites use this property because
> it's only worked in Firefox.
> Interop:
> The main interop risk is that WebKit doesn't implement.
>
> * There's an edge case we don't yet implement that Firefox
> does. https://github.com/w3c/csswg-drafts/issues/4664

What's the rationale to ship this with a known bug?

Because perfect is the enemy of the good. And it's a weird case. There have been 3 spec issues about it, including the analogous grid behavior (https://github.com/w3c/csswg-drafts/issues/345 https://github.com/w3c/csswg-drafts/issues/472 https://github.com/w3c/csswg-drafts/issues/4664). If it were a straightforward case, there would have been less discussion. Weird cases seem less important to support than the main functionality.

This has been shipped in Firefox with this behavior since Firefox
started supporting gaps in Flexbox, and in Grid Layout in Chromium since
mid-2018. So I believe developers are going to get confused due to the
different behavior in flex vs grid.
Why we don't implement the behavior from the spec for rows too?
Not doing it now and implementing it in the future would imply that some
sites might have issues.
Grid was not very widely used when we applied the spec change for this
in 2018 and some sites got affected by the change [1], I guess the same
will happen if we do this later.

I share this concern, but I think it is less likely to happen with flex. For grid, Firefox made the same switch, right? (I'm not positive) So developers relied on this feature because it had interop, then both engines changed behavior, and live sites broke. For flex, there will not be interop for this edge case so developers will be less likely to use it in live sites.

Also Firefox hasn't implemented this for grid rows yet (they implement
it only for gaps), and we are getting some interop bugs every now and
then due to that.

Yeah, we'll get an interop bug every now and then due to this edge case. But that seems like a worthwhile tradeoff to ship the feature earlier when it is so in demand (twitter lit up in response to the _code commit_, let alone devrel's later tweets).

Further, note that shipping this feature as is, without supporting this edge case, is a net big win for interop. Right now, we support neither the main functionality nor the edge case. Firefox supports both.

To be clear, thanks for bringing up this point, it deserves discussion.

Yoav Weiss

unread,
May 7, 2020, 1:46:27 AM5/7/20
to David Grogan, Manuel Rego Casasnovas, blink-dev
On Thu, May 7, 2020 at 12:04 AM 'David Grogan' via blink-dev <blin...@chromium.org> wrote:
On Wed, May 6, 2020 at 2:12 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 06/05/2020 22:03, 'David Grogan' via blink-dev wrote:
> Interoperability and Compatibility
>
> Compat:
> This is practically* the same behavior of Firefox so should not have
> compat problems. Also, probably not many sites use this property because
> it's only worked in Firefox.
> Interop:
> The main interop risk is that WebKit doesn't implement.
>
> * There's an edge case we don't yet implement that Firefox
> does. https://github.com/w3c/csswg-drafts/issues/4664

What's the rationale to ship this with a known bug?

Because perfect is the enemy of the good. And it's a weird case. There have been 3 spec issues about it, including the analogous grid behavior (https://github.com/w3c/csswg-drafts/issues/345 https://github.com/w3c/csswg-drafts/issues/472 https://github.com/w3c/csswg-drafts/issues/4664). If it were a straightforward case, there would have been less discussion. Weird cases seem less important to support than the main functionality.

Do you have a sense of how many developers are using gutters today with feature detection (so that they only apply in Firefox) and would hit this edge case once we'd start supporting the feature as a whole, but with diverging implementations on that front?
 

This has been shipped in Firefox with this behavior since Firefox
started supporting gaps in Flexbox, and in Grid Layout in Chromium since
mid-2018. So I believe developers are going to get confused due to the
different behavior in flex vs grid.
Why we don't implement the behavior from the spec for rows too?
Not doing it now and implementing it in the future would imply that some
sites might have issues.
Grid was not very widely used when we applied the spec change for this
in 2018 and some sites got affected by the change [1], I guess the same
will happen if we do this later.

I share this concern, but I think it is less likely to happen with flex. For grid, Firefox made the same switch, right? (I'm not positive) So developers relied on this feature because it had interop, then both engines changed behavior, and live sites broke. For flex, there will not be interop for this edge case so developers will be less likely to use it in live sites.

Also Firefox hasn't implemented this for grid rows yet (they implement
it only for gaps), and we are getting some interop bugs every now and
then due to that.

Yeah, we'll get an interop bug every now and then due to this edge case. But that seems like a worthwhile tradeoff to ship the feature earlier when it is so in demand (twitter lit up in response to the _code commit_, let alone devrel's later tweets).

Further, note that shipping this feature as is, without supporting this edge case, is a net big win for interop. Right now, we support neither the main functionality nor the edge case. Firefox supports both.

To be clear, thanks for bringing up this point, it deserves discussion.


Bye,
  Rego

[1]
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/_TBhjGLfAwAJ

--
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/CAOZbSt0mTJ4C8LLbTdL0Hrge4rwe252Bs64QBdT_-3iJZKJfZg%40mail.gmail.com.

David Grogan

unread,
May 7, 2020, 6:01:08 PM5/7/20
to Yoav Weiss, Manuel Rego Casasnovas, blink-dev
On Wed, May 6, 2020 at 10:46 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Thu, May 7, 2020 at 12:04 AM 'David Grogan' via blink-dev <blin...@chromium.org> wrote:
On Wed, May 6, 2020 at 2:12 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 06/05/2020 22:03, 'David Grogan' via blink-dev wrote:
> Interoperability and Compatibility
>
> Compat:
> This is practically* the same behavior of Firefox so should not have
> compat problems. Also, probably not many sites use this property because
> it's only worked in Firefox.
> Interop:
> The main interop risk is that WebKit doesn't implement.
>
> * There's an edge case we don't yet implement that Firefox
> does. https://github.com/w3c/csswg-drafts/issues/4664

What's the rationale to ship this with a known bug?

Because perfect is the enemy of the good. And it's a weird case. There have been 3 spec issues about it, including the analogous grid behavior (https://github.com/w3c/csswg-drafts/issues/345 https://github.com/w3c/csswg-drafts/issues/472 https://github.com/w3c/csswg-drafts/issues/4664). If it were a straightforward case, there would have been less discussion. Weird cases seem less important to support than the main functionality.

Do you have a sense of how many developers are using gutters today with feature detection (so that they only apply in Firefox) and would hit this edge case once we'd start supporting the feature as a whole, but with diverging implementations on that front?

Good question. Until today I thought there was no way to feature detect it[1][2]. Modernizr added a script-based check[3] in December though. But a github search for usages only returns copies of the Modernizr library, no usages of the check itself[4], which gives me the sense that not many developers are using it.

Yoav Weiss

unread,
May 8, 2020, 12:59:35 AM5/8/20
to David Grogan, Manuel Rego Casasnovas, blink-dev
On Fri, May 8, 2020 at 12:01 AM David Grogan <dgr...@google.com> wrote:


On Wed, May 6, 2020 at 10:46 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Thu, May 7, 2020 at 12:04 AM 'David Grogan' via blink-dev <blin...@chromium.org> wrote:
On Wed, May 6, 2020 at 2:12 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 06/05/2020 22:03, 'David Grogan' via blink-dev wrote:
> Interoperability and Compatibility
>
> Compat:
> This is practically* the same behavior of Firefox so should not have
> compat problems. Also, probably not many sites use this property because
> it's only worked in Firefox.
> Interop:
> The main interop risk is that WebKit doesn't implement.
>
> * There's an edge case we don't yet implement that Firefox
> does. https://github.com/w3c/csswg-drafts/issues/4664

What's the rationale to ship this with a known bug?

Because perfect is the enemy of the good. And it's a weird case. There have been 3 spec issues about it, including the analogous grid behavior (https://github.com/w3c/csswg-drafts/issues/345 https://github.com/w3c/csswg-drafts/issues/472 https://github.com/w3c/csswg-drafts/issues/4664). If it were a straightforward case, there would have been less discussion. Weird cases seem less important to support than the main functionality.

Do you have a sense of how many developers are using gutters today with feature detection (so that they only apply in Firefox) and would hit this edge case once we'd start supporting the feature as a whole, but with diverging implementations on that front?

Good question. Until today I thought there was no way to feature detect it[1][2]. Modernizr added a script-based check[3] in December though. But a github search for usages only returns copies of the Modernizr library, no usages of the check itself[4], which gives me the sense that not many developers are using it.

Is it possible that developers are using it through Modernizr?
Is that something you can get data on through the HTTPArchive?

Also, how hard would it be to resolve the related issues and align behavior with Firefox?

David Grogan

unread,
May 8, 2020, 1:15:10 AM5/8/20
to Yoav Weiss, Manuel Rego Casasnovas, blink-dev
On Thu, May 7, 2020 at 9:59 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, May 8, 2020 at 12:01 AM David Grogan <dgr...@google.com> wrote:


On Wed, May 6, 2020 at 10:46 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Thu, May 7, 2020 at 12:04 AM 'David Grogan' via blink-dev <blin...@chromium.org> wrote:
On Wed, May 6, 2020 at 2:12 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 06/05/2020 22:03, 'David Grogan' via blink-dev wrote:
> Interoperability and Compatibility
>
> Compat:
> This is practically* the same behavior of Firefox so should not have
> compat problems. Also, probably not many sites use this property because
> it's only worked in Firefox.
> Interop:
> The main interop risk is that WebKit doesn't implement.
>
> * There's an edge case we don't yet implement that Firefox
> does. https://github.com/w3c/csswg-drafts/issues/4664

What's the rationale to ship this with a known bug?

Because perfect is the enemy of the good. And it's a weird case. There have been 3 spec issues about it, including the analogous grid behavior (https://github.com/w3c/csswg-drafts/issues/345 https://github.com/w3c/csswg-drafts/issues/472 https://github.com/w3c/csswg-drafts/issues/4664). If it were a straightforward case, there would have been less discussion. Weird cases seem less important to support than the main functionality.

Do you have a sense of how many developers are using gutters today with feature detection (so that they only apply in Firefox) and would hit this edge case once we'd start supporting the feature as a whole, but with diverging implementations on that front?

Good question. Until today I thought there was no way to feature detect it[1][2]. Modernizr added a script-based check[3] in December though. But a github search for usages only returns copies of the Modernizr library, no usages of the check itself[4], which gives me the sense that not many developers are using it.

Is it possible that developers are using it through Modernizr?

I don't understand what "using it through Modernizr" means. Modernizr is just feature detection, not a polyfill?

Is that something you can get data on through the HTTPArchive?

I think this depends on the answer to the previous question.

Also, how hard would it be to resolve the related issues and align behavior with Firefox?

Not hard to implement, but harder to ensure the implementation doesn't cause correctness regressions. We'd have to implement it in both FlexNG and legacy flex. It would be obtrusive in legacy (unlike the main behavior) and recent history indicates that obtrusive changes in legacy flex have a high chance of introducing correctness regressions. So I was hoping to not implement until we can turn down legacy flex in a few quarters (after it stops being used for flex layouts in fragmentation, input elements, and editing contexts). If I do implement in legacy, it will need a full cycle of testing and would be put off until Chrome 85.

Manuel Rego Casasnovas

unread,
May 8, 2020, 1:40:09 AM5/8/20
to David Grogan, Yoav Weiss, blink-dev

On 08/05/2020 07:14, David Grogan wrote:
> Is that something you can get data on through the HTTPArchive?
>
> I think this depends on the answer to the previous question.

Not talking about Modernizr here, but in general I guess we cannot query
things like this in HTTPArchive. For this case we'd need to know if an
element is a flex container it has indefinite height and it uses
percentage row gap. It'd need to detect cases like for example:
<div style="display: flex; height: auto; row-gap: 10%;">
or:
<div style="display: inline-flex; height: max-content; gap: 10%;">

Maybe we should have a use counter to have some data to backup the
decision we take here. Otherwise I guess we cannot know how many sites
would be affected by this interop issue and how important would be the
effect on those sites. But I guess adding the use counter and getting
some useful data will take some time too.
Flexbox is very widely used (69% page loads according to chromestatus
[1]), it's hard to make guesses about how many sites would be using or
not the gaps feature and how.

> Also, how hard would it be to resolve the related issues and align
> behavior with Firefox?
>
> Not hard to implement, but harder to ensure the implementation doesn't
> cause correctness regressions. We'd have to implement it in both FlexNG
> and legacy flex. It would be obtrusive in legacy (unlike the main
> behavior) and recent history indicates that obtrusive changes in legacy
> flex have a high chance of introducing correctness regressions. So I was
> hoping to not implement until we can turn down legacy flex in a few
> quarters (after it stops being used for flex layouts in fragmentation,
> input elements, and editing contexts). If I do implement in legacy, it
> will need a full cycle of testing and would be put off until Chrome 85.

That's what I was asking about, the reason why we were not implementing
it yet. Thanks for the information.

The problem with this plan is that we don't know when we can turn down
legacy flex for sure, you mention "a few quarters" but we cannot be sure
if that's going to be 3 releases or 6 releases or whatever is the final
number.
People would start using gaps once they ship but then we'll change the
behavior for this case X releases after, what if by that time many sites
depend on the "broken" behavior?

One concert I have is the fact that the behavior for gutters in flex and
grid will be different only in this special case. I believe that can
create a bunch of misunderstandings to web authors.

Bye,
Rego

[1] https://www.chromestatus.com/metrics/feature/timeline/popularity/1692

Manuel Rego Casasnovas

unread,
May 8, 2020, 5:00:16 PM5/8/20
to David Grogan, Yoav Weiss, blink-dev


On 08/05/2020 07:39, Manuel Rego Casasnovas wrote:
>> Not hard to implement, but harder to ensure the implementation doesn't
>> cause correctness regressions. We'd have to implement it in both FlexNG
>> and legacy flex. It would be obtrusive in legacy (unlike the main
>> behavior) and recent history indicates that obtrusive changes in legacy
>> flex have a high chance of introducing correctness regressions. So I was
>> hoping to not implement until we can turn down legacy flex in a few
>> quarters (after it stops being used for flex layouts in fragmentation,
>> input elements, and editing contexts). If I do implement in legacy, it
>> will need a full cycle of testing and would be put off until Chrome 85.
>
> That's what I was asking about, the reason why we were not implementing
> it yet. Thanks for the information.
>
> The problem with this plan is that we don't know when we can turn down
> legacy flex for sure, you mention "a few quarters" but we cannot be sure
> if that's going to be 3 releases or 6 releases or whatever is the final
> number.
> People would start using gaps once they ship but then we'll change the
> behavior for this case X releases after, what if by that time many sites
> depend on the "broken" behavior?

One more thing about this, I can imagine people developing components
for Android webview, or an electron app, or an internal app that only
uses Chromium and then don't realize that this is an interop issue.
Percentages will be only resolved when the component has a definite size
and otherwise they won't be resolved (as it already happens in regular
blocks for percentage heights). Authors might probably not even check if
Firefox behaves the same, because they don't need interop with Firefox
and also current behavior looks good enough.
If in a few releases we change how that works, we're going to break
these components, as percentage row gaps will now cause the flex
container to have overflow, and that might cause overlapping other text
on the page (see attached image as an example).

Another option regarding shipping, could be to ship the spec behavior in
LayoutNG and a different behavior in legacy layout. Probably we already
have a bunch of things that work different in LayoutNG than legacy, and
if you happen to use a flexbox under one of the things that still use
legacy layout you'll be less lucky and have the wrong behavior. It'll be
weird when you compare it with a regular flexbox using LayoutNG, but at
least the default case (LayoutNG) would work the same than Firefox; and
as time passes more and more parts of Chromium will be moving to
LayoutNG and that behavior. Any thoughts on this?

My 2 cents,
Rego
flex-gaps.png

Christian Biesinger

unread,
May 12, 2020, 6:05:41 PM5/12/20
to Manuel Rego Casasnovas, David Grogan, Yoav Weiss, blink-dev
On Fri, May 8, 2020 at 4:00 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:
> Another option regarding shipping, could be to ship the spec behavior in
> LayoutNG and a different behavior in legacy layout. Probably we already
> have a bunch of things that work different in LayoutNG than legacy, and
> if you happen to use a flexbox under one of the things that still use
> legacy layout you'll be less lucky and have the wrong behavior. It'll be
> weird when you compare it with a regular flexbox using LayoutNG, but at
> least the default case (LayoutNG) would work the same than Firefox; and
> as time passes more and more parts of Chromium will be moving to
> LayoutNG and that behavior. Any thoughts on this?

We still use legacy for printing, right? So the page would look
different on screen vs printed?

Christian

Morten Stenshorne

unread,
May 13, 2020, 4:22:19 AM5/13/20
to Christian Biesinger, Manuel Rego Casasnovas, David Grogan, Yoav Weiss, blink-dev
Correct. The entire document is laid out by the legacy engine when
printing.

> So the page would look different on screen vs printed?

I'd also like to point out that legacy block fragmentation (printing /
multicol) of flexboxes is really broken (no pun intended; I mean "in a
really bad state"), due to crbug.com/606350 . You may want to take this
into consideration. That said, the fewer surprises, the better. It's
hard for anyone to anticipate whether things will occasionally (or
always) be laid out by the legacy engine or not (and the conditions for
falling back to legacy is "constantly" changing, anyway).

--
Morten Stenshorne, Software developer,
Blink/Layout, Google, Oslo, Norway

dhol...@mozilla.com

unread,
May 15, 2020, 7:40:13 PM5/15/20
to blink-dev, re...@igalia.com
[chiming in to reply to this post from up-thread a bit]


On Wednesday, May 6, 2020 at 3:04:15 PM UTC-7, David Grogan wrote:
On Wed, May 6, 2020 at 2:12 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 06/05/2020 22:03, 'David Grogan' via blink-dev wrote:
> * There's an edge case we don't yet implement that Firefox
> does. https://github.com/w3c/csswg-drafts/issues/4664

What's the rationale to ship this with a known bug?

Because perfect is the enemy of the good. And it's a weird case. [...] Weird cases seem less important to support than the main functionality.

Unfortunately, this weird case is quite easy for web developers to trigger by accident & without noticing. Consider the “gap” shorthand, which is an attractively concise way of using this feature (and which is the way you demo the feature in your dev-rel post[1]).  If a developer uses the “gap” shorthand (for brevity) with a percent value (because they like responsive design) on a flex container with height:auto (the default), then they’re likely to trigger this interop issue.  And they may do so without noticing, if they’re only testing in Chrome.
 
For flex, there will not be interop [with Firefox] for this edge case so developers will be less likely to use it in live sites.

This doesn’t feel like a safe or responsible prediction, given Blink’s dominant market-share.  Of course, we love when web developers test their sites in Firefox, but we realistically can’t always rely on them to do that -- and I don’t think you can rely on that, either, as part of your planning here.  (This is especially true for web content on Android, where Blink is obviously in an especially dominant position.)

If you do ship with this bug & your prediction does end up being correct here (i.e. if lack-of-interop prevents this Chrome bug from being cemented in as a de-facto standard), I suspect it will largely be due to to future work & outreach that Mozilla’s developers & webcompat-detectives will have to do, after getting reports from upset users about sites breaking in Firefox due to dependencies on this intentionally-shipped Chrome bug.  This is a foreseeable & nontrivial negative externality of this shipping decision, and I hope you’re taking it seriously as part of your calculus.  I empathize with not wanting perfect to be the enemy of the good, and I also empathize with the desire to ship the core functionality ASAP; but also, Blink’s market-share position imposes a particular “great power/great responsibility” consideration for decisions like this.

So: I’d advocate for fixing this bug in LayoutNG (at least), before you enable support for gaps in flexbox. That way, if you’re correct that this is a weird puntable edge case, then all will still be well & developers won’t notice this as a LayoutNG-vs-legacy-engine behavior difference. Alternately, if developers *do* bump into this behavior-difference and get confused, then that will be a signal to them that they shouldn’t rely on this behavior, and (just as you said RE Chrome/Firefox interop) they’ll be less likely to ship content with a fragile dependency on any particular behavior.  And perhaps they’ll file Chrome bugs, which would be appropriate in that scenario, instead of filing bugs in (or shipping content that’s broken in) browsers that are spec-compliant on this point.

Daniel Holbert
Mozilla

Iwan Lesmana Riza

unread,
May 15, 2020, 10:34:49 PM5/15/20
to dhol...@mozilla.com, blink-dev, re...@igalia.com
--
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.
ying-efedf624812871ad
ying-dcfa04be7ebac03b
tumblr_11793ac024ccb4975fc9bb85403eaaa1_87912cf6_500.jpg
ying-7cd416abe7d482ce (1)
retrieve.jpg
maven2classpath2.jpg
TB1NoU6aKbviK0jSZFNXXaApXXa-1000-666.jpg
network_cover.jpg
randall_stephenson.jpg
tumblr_9e4607d5ba87b46a5e92e84632e1acf7_550315d0_500.jpg
zac-profile.jpg
IMG-20200515-WA0017.jpeg
randall_stephenson_signature.jpg
info_strength_in_revenue.jpg
IMG-20200515-WA0014.jpeg
ying-28ddddbb7fc33615
tumblr_5e3505d9cca358f9fcf6e3edf5360d91_0c16aded_500.png
ying-9a82f2972879ddfe
ying-7cd416abe7d482ce
info_4g_lte_network.png
tumblr_16845b3143a80c5a73f09c35193bfa19_591db44b_500.jpg
cp_node.jpg
Notes_171214_124340_675.sdoc
cp_resolve.jpg
tumblr_695df46392d14781fad4f6f10a48322d_a7760f99_500.webp
settings_completion_att.jpg
tumblr_74055224aa2d9fb4333713ef7111b52d_57fea0d5_640.jpg
favicon.ico
hover-xref-cpython.png
tumblr_979c05be006344bc4aa9b6095603255d_07ff34fe_500.png
completion4.jpg
ivy_console.jpg
project_specific_settings.jpg

PhistucK

unread,
May 16, 2020, 4:38:36 AM5/16/20
to dhol...@mozilla.com, blink-dev, Manuel Rego Casasnovas
> So: I’d advocate for fixing this bug in LayoutNG (at least), before you enable support for gaps in flexbox.
I think this approach is much too lenient. It sounds like this feature should be delayed until this is fixed (or wait for FlexboxNG for shipping the feature). We managed many years since Flexbox matured without it. A few more months (or a bit more) is worth the wait if this is considered a bug (meaning, something that is truly wrong and there is broad agreement that the specification should not change because the feature is good and it makes sense), because it does not sounds like that much of an edge case, it sounds like a pretty easily encounterable case (to me).

Since there is no real telling when FlexboxNG would ship, developers may (read - probably) encounter this and stick to the Chrome behavior (as if there is a choice), breaking Firefox and eventually changing the specification to specify the less favorable approach.


PhistucK


--

David Grogan

unread,
May 20, 2020, 5:49:36 PM5/20/20
to PhistucK, Daniel Holbert, blink-dev, Manuel Rego Casasnovas
Good points, all. Digging in made us realize that the specified behavior was suboptimal. The CSSWG resolved on new behavior. Firefox will probably ship the new behavior a few weeks prior to Chrome 84, which is scheduled for ~mid July. (dholbert, can you confirm my understanding of Firefox's schedule?)

So, this thread is now about shipping behavior that Firefox and Chrome have, AFAIK, 100% interoperability.

Manuel Rego Casasnovas

unread,
May 20, 2020, 5:55:35 PM5/20/20
to David Grogan, PhistucK, Daniel Holbert, blink-dev
LGTM1

Thanks for finding a solution to the interop issues.

I'm all in for having gutters in flexbox!

Cheers,
Rego

On 20/05/2020 23:49, David Grogan wrote:
> Good points, all. Digging in made us realize that the specified behavior
> was suboptimal. The CSSWG resolved
> <https://github.com/w3c/csswg-drafts/issues/5081> on new behavior.
> Firefox will probably ship the new behavior a few weeks prior to Chrome
> 84, which is scheduled for ~mid July. (dholbert, can you confirm my
> understanding of Firefox's schedule?)
>
> So, this thread is now about shipping behavior that Firefox and Chrome
> have, AFAIK, 100% interoperability.
>
> On Sat, May 16, 2020 at 1:38 AM PhistucK <phis...@gmail.com
> <mailto:phis...@gmail.com>> wrote:
>
> > So: I’d advocate for fixing this bug in LayoutNG (at least),
> before you enable support for gaps in flexbox.
> I think this approach is much too lenient. It sounds like this
> feature should be delayed until this is fixed (or wait for FlexboxNG
> for shipping the feature). We managed many years since Flexbox
> matured without it. A few more months (or a bit more) is worth the
> wait if this is considered a bug (meaning, something that is
> truly wrong and there is broad agreement that the
> specification should not change because the feature is good and it
> makes sense), because it does not sounds like that much of an edge
> case, it sounds like a pretty easily encounterable case (to me).
>
> Since there is no real telling when FlexboxNG would ship, developers
> may (read - probably) encounter this and stick to the Chrome
> behavior (as if there is a choice), breaking Firefox and eventually
> changing the specification to specify the less favorable approach.
>
>
> ☆*PhistucK*
> <mailto:blink-dev+...@chromium.org>.
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8e514e70-4c5c-4ed2-9ee3-2eff019bbf13%40chromium.org?utm_medium=email&utm_source=footer>.
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BjORzKMJaRLy%3Dq3dthivy1BresYdOt4Z_ByNS4gXEfAw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BjORzKMJaRLy%3Dq3dthivy1BresYdOt4Z_ByNS4gXEfAw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOZbSt0D5W4Q8JKLcJ9NBUQRmcfB%2Bed8bsUYQXVcxX98Dsnw8A%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOZbSt0D5W4Q8JKLcJ9NBUQRmcfB%2Bed8bsUYQXVcxX98Dsnw8A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Chris Harrelson

unread,
May 20, 2020, 6:05:48 PM5/20/20
to Manuel Rego Casasnovas, David Grogan, PhistucK, Daniel Holbert, blink-dev
I'm recused from LGTMing, but just wanted to say thanks to everyone for coming to a good agreement!

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/1d46d7ac-40fc-c827-c7bd-e99e1961bcc0%40igalia.com.

Adam Argyle

unread,
May 20, 2020, 6:31:00 PM5/20/20
to Chris Harrelson, Manuel Rego Casasnovas, David Grogan, PhistucK, Daniel Holbert, blink-dev

Yoav Weiss

unread,
May 21, 2020, 2:55:16 AM5/21/20
to Adam Argyle, Chris Harrelson, Manuel Rego Casasnovas, David Grogan, PhistucK, Daniel Holbert, blink-dev
Yay for cross-browser agreement and interop!!
LGTM2

Daniel Holbert

unread,
May 21, 2020, 11:11:46 AM5/21/20
to David Grogan, PhistucK, blink-dev, Manuel Rego Casasnovas
Thanks for digging in & for proposing/justifying the spec-change (which I'm happy with).

I'm changing Firefox's behavior in accordance with this spec-change in https://bugzilla.mozilla.org/show_bug.cgi?id=1639627 -- that'll be in our Nightly builds within a day or two, and it should ship as part of Firefox 78, which hits release on or around June 30th.

~Daniel

Daniel Bratell

unread,
May 21, 2020, 2:55:37 PM5/21/20
to Yoav Weiss, Adam Argyle, Chris Harrelson, Manuel Rego Casasnovas, David Grogan, PhistucK, Daniel Holbert, blink-dev
Reply all
Reply to author
Forward
0 new messages