RE: Custom Layout and Inadvertent Style Updates

> > Sure, once we have a "custom layout event", we won't need that part,
> I agree with you. Still... 
> > (If your polyfill waits for a real layout, how do you keep up with
> multiple polyfills acting one after another? That seems hard to me.)
>  
> One idea for extending layout is that the layout-polyfill for say 
> "mygrid" runs in a separate script context, and only has access to the 
> "fragment-tree". E.g. it doesn't have access to the traditional DOM.
> You are only allowed a custom layout per node of the tree, and you can 
> only position / measure you decedents (or maybe only direct children).
>  
> We don't want to end up in a state where its easy for authors to 
> create dependency cycles with layout.
>  
> I can delve into a little more detail if you like, but these are only 
> very raw ideas. ;)
>
> Sure, please don't hesitate to share!
>That being said, while this looks great on paper (and should be pursued) I'm afraid this approach is too long-term, as it will require massive changes to how browser > work/expose their layout work.

> At this time, I'm (understandably) more interested in making what polyfills are doing now easier to do, by tweaking already-implemented platform features (because there's a clear incremental way forward when you move in that direction).

Yep, the Houdini stuff is pretty long term, but my hope is we can start lighting up some of these ideas sooner rather than later. For example more metrics in the current OM, custom props and values, and access to the parser. The custom layout stuff, IMO, is going to be best (not a requirement) once the fragment tree is implemented and built upon that. At any rate, keep the use cases coming and consider not only how they fit into CSS Houdini, but the same concept may be possible within the current platform as well.

Greg

Received on Friday, 10 April 2015 16:04:12 UTC