- From: Bert Bos <bert@w3.org>
- Date: Thu, 29 Nov 2012 21:36:51 +0100
- To: www-style@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
application/component+xml.
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:
<style>
article {
flow-into: region;
}
.start { /* A slot in the imported layout */
height: 60vh;
}
body { /* Corrected selector */
decorator: url(region-layout.html/#region-layout);
}
</style>
<body>
<article>
...
</article>
<img class="bar" src="foo" alt="separate content">
</body>
(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/>
</div>
</decorator>
allows
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
--
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