You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There seems to be a presumption in the spec, in Firefox's implementation and the web-platform-test clip-path-polygon-008.html that the ellipse is calculated against a width of 300px.
"All the lengths expressed in percentages are resolved from the used dimensions of the reference box.", but CSS 2.1 10.3.3 indicates that the used value of margin-right in the above example is 800px: the values are overconstrained so the computed value for margin-right is ignored.
If the two margin values above are changed to auto, then the used values are (1000px-100px) / 2 = 450px each. This matches the behaviour of Firefox, which is the only browser I have here that supports this syntax.
So one of two things has to give:
Is the intention more like "... percentages are resolved from not-quite-used dimensions of the reference box; these are identical to the used dimensions in the way that percentages and "auto" values are resolved, but any additional constraints on used values described in CSS2.1 section 10 are not applied"? If so then the spec needs updating to reflect this, and I have a feeling this area might be more complex than it appears.
The specified behaviour is correct, in which case the testcase and implementation(s) need updating. If that's the decision I'm happy to update the testcase.
The text was updated successfully, but these errors were encountered:
It's not clear that this is happening because of the section you cite in CSS2.1, so css-shapes could use a clarification, but the used margin is not considered to be ignored, we just position the box so that the margin box overflows the end edge. See https://www.w3.org/TR/css-align-3/ for how that's been expanded to handle self-alignment in general.
If all of the above have a computed value other than 'auto', the values are said to be "over-constrained" and one of the used values will have to be different from its computed value
However, I've re-read css-align-3 and I now see that it effectively replaces much of CSS2.1 section 10, which I hadn't fully appreciated until now.
I see the intention if all the align-* and justify-* values are left at their defaults is that the results will be identical to CSS 2.1. It looks like they are except for the removal of the over-constraint clauses in 10.3.3, 10.3.7 and 10.6.4. And the only place I think think of where that change would have an effect is, of course, the margin-box in css-shapes-1.
It might be an idea to add a note to css-shapes-1 section 1.1, "Module Interactions", that the behaviour also depends on css-align-3. Although I'm sure I would have missed that too...
The "margin-box" in question is the one defined in css-shapes-1 relating to basic shapes. In this example:
There seems to be a presumption in the spec, in Firefox's implementation and the web-platform-test clip-path-polygon-008.html that the ellipse is calculated against a width of 300px.
"All the lengths expressed in percentages are resolved from the used dimensions of the reference box.", but CSS 2.1 10.3.3 indicates that the used value of margin-right in the above example is 800px: the values are overconstrained so the computed value for margin-right is ignored.
If the two margin values above are changed to
auto
, then the used values are(1000px-100px) / 2 = 450px
each. This matches the behaviour of Firefox, which is the only browser I have here that supports this syntax.So one of two things has to give:
Is the intention more like "... percentages are resolved from not-quite-used dimensions of the reference box; these are identical to the used dimensions in the way that percentages and "auto" values are resolved, but any additional constraints on used values described in CSS2.1 section 10 are not applied"? If so then the spec needs updating to reflect this, and I have a feeling this area might be more complex than it appears.
The specified behaviour is correct, in which case the testcase and implementation(s) need updating. If that's the decision I'm happy to update the testcase.
The text was updated successfully, but these errors were encountered: