I think this is a Chrome bug.  `flex-basis` is specced as accepting
everything that `width` accepts (plus another keyword):
> Value: content | <'width'>
https://drafts.csswg.org/css-flexbox-1/#flex-basis-property

So if there's a keyword accepted by `width` that flex-basis rejects, that's
a bug.


On Mon, Sep 23, 2024 at 9:13 PM 一丝 <yio...@gmail.com> wrote:

> Chrome supports `-webkit-fill-available` in the width/height properties,
> but not `flex-basis: -webkit-fill-available`, while Firefox supports it
> well (flex-basis: -moz-available ). This can be very confusing for CSS
> authors and may lead to some interoperability issues.
>
> So I hope that `flex-basis: stretch` will be supported when the stretch
> keyword is implemented.
>
> 在2024年9月20日星期五 UTC+8 10:04:17<David Grogan> 写道:
>
>> Contact emailsdgr...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/css-sizing-4/#sizing-values
>>
>> Summary
>>
>> A keyword for CSS sizing properties (e.g. 'width', 'height') that allows
>> elements to grow to exactly fill their containing block's available space.
>> It is similar to '100%', except the resulting size is applied to the
>> element's margin box instead of the box indicated by 'box-sizing'. Using
>> this keyword allows the element to keep its margins while still being as
>> large as possible. Essentially an unprefixed version of
>> '-webkit-fill-available'.
>>
>>
>> Blink componentBlink>Layout
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout>
>>
>> Motivation
>>
>> To get this behavior without this new property you have to jump through
>> hoops. You can use align/justify-self:stretch, but then you can't use
>> align/justify-self to actually align the element. Also, not all layout
>> modes support align/justify-self in both the inline and block directions.
>> Alternatively, in many situations but not all, you can use a variable to
>> store the element's margins and refer to the variable in both the margin
>> and sizing properties, like height:calc(100% - var(--my-margin)). That's
>> clearly a hassle.
>>
>>
>> Initial public proposalNone
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/1054)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/401)
>>
>> *Web developers*: Positive (
>> https://github.com/web-platform-tests/interop/issues/726) An author
>> requested this to be part of Interop2025. Lots of +1 on the chrome bug.
>>
>> *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?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?No
>>
>> No tests yet. Will add before enabling.
>>
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameNone yet
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6176445286842368?gate=6350180832772096
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_rCTkCcq964bB7NahAvfC6pVzV32P734qgPqrdJfbbQMNusA%40mail.gmail.com.

Reply via email to