Bugzilla

I don't think the suggested warning here makes sense. In particular:

Firstly, this would only make sense to do for flex item, in their flex container's main axis. (That's the only place where `flex-basis` is actually honored in place of width or height).

...but even there, we shouldn't do this, because `width` (or `height`) still have subtle effects there, in particular:
   (1) it sets the value that `flex-basis:auto` will resolve to.
   (2) it establishes an upper-limit on what `min-width:auto` will resolve to (as of bug 1316534)

It might be useful to offer *some* warning / hint about this case, as a clue to authors about why `width` (or `height`) isn't behaving as they expect; but we definitely shouldn't report it or style it as "inactive" or having no effect.

I don't think the suggested warning here makes sense. In particular:

Firstly, if we were to have any warning about `width`/`height` colliding with `flex-basis`, it would only make sense to do for flex item, for the sizing property (`width` or `height`) that's in their flex container's main axis.  (That's the only place where `flex-basis` is actually honored in place of `width` or `height`).

...but even there, we shouldn't add an inactive-css warning, because `width` (or `height`) does still have indirect & important effects there. In particular:
   (1) it sets the value that `flex-basis:auto` will resolve to.
   (2) it establishes an upper-limit on what `min-width:auto` will resolve to (as of bug 1316534)

It might be useful to offer *some* warning / hint about this case, as a clue to authors about why `width` (or `height`) isn't behaving as they expect; but we definitely shouldn't report it or style it as "inactive" or having no effect.

I don't think the suggested warning here makes sense. In particular:

Firstly, if we were to have any warning about `width`/`height` colliding with `flex-basis`, it would only make sense to do for flex item, for the sizing property (`width` or `height`) that's in their flex container's main axis.  (That's the only place where `flex-basis` is actually honored in place of `width` or `height`).

...but even there, we shouldn't add an inactive-css warning, because `width` (or `height`) does still have indirect & important effects there. In particular:
   (1) it sets the value that `flex-basis:auto` will resolve to.
   (2) it establishes an upper-limit on what `min-width:auto` will resolve to (as of bug 1316534)

It might be useful to offer *some* warning / hint about this case, as a clue to authors about why `width` (or `height`) isn't behaving as they expect (why it's not precisely setting the element's exact width or height); but we definitely shouldn't report it or style it as "inactive" or having no effect.

I don't think the suggested warning here makes sense. In particular:

Firstly, if we were to have any warning about `width`/`height` colliding with `flex-basis`, it would only make sense to do for flex item, for the sizing property (`width` or `height`) that's in their flex container's main axis.  (That's the only place where `flex-basis` is actually honored in place of `width` or `height`).

...but even there, we shouldn't add an inactive-css warning, because `width` (or `height`) does still have indirect & important effects there. In particular:
   (1) it sets the value that `flex-basis:auto` will resolve to.
   (2) it establishes an upper-limit on what `min-width:auto` will resolve to (as of bug 1316534)

It might be useful to offer *some* warning / hint about this case, as a clue to authors about why `width` (or `height`) isn't behaving as they expect (why it's not precisely setting the element's exact width or height); but we definitely shouldn't report it as having no effect or style it as "inactive".