RE: [css-layout-api] Updates before F2F

Thanks Ian.

TLDR: I think it would be a good idea to change the interface for scrollbars to be like padding: { inlineStart, inlineEnd, blockStart, blockEnd }.

I don’t want to comment on the api itself too much because I don’t have strong opinions, but I noticed one thing which makes me feel unconfortable: scrollbar mechanisms are assumed to work in a classical ltr-ttb + desktop scenario, but scrollbars can and are put on other sides of the elements in rtl for instance. I can also imagine some other scrolling mechanisms that are covering more than one of the sides as well. Maybe better to make generic and not tie UAs to one design in particular?

I also believe the code forgot a bunch of “this.” for instance when calling resolve*() methods, or are those methods defined in the global scope?



From: Ian Kilpatrick [mailto:ikilpatrick@chromium.org]
Sent: Tuesday, January 3, 2017 2:33 AM
To: public-houdini@w3.org
Subject: [css-layout-api] Updates before F2F

Hi all,

I've created an explainer<https://github.com/w3c/css-houdini-drafts/blob/master/css-layout-api/EXPLAINER.md> on github which contains an overview of the API proposal so far. The spec<https://drafts.css-houdini.org/css-layout-api/> has also updated which is much more complete than last time.

Explicit things I'd like feedback on are:
 - How to handle min/max content contributions. I think this is the last major thing to nail down. We've talked about this previously about how we can do this either with an additional author defined method, or via the existing layout method; but I'd like to gain consensus here.
 - Any nits on naming and structure of the API in general. E.g. how this API handles scrolling, the utility functions, etc.

Thanks,
Ian