Re: [css3-regions][css3-gcpm] Thoughts on Plan A and Plan B

On Feb 21, 2012, at 9:59 AM, David Hyatt <hyatt@apple.com> wrote:

>> I completely agree with this approach. In my view, we almost have page masters right now, with @page and its related @rules, except that they are only masters for margin boxes and size, and not the main content area. If we added column-related properties to the properties that could be used directly with @page, then the simple case of having different column numbers, width, etc. per named page (or pseudo-class selected page) would immediately be available. If we add to that being able to right rule sets with selectors within @page (like you can within @region), then you would be able to change fonts, colors, widths, etc. of any element based on what page it was in. If you go one step further, and add the ability to create an arbitrary number of pseudo-elements per page, then you could use 'content' with them to put decorations wherever you want on whatever pages you want, not just in the margins. I have proposed '@slot()' for this. combining this with regions, and you could have content flow from region to region, page to page. You could have your sushi column in your example work, by flowing it into a slot that is on the title page and the third page, but not the second. Anything that didn't fit in a slot because of page size or other constraints would automatically go to the next available page with the same 'flow-from'.
>> 
> 
> Yeah, we are definitely on the same page here. (Haha.) I would like to see column rules applicable to @page as well as the ability to define a set of slots for the page that can then be regions. The placement of the slots should be achievable with grid layout, floating or positioning.

Exactly my thinking. Cool. 

>> Combine all that with overflow:paged by making the pages it generates obey css3-page, and you've got a complete solution.
>> 
> 
> Yes.
> 
>>> If the CSS Regions spec remains the way it is, though, with explicit elements and scripting being the only way to build the paginated content, then I think we'll have failed. Page masters/templates and automatic generation of regions has to be addressed, and the explicit element requirement needs to be removed. The list of questions I have regarding how the layout of explicit element flows works is just growing (everything from layout cycles to sizing to how they paginate, etc.). If regions could only be generated anonymously by pagination and/or multi-column, then many layout, pagination and styling issues just go away.
>> 
>> Anonymously means they can't be selected and styled though, which I consider a negative.
>> 
> 
> I wasn't really using the spec term "anonymous." I just meant "they don't have a DOM element."

OK, great then.

Received on Tuesday, 21 February 2012 20:13:37 UTC