You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As I see the way unregistered layout functions are handled right now is ad-hoc: You always create a Layout API Container, but if the definition is not there you fall back to flow layout in some cases.
But the data in the definition is used for other stuff (i.e., blockification, for example, via childDisplay).
I tend to thing that instead of monkey-patching all the handling depending on the registeredness of the layout function and unregistered layout property should maybe just compute to flow-root or block... But I don't have all the context to know why the currently-specified handling is the way it is so I may be missing something.
The text was updated successfully, but these errors were encountered:
The Houdini Task Force just discussed unregistered layout functions, and agreed to the following:
RESOLVED: An unregistered or error'd layout() value causes blockification of the child elements, like the default value of childDisplay for a registered layout worker.
The full IRC log of that discussion
<TabAtkins> Topic: unregistered layout functions
<astearns> github: https://github.com//issues/844
<TabAtkins> iank_: When we register a layout function, there is a childDisplay property which tells the rendering engine how to build a box tree
<TabAtkins> iank_: By default it will blockify everything, similar to flex and grid
<TabAtkins> iank_: Other mode doesn't
<TabAtkins> iank_: We haven't specified what happens if you put display:layout(...) but the ... isn't registered yet
<TabAtkins> iank_: I have a slightly pref for blockifying everything, as it's the default
<TabAtkins> iank_: Less change if there's an error in your layout function
<TabAtkins> RESOLVED: An unregistered or error'd layout() value causes blockification of the child elements, like the default value of childDisplay for a registered layout worker.
As I see the way unregistered layout functions are handled right now is ad-hoc: You always create a Layout API Container, but if the definition is not there you fall back to flow layout in some cases.
But the data in the definition is used for other stuff (i.e., blockification, for example, via
childDisplay
).https://drafts.css-houdini.org/css-layout-api/#layout-api-box-tree doesn't define what happens if the definition is missing, and it should. I have no particularly strong opinion on what to do in that case...
I tend to thing that instead of monkey-patching all the handling depending on the registeredness of the layout function and unregistered layout property should maybe just compute to
flow-root
orblock
... But I don't have all the context to know why the currently-specified handling is the way it is so I may be missing something.The text was updated successfully, but these errors were encountered: