Intent to Implement and Ship: Correct handling of percentages in children of flex items

[Christian Biesinger]

I already checked in parts of this change, but then I realized that maybe I should go through this process, so here goes...

Contact emails

cbies...@chromium.org Spec https://drafts.csswg.org/css-flexbox/#definite-sizes Summary Certain flex items should be considered to have definite sizes (see spec URL), and therefore if a child element of a flex item uses percentage sizes, they should work. Motivation With Flexbox, web developers would like to be able to size items relative to the size of the flex item. Since flex items get flexed and stretched, it doesn't necessarily make sense to give them an explicit size, but it is still desirable to size things relative to them.

Firefox and IE shipped this. No idea about Safari.

Interoperability risk Firefox: Shipped Edge: Shipped Safari: No public signals Web developers: Strongly positive Describe the degree of interoperability risk you believe this change poses. If this is a brand new feature, please characterize how much we might regret shipping this new feature because we might want to change or remove it in the future. If you don't have a launch tracking bug or row in the feature dashboard, include in this email links to relevant specs, standards discussions, or documentation about support for the feature in other browsers. Compatibility risk Not likely; any percentage sizes they used to use would have been ignored. In fact a lot of people have been asking us to support this.

Ongoing technical constraints None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes (sadly, not iOS...)

OWP launch tracking bug Not OWP, but: http://crbug.com/341310, http://crbug.com/542388, http://crbug.com/346275 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5670760496496640 Requesting approval to ship? Yes

[Rick Byers]

LGTM1 to ship

This feels like a bug-fix that doesn't require an intent to me.  There's a fuzzy line here, but in general I'd hate for everyone fixing a web-exposed interop bug to feel like they need to go through the overhead of an intent (I mean a bunch of such bug fixes land every day in blink).  It doesn't hurt to err on the side of caution though - especially if you have some cause to be concerned about compat or interop risk.  In the past the rough rule of thumb we've used is "is this a change in behavior of the magnitude that we'd want to update MDN docs for?" - if not, perhaps it's just a bug :-)

Rick

[Philip Jägenstedt]

LGTM2, and I agree with Rick that unless the situation is especially
tricky or risky, it's a shame to burden you with the extra paperwork.
A PSA can be a middle ground.

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

[TAMURA, Kent]

LGTM3.  I also think intent-to-ship is unnecessary in this case.

--

TAMURA Kent
Software Engineer, Google

[Levi Weintraub]

Non-owner lgtm. This is a big pain point for current flexbox sites.

[PhistucK]

I guess you felt that this needed announcing. :) If you could mention the reason why you felt this needed announcing, it might be clearer to everyone.

I guess, in the future, you can add a ChromeStatus.com entry for it without an intent (does anyone object?). This makes (it more) sure that a blog post announces that change.

☆PhistucK

[Joe Medley]

Speaking as a guy who's viewed every intent for the last year and a half, this also feels like a bug fix.

P.S. If it goes that way contact me directly. I know how to get the status entry removed.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Christian Biesinger]

Thanks for all the responses. I will not send Intents for such changes in the future. I sent this one because for past flexbox changes, I have gotten a lot of feedback of the sort that people felt they didn't have enough warning. So, maybe I should not send intents for bugfix-like changes but still create chromestatus entries? Or is that not necessary either?

-Christian

[Rick Byers]

I think it all comes down to the compat impact.  If the compat risk is really very low (eg. because we're matching all other engines in a way that most developers won't even notice), then who really needs "warning"?  But if we're likely to break a bunch of content that's come to rely on our bugs, then yeah we need an intent discussion.  I'm OK with the idea that there's some grey area in the middle too - eg. key bug fixes mentioned in the blog post (or even on chromestatus.com).

Rick

[Christian Biesinger]

OK, sounds good. Thanks for the advice.

-Christian