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-display] Must a non-box-generated containing block be the initial containing block? #1672

Closed
Loirooriol opened this issue Aug 1, 2017 · 5 comments

Comments

@Loirooriol
Copy link
Contributor

The containing block definition says

a containing block is not a box (it is a rectangle), however it is often derived from the dimensions of a box. If properties of a containing block are referenced, they reference the values on the box that generated the containing block. (For the initial containing block, the values are taken from the root element.)

But what if something references a property of a containing block that has not been generated by any box, and is not the initial containing block?

According to CSS 2 and CSS Position, I think this case is not possible, but then you should say so. Otherwise, if it's possible, define what should happen.

@tabatkins
Copy link
Member

Other than the ICB, containing blocks are always generated by a box.

@fantasai fantasai added the css-display-3 Current Work label Aug 15, 2017
@Loirooriol
Copy link
Contributor Author

@tabatkins This has not been clarified in CSS Display, and one can't trust CSS Position because it's not maintained. So this issue is not fixed.

@tabatkins
Copy link
Member

As far as I know, nothing needed to be clarified - other than the ICB, every containing block is generated by a box, so any question about CBs that aren't generated by boxes (other than the ICB) is moot.

But yeah, one can't trust Position.

@Loirooriol
Copy link
Contributor Author

other than the ICB, every containing block is generated by a box

It's this statement what I think is not clear. It would be useful to include it in the definition.

@fantasai
Copy link
Collaborator

I'm not sure we need to preclude the possibility in the future--though I don't see us doing it in the future, I don't think we gain anything by locking down the definition here, either. So I think it's fine to leave the definition as-is, and if we end up with more cases like the ICB, define how they work when we create them.

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

3 participants