RE: layout collapsibility

Hi Rossen,

Thanks for this proposal, I can clearly see the usefulness of this feature. It’s a nice incremental update that looks reasonable to me. That being said, collapsibility is only part of the equation. When I tried to remember user interfaces that made use of collapsibility for responsive design, the Office ribbon came to my mind, and I remembered some other interesting features that this layout had in addition to collapsibility:

- Some sections have a width that “snaps” to some specific width-increments (example: the ‘style gallery’ of Word, which only grows by entire item).
- Some sections that switch layout when there’s a size constraints (example: the cut/copy/reproduce section) to accommodate less space.
- Section almost never really “collapse”, they are just replaced by a placeholder.

All of this just to conclude there’s one thing I would have loved to see in this mail but didn’t, and it’s real-world use cases. I’m sure you presented some of them to the WG in the meeting in Seattle but I think some of us would find it great if you could share them here.

Best regards,
François
_____________________
PS: The reason I’m asking for this is that I had another vision in mind for this feature, which could be summarized as "alternative layouts". In such case, a single element has multiple alternative layouts ordered by preference, and the browser choose the first one that allows to render the element without forced shrink, for example. That's possibly more complex but also covers some uses cases I envisioned for "element queries", a feature that looks rather complex to support but many people do find useful. I'm not saying this is "the" way to solve the problems you've in mind, but I was curious to see how well it would hold on ;-)



De : Rossen Atanassov [mailto:Rossen.Atanassov@microsoft.com] 
Envoyé : mardi 28 janvier 2014 00:03
À : www-style@w3.org
Objet : layout collapsibility 

Collapsibility is one these useful layout features that we exposed in tables and now we’re trying to do it for flex and grid. The usual way it’s used is by crafting selectors that when matched define visibility: collapse etc. 

Another usage pattern of collapsibility is based on layout. One pattern I’ve noticed is when authors layout elements off-screen and then apply collapsing to elements based on the used style. My hope is that we can come up with a way that would enable layout to handle collapsibility automatically. To do that we can introduce a min-width-collapse, min-height-collapse properties. The property would trigger collapsing if the width or height available for the element’s box during layout is less than the used value of the property.

min-width-collapse: <length> | <percentage> | inherit 
min-height-collapse: <length> | <percentage> | inherit

For the purposes of shrink-to-fit the new definition would most likely imply the following change to preferred minimum and preferred width:

* preferred minimum width = (min-content >= min-width-collapse) ? min-content : 0
* preferred width = (max-content >= min-width-collapse) ? max-content : 0

With the above change the shrink-to-fit width should still be computable as defined in CSS 2.1 or the CSS 3 sizing spec.
min(max(preferred minimum width, available width), preferred width)

We’ll have to deal with ordering of collapsing which by default could be document order.

Thanks,
Rossen

Received on Tuesday, 28 January 2014 21:41:18 UTC