RE: CSS Regions proposal

First, this [1] is very interesting and cool, I’m excited to see progress in getting CSS further into area of high end typography.

I have a few comments…


1)      Module name
The word “region” is good in representing that the shapes involved are not necessarily rectangular. It doesn’t represent however that the containers are connected. “thread” is better in communicating that, so perhaps it would work as the module name? Other options:

·         “Named flows” (as previously used in GCPM [2])

·         “Linked boxes”, “linked containers”, “connected frames” – some other terms I’ve seen in products or in implementation.


2)      Property names

Usually properties in the same module start with the same prefix. E.g. if the module is called “Threads” perhaps the properties should be ‘tread-source’, ‘thread-region’, ‘thread-content-consumption’ etc.?



3)      ‘flow-thread’ and ‘region-thread’

Elements in thread definition have two roles – content sources (‘flow-thread’) and content containers(‘region-thread’). It is really not intuitive from property naming that ‘flow-thread’ only provides the content and doesn’t render it.



A different option could be to name the source ‘thread-source’ or ‘region-source’ but the can also be very confusing because ‘source’ property usually points at the source (as <img src=”…”>).



GCPM deals with the role naming with directional properties:
    table .note {
        float: to(endnote);
    }
    table::after { content: from(endnote) }

That could translate to ‘thread-to’ and ‘thread-from’.
    <div style="thread-to:news">
        CSS 2.1 has no issues ...
    </div>
    <div style="thread-from:news"></div>
    <div style="thread-from:news"></div>



Another syntax option can be to use one property to designate a thread, and another to designate a role
    <div style="thread:news; thread-role:source;">
        CSS 2.1 has no issues ...
    </div>
    <div style="thread:news"></div>
    <div style="thread:news"></div>



4)      Does thread source have to be in same document?

Documents that are as complicated as magazines probably have a complex workflow that involves multiple files and different people working on design and content. Wouldn’t it be more scalable if the content could come from a file?



E.g.
    <iframe src="content.html" style="flow-thread:content"></iframe>

or
    <object data="content.html" style="flow-thread:content"></object>



5)      Can there be multiple sources?

What happens if multiple elements have “flow-thread:content”? It can be defined that all sources are concatenated (and it may make sense in GCPM examples). However if content is from multiple files concatenation in layout can be complicated. Regions proposal [1] hints that “quotations” thread can have multiple sources. I am not convinced however that use cases that call for source concatenation can’t be solved better by simpler means. Perhaps that should be optional…



6)      ‘display’ on ‘flow-thread’

Why is it important that ‘flow-thread’ is only applicable to blocks? If that element becomes the root element of content of a flow region, is it any different HTML from another source being in an iframe? Then whatever is applicable to HTML element should apply there… ‘display:table’ should work fine…



7)      ‘region-index’
Flexbox also has a property that reorders content – “flex-order”. As similar concepts these terms should be consistent across new specs. I suggest ‘order’.

Are there real use cases for region reordering? Even the example uses the explicit order that is same as source order. In very rare cases where order needs to be dynamic (e.g. depend on rotation), other means can be used to rearrange containers, for example order in flexbox or grid…


8)      ‘content-consumption’

The intent is clear but the way it is defined it can do much more than just repeating headers. ‘retain’ doesn’t create a copy of logical flow, it creates a fork, creating possibility of trees of logical flows where some containers ‘consume’ and some ‘retain’. That seems way more complicated than what the use case calls for.



Perhaps this could be a flow property instead of container property? Or instead of an option this could be done by multiple flow pointing at the same source (syntax for that may be complicated though).



9)      ‘region-shape’
There is a lack of symmetry on what kind of shape can be aligned to top-left as opposed to bottom-right. It will work better if it this shape can be positioned the same way exclusions can be positioned (and both should use same positioning as page floats, assuming that is powerful enough to be superset of what’s defined here).


10)  Region-based styling
It is easy to think about region-based styling as being similar to first-line. However it is really similar if it is first-page. Otherwise semantics of applying that is ambiguous. For example consider this makup (“---“ designate region boundaries

<style>
body { color:black; }
body div { color:green; }
body div div { color:blue; }
--- region 1
<body>
X
<div>
Y
<span style=”color:orange”>
Z
--- region 2 (sets “color:red” via region pseudoselector)
A
</span>
B
<div>
C
</div>
D
--- region 3

What colors are A, B and C?

The spec suggests that region style overrides all but inline styles. Then A is orange, others are red. But it is not what first-line would do – it is set on an element rather than container so nested elements are not overridden (and C would be blue).

This is tricky to define and hard to implement efficiently too. What if it would be limited to first-region? All use cases I can think of involve first-page being different… But if it needs to be defined on any region I’d prefer a definition that can match first-line when applied to first-region.


11)  ‘content-fitting’
As was already noted this should be a more general layout property.
And to match what was previously requested it should allow tweaking font-size and allow requesting fitting in a given number of lines…


12)  ‘exclusions’

It is a good idea to specify on an element what shapes it is willing to flow around. It may be difficult to manage though if specific shapes always need to be listed though. Probably OK for tool generated, but a hassle otherwise.



Could it be enough to just say that a box marked “exclusions:ok” will wrap around any available exclusions?



Do exclusions apply to all content of the element where ‘exclusions’ is set, including block elements? Or non-BFC children only? Or only children who opt in to wrap?


Thanks, this already looks impressive!
Alex

[1] http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0011/CSS_Regions.pdf

[2] http://www.w3.org/TR/2007/WD-css3-gcpm-20070504/