- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 1 Jul 2015 12:51:19 -0700
- To: Florian Rivoal <florian@rivoal.net>
- Cc: www-style list <www-style@w3.org>
On Wed, Jul 1, 2015 at 12:30 PM, Florian Rivoal <florian@rivoal.net> wrote: > On 01 Jul 2015, at 20:22, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> On Wed, Jul 1, 2015 at 8:08 AM, Florian Rivoal <florian@rivoal.net> wrote: >>> The current definition of the 'contain' property doesn't work well >>> with regions. flow-from and flow-into are scoped to the contain:style >>> container, but that's not enough, and regions make contain:layout >>> ineffective when used without contain:style. >>> >>> <article> >>> <div id=container> >>> <p>Lorem ipsum dolor sit amet... >>> </div> >>> <div id=container> >>> <div>...<table>...<tr>...<td>.../* arbitary nesting */ >>> <p>Aenean vestibulum, dui eu bibendum sagittis... >>> </td>...</tr>...</table>...</div> >>> </div> >>> <p>Sed semper vehicula nisl ac dignissim... >>> </article> >>> >>> <style> >>> container { >>> contain:layout; >>> height: 100px; >>> width: 100px; >>> } >>> p { flow-into: my-flow; } >>> p { flow-from: my-flow; } >>> </style> >>> >>> You can't know what the content of the second or third <p> >>> is going to be (and therefore you cannot lay them out) >>> without first laying out the content of the preceding >>> container. Which also means you cannot figure out the >>> height of <article>, without doing a full layout of all >>> its children, despite the presence of contain:layout on >>> some of them. >>> >>> In the best case, that means that UAs cannot do the type of >>> optimizations you'd expect from contain:layout if regions >>> are involved, and in the worst case, that means UAs can >>> never to the type of optimization you'd expect from >>> contain:layout because regions *might* be involved, and >>> it's too hard to figure out if they actually are. >>> >>> I see 2 ways out of that: >>> >>> 1) merge layout and style containment >>> >>> 2) add a region-specific rule to layout containment in addition >>> to those in style containment. Here's one that should work: >>> >>> The first (if any) region in a region chain that is either >>> a contain:layout element itself or the descendant of one is >>> treated as if it was the last region in the chain, and gets >>> all the remaining content in the associated named flow. >>> Subsequent regions in the chain do not receive any content >>> from the named flow. >>> >>> You'll still need to walk the through the preceding regions >>> in a region chain before you can layout the next one, but >>> if any of them is in a contain:layout element, you don't need >>> to lay it out before you can continue. >>> >>> Actually, we need to reword that so that if several regions >>> of the same chain are descendants of the same contain:layout >>> element, it's the last of one rather than the first, that should >>> behave as the last one in the chain. But that's hard to phase well, >>> so it's probably easier to understand my point with the definition >>> above, even if we need to tweak it before putting it in the spec. >> >> I'm fine with layout containment also breaking region chains. > > By which you mean do what I said, or do the same as contain:style? Either. ^_^ But yours is less disruptive to regions in general; it means you can still flow into a layout-contained element, and it doesn't stop you from flowing *out* of one. So yeah, yours is preferable. ~TJ
Received on Wednesday, 1 July 2015 19:52:06 UTC