- 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>
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?
Vincent.
Received on Thursday, 19 May 2011 23:36:57 UTC