https://drafts.csswg.org/css-flexbox-2/#flex-property

All browsers agree on expanding flex: 1 0 with flex-shrink set to 0 rather than with flex-basis set to 0px.

For context, 0 is generally allowed to match <length> across CSS, and all browsers currently set flex-basis to 0% when omitted (#5742). So they currently expand flex: 1 0 to:

• flex-grow: 1
• flex-shrink: 0
• flex-basis: 0%

Since 0 cannot be interpreted as 0% (at least in flex-basis/width), this result shows that browsers give priority to <'flex-shrink'> instead of <'flex-basis'> to match 0, otherwise flex-basis would be set to 0px rather than 0%, like with flex: 1 0 0.

flex        =  none | [ <'flex-grow'> <'flex-shrink'>? || <'flex-basis'> ]
flex-grow   =  <number [0,∞]>
flex-shrink =  <number [0,∞]>
flex-basis  =  content | <'width'>
width       =  auto | <length-percentage [0,∞]> | ...

If I am not mistaken, alternatives (|) and options (||) are not defined with LTR or RTL priority. Put more simply, parsing 1 0 against <number> <number>? || <number> is ambiguous. Perhaps this could be fixed with:

When parsing flex, <'flex-basis'> can claim 0 only if <flex-shrink'> is fullfilled.