- 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