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.

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

[css-position-3] Auto margin resolution isn't symmetrical. #5374

Closed
bfgeek opened this issue Jul 30, 2020 · 6 comments
Closed

[css-position-3] Auto margin resolution isn't symmetrical. #5374

bfgeek opened this issue Jul 30, 2020 · 6 comments

Comments

@bfgeek
Copy link

bfgeek commented Jul 30, 2020

https://drafts.csswg.org/css-position-3/#abspos-margins

Otherwise, the remaining space is calculated as the size of its inset-modified containing block in the relevant axis minus the box’s used size in the relevant axis, and this remaining space is divided among any auto margins in the relevant axis. However, if the remaining space is negative and both margins are auto, the start margin resolves to zero and the end margin receives the remaining space.

There is a sutle different between the horizontal and vertical (or inline, and block? - needs research) algorithms:
https://drafts.csswg.org/css-position-3/#abs-non-replaced-width
https://drafts.csswg.org/css-position-3/#abs-non-replaced-height

See this testcase:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8318

In the vertical (or block, but which block?) direction negative auto margins get distributed evenly between the top and bottom, where-as horizontal (or inline) the inline-start margin is zero.

@bfgeek
Copy link
Author

bfgeek commented Jul 30, 2020

cc/ @fantasai

Unsure what all the UAs do for different writing modes.

@Loirooriol
Copy link
Contributor

Loirooriol commented Jul 30, 2020

In the vertical (or block, but which block?)

Chromium seems to use the wm of the abspos in order to decide between the algorithms, and Firefox the wm of the containing block. But in both browsers, the direction that decides which size becomes zero is the one of the containing block. https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/8322

@Loirooriol Loirooriol added the css-position-3 Current Work label Jul 30, 2020
@fantasai
Copy link
Collaborator

@Loirooriol For this kind of thing, we generally use the writing mode of the containing block, so I think Firefox is more correct in that respect.

fantasai added a commit that referenced this issue Aug 4, 2020
…s different in vertical vs horizontal axes per CSS2. #5374
@fantasai
Copy link
Collaborator

fantasai commented Aug 4, 2020

Edits checked in to make the behavior match CSS2, translating to vertical writing modes per containing block.

@tabatkins
Copy link
Member

And specifically, we aligned with Firefox's behavior (using containing block for both the axis and direction), because using the WM of one element but the direction of another, like Chrome does, is almost always wrong.

@bfgeek
Copy link
Author

bfgeek commented Aug 10, 2020

Are there additional tests for this now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants