Skip to content

[css-shapes-1] Unclear on "margin-box" dimensions when box model is over-constrained #3275

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
faceless2 opened this issue Nov 1, 2018 · 2 comments
Labels
css-shapes-1 Current Work

Comments

@faceless2
Copy link

The "margin-box" in question is the one defined in css-shapes-1 relating to basic shapes. In this example:

<body style="width: 1000px">
 <div style="width:100px; margin-left: 100px; margin-right: 100px; clip-path: ellipse()"></div>
</body>

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:

  1. 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.

  2. 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.

@fantasai
Copy link
Collaborator

fantasai commented Nov 1, 2018

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.

@fantasai fantasai added the css-shapes-1 Current Work label Nov 1, 2018
@faceless2
Copy link
Author

faceless2 commented Nov 2, 2018

It was specifically this bit:

'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' = width of containing block

and

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...

I'll close this, thanks for your feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-shapes-1 Current Work
Projects
None yet
Development

No branches or pull requests

2 participants