Re: [css-regions][css-overflow] named flows and overflow:fragments use case 1

On 10/22/13 2:49 PM, "François REMY" <francois.remy.dev@outlook.com> wrote:

>Hi Alan,
> 
>While this reply will probably cover the three mails of the series, I
>took the decision to reply to mail 1.
> 
>Firstly, while the series seems to cover the "how to make
>overflow-fragments and css-regions cooperate", I think it lacks an
>introduction stating why each one is necessary, for people that do not
>follow the debate closely. I also think starting with a concrete
> use case may help push the discussion forward in this case (even if I'll
>probably end up restating what you already said in the thread, just under
>another perspective).
> 
>The sample I propose to work on is the following one: a newspaper
>featuring a few articles on his front page, and continuing those articles
>in order in later pages (subsequent pages use a column-based layout).
> 
>A markup for such a newspaper could be:
> 
>|   main {
>|       div.front-page {
>|          div.box[for=A1]{}
>|          div.box[for=A2]{}
>|          ...
>|       }
>|       article#A1 {
>|           p{...}
>|           p{...}
>|           ...
>|        }
>|        article#A2 {
>|           ...
>|        }
>|        ...
>|   }
> 
>Creating a continuous paging experience in this case is challenging for
>all currently-proposed mechanisms.
> 
>(a) CSS Regions will easily help pour some content of some of the
>articles in the boxes of the first page
>(b) CSS Overflow will easily help divide the articles into pages
> 
>However, none of them will help achieve the desired layout without the
>help of JavaScript (CSS Regions require help to generate new boxes for
>paging the articles if needed, while CSS Overflow will require my CSS
>Regions polyfill to extract out of the articles
> the begining of the article (as needed to fit the first page boxes).
> 
>Like you said in another mail, a solution combining the two would
>potentially solve the problem easily:
> 
>|   main > article {
>|       overflow: fragments;
>|   }
>|   main > article[id] {
>|       flow-into: get( attr id || none ) content;
>|       flow-from: get( attr id || none );
>|   }
>|   
>|   main > .font-page > div.box[for] {
>|       flow-from: get( attr for || none );
>|   }
> 
>I think the use case is compelling.

Yes, I believe this is an example of 'escaping the sibling trap' - adding
boxes to a region chain otherwise defined by the siblings of an
overflow:fragments element.

> 
> 
> 
> 
>That being said, "overflow: fragments" make unsolvable the problem I
>outlined in a previous mail: the impossibility to define "region chains"
>and break away from them. Once your named flow enters in an Overflow:
>Fragment region, all of it is consumed without
> any possible escape, even a hard break.
> 
>In the previous thread about this problem, I got the advice to use JS and
>"dynamically add as many supplemental region breaks as necessary to
>escape the region chain" but in the case of Overflow: Fragments, this is
>not possible because the amount of regions
> to break is infinite.

I think this is another instance of 'escaping the sibling trap.' An
overflow:fragments element can choose to stop generating fragment boxes by
setting the overflow property on an ::nth-fragment pseudo-element to
something other than fragments. If those fragment boxes are part of a
region chain, you can escape out of a particular overflow:fragments
element by assigning other boxes (perhaps more overflow:fragment boxes) to
that named flow.

> 
>To cooperate properly, I think CSS Overflow and CSS Regions would
>probably benefit from a region-chaining mechanism (where all fragments
>generated by an Overflow: Fragments would share the same region family as
>the host element).
> 
> 
> 
> 
> 
>> From: stearns@adobe.com
>> To: www-style@w3.org
>> Date: Sun, 6 Oct 2013 18:23:22 -0700
>> Subject: [css-regions][css-overflow] named flows and overflow:fragments
>>use case 1
>> 
>> Hey all,
>> 
>> I've been thinking quite a bit lately about how overflow:fragments and
>>CSS
>> regions fit together. I've been talking to people off and on about this
>> for the last 16 months, but I figure it's better to write some of this
>> down and get the ideas logged on this list. This is just the first post
>>in
>> a series.
>> 
>> I revived the idea of overflow:fragments as one possible solution for
>>the
>> box generation issue in CSS Regions. It's not the only box-generation
>> mechanism we've discussed, but it's the one that's received the most
>> interest. The basic use-case for combining named flows with
>> overflow:fragments is to use it on the last region in a region chain. I
>> think overflow:fragments has more uses than this (both with named flows
>> and without), but it's where I started.
>> 
>> Without overflow:fragments, you can set auto-sizing on the last region
>>in
>> the region chain. This allows for a fixed-sized region chain to almost
>> always adapt to its named flow content. But if you add region breaks to
>> your named flow content, you can get into a situation where you have
>> defined fewer boxes than breaks. So in this situation, it's very useful
>>to
>> set overflow:fragments on the last region in the region chain. This
>> ensures that you'll generate a new box for every fragment created by a
>> region break. These overflow:fragment boxes can either be auto-sized or
>>a
>> fixed size. It's a complete solution to matching a region chain to the
>> named flow content.
>> 
>> One response to this use case is the notion that all of the boxes could
>>be
>> generated and styled using the ::nth-fragment() pseudo-element. This is
>> true for some basic cases, but taking named flows out of the equation
>>has
>> some big disadvantages:
>> 
>> 1. All of the boxes need to be siblings
>> 2. Styling has to use pseudo-elements versus classes and ids
>> 3. JavaScript access is limited
>> 
>> So my point here is that if you use named flows, overflow:fragments can
>>be
>> a useful overflow setting for the end of your region chain. I'll go into
>> other interactions in separate posts coming soon.
>> 
>> Thanks,
>> 
>> Alan
>> 
>> 
>
>
>

Received on Wednesday, 23 October 2013 01:59:18 UTC