Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[css-align] are there compatibility issues with replacing overconstraint rules from CSS2? #1428

Closed
dbaron opened this issue May 20, 2017 · 8 comments
Closed

[css-align] are there compatibility issues with replacing overconstraint rules from CSS2? #1428

dbaron opened this issue May 20, 2017 · 8 comments
Labels
Closed Accepted by CSSWG Resolution css-align-3 Current Work

Comments

@dbaron
Copy link
Member

dbaron commented May 20, 2017

The rules for justify-self on blocks and the rules for justify-self on Absolutely-Positioned boxes specify that they replace the overconstraint rules in CSS Level 2 with the rules for justify-self. This replacement is not scoped to values other than normal. I think that is probably a good thing.

However, one issue where the overconstraint rules have come up is the question of what getComputedStyle() returns for the used values of margin (for block) or offset (for abspos) properties. My memory is that this generally hasn't been particularly conformant to a literal reading of the spec, but this may have changed.

I think it's worth investigating what implementations do for getComputedStyle() and margins, and then either:

  • scoping this replacement to non-normal values (which in some sense would introduce inconsistency), or
  • adding a note that this replacement is intentionally intended to include normal values as well, and therefore that the used values of margins (for blocks) or offsets (for abspos) are no longer expected to be adjusted for overconstraint.
@dbaron dbaron added the css-align-3 Current Work label May 20, 2017
@dbaron
Copy link
Member Author

dbaron commented May 20, 2017

This also applies to the rules for align-self on Absolutely-Positioned boxes.

@dbaron
Copy link
Member Author

dbaron commented May 22, 2017

Also, any differences from CSS 2.1 should be noted explicitly.

@tabatkins
Copy link
Member

tabatkins commented Jun 26, 2017 •
edited
Loading

Testing:

Horizontal, block

<!DOCTYPE html>
<div>
 <child>foo</child>
</div>
<style>
div {
width: 300px;
border: solid;
}
child {
display: block;
background: rgba(0,0,0,.2);
width: 100px;
margin: 0 50px;
}
</style>
<script>
var s = getComputedStyle(document.querySelector("child"));
console.log(s.marginLeft);
console.log(s.marginRight);
</script>

Result: both Chrome and Firefox return "50px" for both margins, compatible with Align. (They do not apply the fixup in an author-observable way.)

Horizontal, abspos

<!DOCTYPE html>
<div>
 <child>foo</child>
</div>
<style>
div {
width: 300px;
height: 100px;
border: solid;
position: relative;
}
child {
position:absolute;
background: rgba(0,0,0,.2);
width: 100px;
margin: 0 50px;
left: 0;
right: 0;
}
</style>
<script>
var s = getComputedStyle(document.querySelector("child"));
console.log(s.marginLeft);
console.log(s.marginRight);
console.log(s.left);
console.log(s.right);
</script>

Result: Chrome returns "50px" for both margins and "0px" for both insets, compatible with Align. Firefox returns "100px" for 'right', exposing the used-value fixup in an observable way.

Vertical, abspos

<!DOCTYPE html>
<div>
 <child>foo</child>
</div>
<style>
div {
width: 300px;
height: 100px;
border: solid;
position: relative;
}
child {
position:absolute;
background: rgba(0,0,0,.2);
width: 100px;
height: 50px;
margin: 10px;
top: 0;
bottom: 0;
}
</style>
<script>
var s = getComputedStyle(document.querySelector("child"));
console.log(s.marginTop);
console.log(s.marginBottom);
console.log(s.top);
console.log(s.bottom);
</script>

Result: Chrome returns "10px" for both margins and "0px" for both insets, compatible with Align. Firefox returns "30px" for 'bottom', exposing the used-value fixup in an observable way.

@tabatkins
Copy link
Member

So looks like Chrome is compatible with the Align text in all cases, but Firefox is only compatible for block flow; for abspos elements, Firefox exposes the fixup and is thus inconsistent with Align. Since browsers are inconsistent, I suspect we can make this change (at least, Align seems to be honored more closely than 2.1 is).

Also, any differences from CSS 2.1 should be noted explicitly.

Isn't that what the "rules in [2.1] are ignored in favor of alignment as specified here" is saying?

@fantasai
Copy link
Collaborator

The prose is in the form

In terms of CSS2.1 formatting [CSS2], the rules for “over-constrained” computations in section 10.3.7 are ignored in favor of alignment as specified here, and the used value of the inset properties are not adjusted to correct for the over-constraint.

which explicitly specifies a) that it overrides CSS2.1 and b) that used values are affected as we're discussing here. Since resolved values are defined to reference used values, this means the spec should be sufficiently clear on this point.

Adding Agenda+ just to verify with the WG about overriding CSS2.1.

@gregwhitworth
Copy link
Contributor

To add to this, Edge produces the same results as Chrome for both test cases.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed are there compatibility issues with replacing overconstraint rules from CSS2, and agreed to the following resolutions:

  • RESOLVED: Accept margin and position properties will return the specified values
The full IRC log of that discussion <dael> Topic: are there compatibility issues with replacing overconstraint rules from CSS2
<dael> Github: https://github.com//issues/1428
<Rossen_> t, I thought you were irc-only :)
<dael> fantasai: What's going on is in the alignment spec we're saying we no longer do the overconstraint rules in CSS 2. Those are if you spec margin and padding and border and width on both sides. IT's spec in CSS2.1 that margin box must fill containing block. If you spec all these it won't fit likely. 2.1 says you take end size margin and treat it as auto.
<Rossen_> but you guys are awesome and multitask awesomely!
<dael> fantasai: IN alignment we're saying don't do that. When the margin box doesn't match the alignment dictates layout. Observably ther'es no difference. We spec the initial to be start alignmnt. dbaron pointed out we need to investigate situation with object model. Do you get he result of what was spec or what was used?
<dael> fantasai: TabAtkins ran tests, it's mostly like the align spec, but there's no compat. We wanted to verify the group is okay with this override
<gregwhitworth> fantasai: I just added that Edge matches Chrome
<dael> TabAtkins: Chrome always returns specified value for margin right, right or bottom. FF returns margin-right spec value, but fixed for right and bottom. I couldn't test other browsers at the time, but they're in the issue
<dael> gregwhitworth: I added, we match Chrome.
<dael> TabAtkins: Great. Sounds like there was little matching 2.1 Let's resolve to let align overrule
<dael> Rossen_: Okay, so let's match the spec to impl. Other opinions?
<dael> Rossen_: Objections to proposal?
<dael> RESOLVED: Accept margin and position properties will return the specified values

@tabatkins
Copy link
Member

Since Align already says it overrides 2.1, there's no change to be made. Closing, but if @dbaron thinks there's anything left to do, please ping this bug. ^_^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-align-3 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dbaron @tabatkins @fantasai @gregwhitworth @css-meeting-bot