- From: L. David Baron <dbaron@dbaron.org>
- Date: Wed, 8 Aug 2012 15:03:30 -0700
- To: Ojan Vafai <ojan@chromium.org>
- Cc: www-style@w3.org
On Wednesday 2012-08-08 14:25 -0700, Ojan Vafai wrote: > Before I start fixing bugs, what should we do in these cases? It seems to > me that respecting min-content/max-content is a no-brainer. I presume you're talking about respecting width:min-content/max-content on an element E when computing one of the intrinsic widths of E's parent P. > Should we also > respect percentage widths, fill-available and fit-content which depend on > the available width? It's certainly what I would expect as a web developer. > I'm not sure if we can safely change percentages without breaking existing > sites though. I don't think respecting 'fill-available' and 'fit-content' requires any change; the correct behavior is, I think, exactly the same as for 'auto', for both intrinsic widths. (The correct behavior of a preferred intrinsic width is either (a) to have no optional breaks or (b) to take up as much width as can be usefully occupied. The correct behavior of a minimum intrinsic width is to find the smallest width that doesn't lead to overflow that could be avoided by choosing a larger width.) For percentages, we could honor percentages by multiplying the relevant intrinsic width of E by the reciprocal of the percentage to find its contribution to the intrinsic width of the parent. This would produce the correct behavior as described above, but I don't think it's Web-compatible with respect to the 'width' property, outside of a table context (where percent widths on cells do, interoperably, behave this way). Gecko does do this behavior for the preferred intrinsic width, for percentage margin and padding (where the formula is different, since it requires multiplying the non-percentage part by the reciprocal of 1 minus the sum of the percents). -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Wednesday, 8 August 2012 22:03:54 UTC