Skip to content

[css-layout-api] Intrinsic sizes and orthogonal children behaviour #776

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

Open
bfgeek opened this issue Jul 1, 2018 · 1 comment
Open

Comments

@bfgeek
Copy link
Contributor

bfgeek commented Jul 1, 2018

<div style="display: layout(foo);">
  <div id=verticalrl >
    Some content, but it really doesn't matter.... 
  </div>
</div>
registerLayout('foo', class {
  intrinsicSizes(children) {
    const sizes = children[0].intrinsicSizes();
  }
});

What is the value of sizes above?

@css-meeting-bot
Copy link
Member

The Working Group just discussed Intrinsic sizes and orthogonal children behaviour, and agreed to the following:

  • RESOLVED: Intrinsic size in orthogonal flows are taken according to the writing mode of the containing block, and that intrinsic size calculations have to be consistent with all other places in CSS (per CSS Sizing).
The full IRC log of that discussion <fantasai> Topic: Intrinsic sizes and orthogonal children behaviour
<fantasai> github: https://github.com//issues/776
<fantasai> iank_: I can say what I expect
<fantasai> iank_: I expect that Sizes is the intrinsic size contribution of that chid in the parent's writing mode
<fantasai> iank_: Different engines will calculate it differently
<fantasai> Rossen: That sounds every vague
<fantasai> s/vague/overly vague for it to be any kind of definition in the spec/
<heycam> fantasai: you're trying to say that the result of that should be the same thing that the layout engine uses for intrinsic size calculation
<heycam> ... whether it's shrink to fit on [various things], intrinsic size keywords, ...
<heycam> ... they should all return the same thing, which is the thing returned here, and just be clear about which axis we're grabbing from
<heycam> ... I think we can put that in the spec, and is definite enough to not be vague
<heycam> ... it's exactly what we're doing in the sizing spec in a number of cases, we don't define how to calculate the intrinsic size, but we require it's consistent across all the places we use it
<heycam> Rossen: I agree
<heycam> RESOLVED: Intrinsic size in orthogonal flows are taken according to the writing mode of the containing block, and that intrinsic size calculations have to be consistent with all other places in CSS (per CSS Sizing).

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

2 participants