Bugzilla

I'm still confused/skeptical about correctness here.

David: thanks for weighing in here & helping us think through this.  Regarding your cat example, I have a few counterexamples/counterpoints that I'd love your thoughts on. You said:

(In reply to dgrogan(chrome) from comment #6)
> I _think_ this patch deals with the same issue as that github comment, which is: should the cats in https://jsfiddle.net/dgrogan/1a06xyjw/1/ be the same size? Blink says yes. Firefox says no. The spec says yes: there are no cyclic percentages present so compressibility doesn't apply.

Counterpoint/counterexample #1: if I take your jsfiddle and [replace the `img` elements with `input` elements](https://jsfiddle.net/dholbert/vmg971d6/), then Firefox doesn't change its behavior vs. your original testcase -- we still compress the one that has a percent -- but Chrome **does change** to agree with Firefox's rendering.  So, I'm skeptical of your above-quoted interpretation of Chrome's behavior and the spec's intentions on compressibility.  If there's a cyclic percentage in my version (as Firefox/Chrome seem to agree), then there is in yours as well, right? 

Counterpoint/counterexample #2: if I take your jsfiddle and [change the flex container to use `width:min-content`](https://jsfiddle.net/dholbert/7bsgy6n4/), then Chrome seems to lay out the first flex item in an interesting way -- it treats the img as compressible when computing the min-content contribution (which is why the flex container ends up being 100px wide -- that comes fully from the orange div's contribution), but it **does not** treat the img as compressible when computing its automatic minimum size.  [CSS-sizing 5.2.1c](https://drafts.csswg.org/css-sizing-3/#replaced-percentage-min-contribution) says the browser should treat the element as compressible in both cases (which is how Firefox handles this case).

All of which is to say, I think I disagree with TYLin's comment 8 (I think there *is* a cyclic percentage in dgrogan's cats testcase, just as browsers agree that there is in my counterexample#1), and it feels like Firefox is internally-consistent & matching the spec here, and I don't fully understand what Chrome is doing or how it ties back to the spec.

I'm still confused/skeptical about correctness here.

David: thanks for weighing in here & helping us think through this.  Regarding your cat example, I have a few counterexamples/counterpoints that I'd love your thoughts on. You said:

(In reply to dgrogan(chrome) from comment #6)
> I _think_ this patch deals with the same issue as that github comment, which is: should the cats in https://jsfiddle.net/dgrogan/1a06xyjw/1/ be the same size? Blink says yes. Firefox says no. The spec says yes: there are no cyclic percentages present so compressibility doesn't apply.

Counterpoint/counterexample #1: if I take your jsfiddle and [replace the `img` elements with `input` elements](https://jsfiddle.net/dholbert/vmg971d6/), then Firefox doesn't change its behavior vs. your original testcase -- we still compress the one that has a percent -- but Chrome **does change** to agree with Firefox's rendering.  So, I'm skeptical of your above-quoted interpretation of Chrome's behavior and the spec's intentions on compressibility.  If there's a cyclic percentage in my version (as Firefox/Chrome seem to agree), then there is in yours as well, right? 

Counterpoint/counterexample #2: if I take your jsfiddle and [change the flex container to use `width:min-content`](https://jsfiddle.net/dholbert/7bsgy6n4/), then Chrome seems to lay out the first flex container in an interesting way -- it treats the `img` as compressible when computing the min-content contribution (which is why the flex container ends up being 100px wide -- that comes fully from the orange div's contribution, with 0 coming from the img); but Chrome **does not** treat the img as compressible when computing its automatic minimum size (which is why the img ends up filling the flex container and insisting on being 100px wide).  [CSS-sizing 5.2.1c](https://drafts.csswg.org/css-sizing-3/#replaced-percentage-min-contribution) says the browser should treat the element as compressible in both cases (which is how Firefox handles this case).

All of which is to say, I think I disagree with TYLin's comment 8 (I think there *is* a cyclic percentage in dgrogan's cats testcase, just as browsers agree that there is in my counterexample#1), and it feels like Firefox is internally-consistent & matching the spec here, and I don't fully understand what Chrome is doing or how it ties back to the spec.

I'm still confused/skeptical about correctness here.

David: thanks for weighing in here & helping us think through this.  Regarding your cat example, I have a few counterexamples/counterpoints that I'd love your thoughts on. You said:

(In reply to dgrogan(chrome) from comment #6)
> I _think_ this patch deals with the same issue as that github comment, which is: should the cats in https://jsfiddle.net/dgrogan/1a06xyjw/1/ be the same size? Blink says yes. Firefox says no. The spec says yes: there are no cyclic percentages present so compressibility doesn't apply.

Counterpoint/counterexample #1: if I take your jsfiddle and [replace the `img` elements with `input` elements](https://jsfiddle.net/dholbert/vmg971d6/), then Firefox doesn't change its behavior vs. your original testcase -- we still compress the one that has a percent -- but Chrome **does change** to agree with Firefox's rendering.  So, I'm skeptical of your above-quoted interpretation of Chrome's behavior and the spec's intentions on compressibility.  If there's a cyclic percentage in my version (as Firefox/Chrome seem to agree), then there is in yours as well, right? 

Counterpoint/counterexample #2: if I take your jsfiddle and [change the flex container to use `width:min-content`](https://jsfiddle.net/dholbert/7bsgy6n4/), then Chrome seems to lay out the first flex container in an interesting way -- it treats the `img` as compressible when computing the min-content contribution (which is why the flex container ends up being 100px wide -- that comes fully from the orange div's contribution, with 0 coming from the img); but Chrome **does not** treat the img as compressible when computing its automatic minimum size (which is why the img ends up filling the flex container and insisting on being 100px wide).  [CSS-sizing 5.2.1c](https://drafts.csswg.org/css-sizing-3/#replaced-percentage-min-contribution) says the browser should treat the element as compressible in **both cases** (which is how Firefox handles this example).

All of which is to say, I think I disagree with TYLin's comment 8 (I think there *is* a cyclic percentage in dgrogan's cats testcase, just as browsers agree that there is in my counterexample#1), and it feels like Firefox is internally-consistent & matching the spec here, and I don't fully understand what Chrome is doing or how it ties back to the spec.

I'm still confused/skeptical about correctness here.

David: thanks for weighing in here & helping us think through this.  Regarding your cat example, I have a few counterexamples/counterpoints that I'd love your thoughts on. You said:

(In reply to dgrogan(chrome) from comment #6)
> I _think_ this patch deals with the same issue as that github comment, which is: should the cats in https://jsfiddle.net/dgrogan/1a06xyjw/1/ be the same size? Blink says yes. Firefox says no. The spec says yes: there are no cyclic percentages present so compressibility doesn't apply.

Counterpoint/counterexample #1: if I take your jsfiddle and [replace the `img` elements with `input` elements](https://jsfiddle.net/dholbert/vmg971d6/), then Firefox doesn't change its behavior vs. your original testcase -- we still compress the one that has a percent -- but Chrome **does change** to agree with Firefox's rendering.  So, I'm skeptical of your above-quoted interpretation of Chrome's behavior and the spec's intentions on compressibility.  If there's a cyclic percentage in my version (as Firefox/Chrome seem to agree), then there is in yours as well, right? 

Counterpoint/counterexample #2: if I take your jsfiddle and [change the flex container to use `width:min-content`](https://jsfiddle.net/dholbert/7bsgy6n4/), then Chrome seems to lay out the first flex container in an interesting way -- it treats the `img` as compressible when computing the min-content contribution (which is why the flex container ends up being 100px wide -- that comes fully from the orange div's contribution, with 0 coming from the img); but Chrome **does not** treat the img as compressible when computing its automatic minimum size (which is why the img ends up filling the flex container and insisting on being 100px wide).  [CSS-sizing 5.2.1c](https://drafts.csswg.org/css-sizing-3/#replaced-percentage-min-contribution) says the browser should treat the element as compressible in **both cases** (which is how Firefox handles this example).

All of which is to say, I think I disagree with TYLin's first line of comment 8 (I think there *is* a cyclic percentage in dgrogan's cats testcase, just as browsers seem to agree that there is in my counterexample#1), and it feels like Firefox is internally-consistent & matching the spec here, and I don't fully understand what Chrome is doing or how it ties back to the spec.