Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
CSS Layout API #224
I'm requesting a TAG review of:
Further details (optional):
You should also know that...
This is an early review, so things might be difficult to understand and/or out of date in the specification and explainer. I'll ping this issue when large changes have been made / clarified, and when some initial code can be used in chromium.
We'd prefer the TAG provide feedback as (please select one):
Stream of consciousness: It's sort of odd that there's a
Took a pretty detailed look at this on the plane ride over :-).
Overall, I'm very excited to see this API--it really has the opportunity to be a game-changer.
Starting with some nits (mostly editorial):
Other thoughts (in sequential order as I read the spec top-to-bottom):
Example 1: Why the yeild at that particular spot (right after executing the map operation? Is the native Layout engine going to know how to handle an array of IntrinsicSizeRequests?
Nit & open question: "The LayoutConstraints object has percentageInlineSize and percentageBlockSize attributes. These represent the size that a layout percentages should be resolved against while performing layout." The "a" is weird in the sentence structure, and I'm lost as to the meaning of how "layout percentages should be resolved against" said number means? A follow-up example might help?
This sentence could really use a picture! "The LayoutEdgeSizes object represents the width in CSS pixels of an edge in each of the abstract dimensions (inlineStart, inlineEnd, blockStart, blockEnd)."
5.3 -- the
On Generators--this model relies on the benevolent developer to call yield in order to achive the layout parallelism/asynchronicity desired. It doesn't seem quite right--the break-points should be more deterministic and based on API calls--hense Promises would seem better suited to the task. But putting that aside, the author cannot expect to write a generator function without a crisp understanding of how that generator function will be used (e.g., how the code that uses the generator's iterator will use it, when it will be expecting intermediate results (if any), and with what parameters to
Example 6, the
The spec needs to be much crisper in defining what the
The paragraph about
In reflecting about the recursive nature of how a given pass through the
In 5.6, why does the
referenced this issue
Apr 7, 2018
Issue brought up in the CSSWG meeting:
Using a generator here as a poor-man's async is bad. It's not actually an iterator; while
Semantically, this should be an async function, with
Looks like this was reviewed recently and good progress is being made. We don't have any additional feedback at this time, but would love to take a second look when further spec revisions have landed. Please keep us in the loop, and thanks for flying TAG!