[css-layout-api] LayoutConstraints object - Are we ok with exposing information we don't have compat on?

[bfgeek]

This primarily comes up with orthog. writing modes, e.g.

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5867

<style>
#container { width: 200px; height: 100px; background: orange;}
#cross { display: flex; writing-mode: vertical-rl; padding-left: 10%; background: red; }
</style>
<div id=container>
  <div id=inner>
    <div id=cross>TEST</div>
  </div>
</div>

If #cross was controlled by the layout API (display: layout(foo)) it would get:

In chrome/webkit:

constraints.percentageInlineSize === 200;

In edge:

constraints.percentageInlineSize === 100;

In FF

constraints.percentageInlineSize == Infinity; // ?

As a basic example.

STOP! DON'T ARGUE ABOUT WHO IS CORRECT HERE AT THE MOMENT

Are we fine with giving the layout API different answers for different engines, and working towards compat in parallel?

Do we initially write tests for the LayoutConstraints object we know we have compat on?

Do we scope down the layout API initially in V1 and only accept LayoutOptions.sizing='block-like and only expose:

interface LayoutConstraints {
  readonly attribute double fixedInlineSize;
  readonly attribute double? fixedBlockSize;
}

As we strictly don't require knowing the percentage/available sizes when our inline/block size are determined by the engine.

[bfgeek]

Some other quick compat examples. :)

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5870

• Blink, FF differs from Edge

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5871

• Edge, FF differs from Blink

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5874

• Blink, Edge differs from FF

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5875

• Blink, FF differs form Edge

[css-meeting-bot]

The Working Group just discussed LayoutConstraints object - Are we ok with exposing information we don't have compat on?.

The full IRC log of that discussion

<dael> Topic: LayoutConstraints object - Are we ok with exposing information we don't have compat on?
<dael> github: https://github.com/w3c/css-houdini-drafts/issues/749
<dael> iank_: All engines have pretty good compat...what we'll pass through LayoutConstraints object...
<dael> iank_: When it's non-orthogonal writing modes we have pretty good compat on what we'll resolve inline % and block % to.
<dael> iank_: Problem is with orthogonal writing modes.
<dael> iank_: A few cases in the issue, we have nowhere near compat.
<dael> iank_: First example is what we resolve % to
<dael> iank_: Padding in this example is completely different on all engines
<dael> iank_: Not arguing about who is right, I made lots of test cases yesterday and they're very simpl.e
<gsnedders> iank_: plz make sure all these tests are in WPT
<dael> iank_: Do we want to get compat here first? Go back and not expose this initially and just use layout sizing as block-like? Are we fine exposing this knowing that orthogonal won't be common?
<dael> fantasai: I'm confused. Spec is clear.
<dael> iank_: No one follows spec.
<dael> dbaron: Seems silly to remove the feature for that reason. It should be clear what the spec says should happen in that case.
<dael> iank_: Half the comments on the spec...like Size with % size is one area of compat. For writing modes we only talk about available space.
<dael> dbaron: I think, it might be worth thinking about which thing makes the most sense in the API. Do you want the thing baesd on the parent's writing mode or your own?
<dael> iank_: It looks at everything in your own writing mode, but all engines have different conversion.
<dael> iank_: Here's a good example where % resolution for padding-left:10% varies. But the size you should resolve against isn't defined.
<dael> fantasai: Flexbox issue.
<dael> emilio: That was fixed recently in FF. If you test the nightly.
<dael> iank_: There's other cases here as well.
<dael> iank_: I'm fine with exposing all this, but it may be a while until we're toward compat.
<dael> iank_: Other option is strip LayoutConstraints and it's just the fixed layout size and the engine handles it's quirks for you.
<fantasai> s/it's/its
<dael> majidvp: Is there a way inside the worklet to detect UA?
<dael> iank_: Only if you pass in a property.
<dael> iank_: Initially given the state of compat I'd only feel comfortable exposing the simple layout and forcing block-like on everyone.
<dael> iank_: Keep in mind this is only input going in. For giving inputs to reach children I think we can reach compat there.
<dael> [silence]
<dael> dbaron: I'm not convinced that the compat problems are that severe.
<dael> dbaron: If houdini specs are clear what these things mean people impl the Hodini bits can be clear.
<dael> Rossen: You're saying code should work regardless of the inputs. If we need different inputs for different engines your code should do something right. It's to our benefit to work out compat bugs regardless of houdini
<dael> dbaron: Gecko has a data structure with this in the parent vs other have hte clind. If the speci is clear you can do the right thing.
<dael> iank_: Yes. Engines can give you different things for different stuff.
<dael> Rossen: So that's no change?
<dbaron> s/hte clind/in the child's writing mode/
<dael> iank_: Yes. I need to write tests to make sure my interpretation is right.
<dael> iank_: Issue is not an issue.