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

[David Grogan]

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

Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=1398483)

Edge: No public signals

Safari: No public signals (https://bugs.webkit.org/show_bug.cgi?id=206767)

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]

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]

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]

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]

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.

[1] https://www.reddit.com/r/css/comments/cb7a7h/flexgap_is_it_possible_to_check_for_it_with_media/

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=762679#c5

[3] https://github.com/Modernizr/Modernizr/pull/2485

[4] https://github.com/search?q=modernizr+flexgap&type=Code

[Yoav Weiss]

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]

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]

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]

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

[Christian Biesinger]

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]

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]

[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

[1] https://web.dev/flexbox-gap/

[Iwan Lesmana Riza]

--

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/8e514e70-4c5c-4ed2-9ee3-2eff019bbf13%40chromium.org.

[PhistucK]

> 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]

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.

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.

[Manuel Rego Casasnovas]

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>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8e514e70-4c5c-4ed2-9ee3-2eff019bbf13%40chromium.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]

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]

Agreed, this resolved nicely! 😻

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-%3DjF_2tu2BJQzkk%3DhHEz%3DhbwzBt%3DwcFkOA%3DXX4H0DLZw%40mail.gmail.com.

[Yoav Weiss]

Yay for cross-browser agreement and interop!!

LGTM2

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

[Daniel Holbert]

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]

LGTM3

/Daniel

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