A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/w3c/csswg-drafts/issues/1679 below:

[css-flexbox] Definiteness of flex items' main size depend on flex-basis's definiteness · Issue #1679 · w3c/csswg-drafts · GitHub

From email:

I've been looking through a few non-interoperable parts of flexbox again recently, and have run into https://codepen.io/gsnedders/pen/WRZQrx?editors=1100#0 again. Notably, Edge and Firefox both pass this test case, and Chrome and Safari fail. Except, as it turns out, the behaviour in Chrome and Safari is right. (Actually, the behaviour in Safari is wrong, it just happens to be right for that test case, but let's never mind details!)

I can't work out is where the behaviour in Edge and Firefox comes from, though maybe it is down to interpretation of the spec prior to 2f0ad00 and whether you need to measure content in this case? Though that doesn't seem true? I haven't dug too deep into this though!

That said, what I'm really here to ask is when and why we decided to go with the behaviour the spec and Chrome now have and hence against the Edge/Firefox behaviour. This seems to be something that trips web authors up a fair bit (there's lots of bugs in the Chromium bug tracker about this!). Something to point people at as to, "hey, here's why the spec does this nowadays, and why we think this is better behaviour", ideally—though obviously a blog post summarising it may well be needed!

Note that since this was written, Safari's behaviour is now genuinely right, because it now shares its flexbox implementation with Chrome.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3