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

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.
 
 
 
 
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.
 
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
> 
>