W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [css3-regions] Separating regions markup

From: Bert Bos <bert@w3.org>
Date: Thu, 29 Nov 2012 21:36:51 +0100
To: www-style@w3.org
Message-Id: <201211292136.51624.bert@w3.org>
On Wednesday 28 November 2012 00:11:18 Alan Stearns wrote:
> Hey all,
> As I mentioned last week, I've edited the sample code in Appendix A
> [1] in CSS Regions to move the regions elements to a separate file
> using custom elements from Web Components [2].
> Bert, Håkon - does this approach satisfy your requirement for
> separating content markup from layout?

I think it can work.

There are some other details missing, such as what the default 
formatting of these regions is. But those can be added.

The previous time we discussed using an XML syntax for defining regions 
(XBL or generic XML) we didn't continue with the idea, I believe, 
because the CSS syntax (the template syntax) was shorter and more 
readable. It can be short, because it only handles regions that are 
aligned to a grid, but that seems to cover most of the cases.

I don't mind also allowing an external resource to define regions. (Some 
systems already use such an XML file to define the layout; it could now 
be processed on the client side, rather than on the server side, which 
seems an improvement.) But being able to define a grid in one line in 
the style sheet itself is very convenient ('grid: "a b" "c d"'). I don't 
want to abandon that.

Some comments in random order:

1) Using an external format for defining a display structure is similar 
to using an external image for a background. If something gets 
complicated (whether an image or a layout) it is good to put it in a 
separate file.

2) Serving that external resource as text/html is not a good idea, 
though. That suggests that you can read it, print it, etc. as if it were 
an HTML document. Better would be to use a new MIME type, something like 

3) For linking to that external resource, I suggest merging the 'grid' 
and 'decorator' properties. That avoids that we have to define which one 
takes priority (or how they combine). Using only one property allows the 
author to choose if he wants

    DIV {
      grid: "a b c"  "d e f"     /* define regions with CSS syntax */

or prefers

    DIV {
      grid: url(regions.xml#r1)   /* define regions in XML */

4) You can refer to CSS-defined slots by their name:

    P {flow-into: a}              /* flow into slot "a" */

and there are scope rules (viz., the document tree) for finding which 
slot is meant if there are several of the same name. In the example in 
the wiki, the slots also have names (given by "class" attributes), so 
that seems to match nicely:

    P {flow-into: region}         /* flow into slot "region" */

5) Regions will also have to be chained. The proposal for chaining grid 
slots is

    DIV {
      chain: a c f            /* make slots a c f into a single flow */

That could work the same with external regions:

    DIV {
     chain: start region

And two slots with the same name would be implicitly chained, in the 
order they appear in the external file. (E.g., the example on the wiki 
has two slots both named "region" which therefore form a single flow.)

6) The example on the wiki uses the existing selector syntax to refer to 
external slots:

    DIV { grid: url(url(region-layout.html/#region-layout) }
    DIV .start { height: 60vh }

where .start selects a pseudo-element, created by the style sheet 
itself. I think I like that syntax, because it is short. (But it may be 
confusing that the pseudo-element isn't a sibling of any real element, 
even though this syntax suggests that it is.)

7) The grid templates proposed for CSS come with default rules for how 
to size and position the slots. We will need rules also to position and 
size the externally defined slots. (E.g., they could be like child 
elements that come after the ':before' pseudo-element and before any 
real child elements.)

8) I think there is an error in the example in the wiki. The regions 
should be defined on a common ancestor of the ARTICLE and the IMG, 
because both of those should flow into the regions. But the .bar 
selector selects the image. I think the syntax should be like this:

    article {
      flow-into: region;
    .start {             /* A slot in the imported layout */
      height: 60vh;
    body {               /* Corrected selector */
      decorator: url(region-layout.html/#region-layout);
      <img class="bar" src="foo" alt="separate content">

(There shouldn't be a 'flow-from'. There is no 'flow-from' if you use 
the CSS syntax to create regions, there shouldn't be one if you use 
externally define regions either. Just use the names of the regions. 
They need names anyway if you want to chain them.)

9) The external layout definition can have nested elements (so that you 
can align slots to one another easily), but you can only flow content 
into leaf elements (i.e., empty elements). E.g.,

    <decorator id=d1>
      <div class=group>
        <div class=slot1/>
        <div class=slot2/>


    P { flow-into: slot2 }

but not this:

    p { flow-into: group }  /* ERROR! */

10) The Web Components syntax has a <content/> element to indicate the 
default slot (where the own contents of the element with the external 
layout go). That is equivalent to the "*" slot in a grid template. I 
didn't see in the Web Components spec if there is always exactly one 
such element. More than one would be an error, but none doesn't have to 
be. We'd just have to define which slot is the default in the absence of 
a <content/> element.

> [1] http://dev.w3.org/csswg/css3-regions/#intro-example-code
> [2]
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html

> >[1] http://lists.w3.org/Archives/Public/www-style/2012Nov/0260.html
> >[2]
> >http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html 
> >[3] http://wiki.csswg.org/spec/css3-regions/sequestering-regions

  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Thursday, 29 November 2012 20:37:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:24 UTC