W3C home > Mailing lists > Public > www-style@w3.org > May 2011

Re: [css3-regions][css3-content] Explicit/Implicit, Named/Anonymous Regions

From: Vincent Hardy <vhardy@adobe.com>
Date: Thu, 19 May 2011 16:35:23 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Christoph Päper <christoph.paeper@crissov.de>
CC: W3C style mailing list <www-style@w3.org>
Message-ID: <C9FAF3A5.2821%vhardy@adobe.com>
On 5/17/11 11:28 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>I like this listing of options, particularly for Part 2.  Allow me to
>boil it down into a more condensed form, for easier reading.
>When dealing with named flows, there are several types of things we
>can potentially style.
>1. The region that is accepting a flow.
>2. The elements in a particular flow.
>3. The elements flowed into a particular region.
>  3a. Elements that are entirely within a particular region.
>  3b. The portions of elements that exist in a particular region.
>I think that styling #1 is straightforward - the region is either an
>element or a pseudoelement, and thus is part of the element-tree.  You
>can select and style it as normal.  We don't need special @-rules for
>this, as CSS already has good syntax for it.

>> Yes.

>Styling #2 also seems relatively straightforward and easy - the only
>thing you have to resolve is where the flow-styles fit in the
>specificity hierarchy.  Presumably they automatically win over the
>ordinary styles applied to them via normal selectors.  This suggests
>that it can be handled as another specificity zone inserted between
>the style attribute and the author zone.

>> I am not sure we would actually need this. As you say later on, we
>>would need a use case and also, the author can probably style things the
>>desired way like so:

.elementInArticleFlow {
     flow: 'article';

h1.elementInArticleFlow {
     color: crimson;

>> Is there more that would be needed.

>#3 is where it gets both complicated and interesting.  We definitely
>have use-cases for it, which is the annoying part, as that means we
>can't just ignore it.  ^_^


>#3b can be handled by something like a ::lines-in(<flow>) pseudo,
>similar to what Hyatt suggested - we just extend the existing
>::first-line concept to be multiple lines.  ::first-line is hacky and
>bad, but UAs at least know how to handle it at this point, so
>::lines-in(<flow>) won't be any worse

Yes. There have been different options discussed for the syntax, but this
is a great summary of the discussion.

>#3a is a bit more difficult, as it runs into circularity issues worse
>than ::first-line.  It's very easy for an element to be entirely
>within a region before applying styles, and partially outside a region
>afterwards.  I suggest that, unless we have a *very* compelling
>use-case that can't be accomplished any other way, we skip trying to
>make #3a work, and just go with #3b.  #3b should still allow the
>use-cases I've seen, where text is styled differently in the first
>region than in the later regions.

I would mostly agree, except that there are things like the 'display:
run-in' example in the draft that cannot be done if we are limited to the
::first-line properties. And that type of effect is useful I think.

Also, I think there are things we can do about the selection rules to
simplify things a bit, for example saying that an element is selected in
an @region rule only if it fits completely within the region.

So I am thinking of keeping the feature in the draft and take it out if
implementation feedback shows that it is not possible (or too costly).

>So, in summary, #1 should already be handled by CSS.  #2 is relatively
>easy to patch in, but I'd like to see use-cases for it before we try
>to do anything in this direction.  #3a is very hard to do, so I
>suggest we skip it.  #3b is also hard, but no harder than ::first-line
>is already, and it hits the use-cases I've seen, so I suggest we
>pursue it.

I am on the same page, except that I propose we keep #3a on the table
until we get more input on use cases and implementation reports. Does that
make sense?

Received on Thursday, 19 May 2011 23:36:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:46 UTC