[css-regions] Comments

We (Apple) have also been working on figuring out how to extend CSS to a) support text-wrap around arbitrary shapes and b) to define regions (we call them slots) and flow content between them and hence there's a fair amount of overlap between what we've been doing and what is proposed in http://lists.w3.org/Archives/Public/www-archive/2011Mar/0011.html.

High-level comments on http://lists.w3.org/Archives/Public/www-archive/2011Mar/0011.html:

- the 'regions-thread' and 'regions-index' properties fail what I call "the Zen garden test"; to change the number of regions I have to change the document structure (there has to be one element in the document structure per region); Apple (as expressed at the f2f) has a strong preference for region models where the containers are always anonymous boxes.
- the 'region-shape', 'exclusions' and 'exclusion-shape' properties doesn't seem very friendly for humans and seems more geared to be produced by a tool.

Our approach:

We've chosen a different name (slots) to match CSS3 Template Layout, which defines the term slot and has the ::slot pseudo-element defined (http://www.w3.org/TR/css3-layout/#slot-pseudo).  The idea being to mesh harmoniously with CSS3 Template Layout, which lets you define the slots as grid cells as well. 

In our approach a slot is always an anonymous box and linking/chaining only apply to slots (i.e. anonymous boxes). Flow around positioned boxes and polygon external/internal wrapping/fitting operate on all on everything (and not just slots).

We've extended the slot model defined in CSS Template Layout to allow for positioned slots. We are also proposing using a new 'positioned-slots' property to define chaining between slots. 

The following example example would be encoded as:



body::slot(s1) { /* properties to set dimension of slot */ }
body::slot(s2) { /* properties to set dimension of slot */ }
body::slot(s3) { /* properties to set dimension of slot */ }
body::slot(s4) { /* properties to set dimension of slot */ }
body { positioned-slots: article1(s1 s2 s3) article2(s4) }

div#article1 { position: slot(article1) }
div#article2 ( position: slot(article2) }

We've also extended the syntax to allow for the ::slot(<ident>) pseudo element to appear inside an @page rule.

@page front
{
  ::slot(sidebar)
  {
    // properties to set dimension of slot;
  }

  ::slot(header)
  {
    // ... {dimensions} ...
  }
  ::slot(col1)
  {
    // ... {dimensions} ...
  }

  ::slot(col2)
  {
    // ... (dimensions) ...
  }

  positioned-slots: header, sidebar, body(col1, col2);
}

body { position: slot(body) }
div.header { position: slot(header) }
div#sidebar { position: slot(sidebar) }

For controlling text-wrap we've taken a different approach in that we have declared a box-interior-wrap-path and a box-exterior-text-wrap. When an box is determining it's text-wrap path it will use it's interior wrap path but also consider any exterior wrap path for boxes that are in front of it in Z-order (within the current stacking context). This doesn't give the same flexibility that 'exclusions' would give but it results in a fairly natural model (a box affect wrap of those things behind it).

We've also defined a 'box-wrap' property that takes the following values: auto (default), none, tight or rectangular. 

none - means that a box doesn't affect wrap of other boxes.
rectangular - means that a box affects wrap of other boxes but using the rectangular margin box.
tight - means that a box affects wrap of other boxes and wrapping is tight and uses the computed value of box-exterior-wrap-path. Perhaps a better name for 'tight' would be 'contour'.

When auto is specified the computed value depends on the box being positioned, floating or a slot. 
- for positioned boxes the computed value would be none; this would allow backward compatibility
- floating boxes would be rectangular (again allowing backward compatibility)
- slot would be tight/contour

The default value for box-wrap-exterior-path is auto and the computed value will in that case be based on  path that defines the border outset by a margin.

The default value for box-wrap-interior-path is auto and the computed value will in that case be a the current content area (for backwards compatibility).

Paths can be specified in a number of ways:

- svg-path(<string>) - specifies a path using the SVG compact syntax (svg-path production in SVG 1.1 section 8.3.9).
- image(<uri>) <percentage>? - the path is computed to be the path that encloses the area(s) where the opacity of the referenced image is greater than <percentage>; if the opacity percentage is not specified it defaults to 50%; we may need some way scale the path.

We could further add common parameterized geometric shapes. 

When a block box is determining what to wrap text around it computes an actual text wrap path. It is computed as the union of all of the following (for any element or slot which the computed value for box-wrap other than 'none'):
The box-wrap-exterior-path of floats (within the same containing block as the block box) that precede the block box (i.e. normal float rules with the addition of considering non-rectangular floats if 'box-wrap' mode is 'tight' for the floated element).
The box-wrap-exterior-path of slots that influence wrap of the containing slot (since the containing slot also acts as a containing block we could also say "of the current containing block")
The box-wrap-exterior-path of positioned boxes in front of the current box (in the current stacking context).
The inverse of box-wrap-interior-path of the box and it's DOM ancestors that share the same containing block.
The inverse of box-wrap-interior-path of the containing slot (or current containing block).
Hence, the actual wrap path specifies one or more shapes that text should flow around.

Kind regards,
- Jacob