Re: [css-regions] Changed @region rule to ::region() pseudo-element

On May 15, 2013, at 10:30 AM, Alan Stearns <stearns@adobe.com> wrote:

> On 5/14/13 4:09 PM, "Brad Kemper" <brad.kemper@gmail.com> wrote:
> 
>> On May 14, 2013, at 10:52 AM, Alan Stearns <stearns@adobe.com> wrote:
>> 
>>> On 5/13/13 8:55 PM, "Brad Kemper" <brad.kemper@gmail.com> wrote:
>>> 
>>>> On May 13, 2013, at 5:55 PM, Alan Stearns <stearns@adobe.com> wrote:
>>>> 
>>>>> Hey all,
>>>>> 
>>>>> Following the discussion in the earlier thread [1] about the
>>>>> similarities
>>>>> between region styling and the ::distributed() pseudo-element, I have
>>>>> changed the @region rule to a ::region() functional pseudo-element.
>>>>> Now
>>>>> if
>>>>> you want to use region styling to set the color of a fragment of an
>>>>> element with 'class=bar' that displays inside a CSS Region with
>>>>> 'id=foo'
>>>>> you can use:
>>>>> 
>>>>> #foo::region(.bar) {
>>>>> color: red;
>>>>> }
>>>> 
>>>> I actually greatly preferred the @region syntax, because it was easier
>>>> for writing several rulesets for how styles should change within a
>>>> single
>>>> region. I think it was also much more readable than having the selector
>>>> chains inside a pseudo-element of another selector chain.
>>> 
>>> I agree that the @region syntax was more compact for some cases. I think
>>> it's arguable that separating the content selectors from the box
>>> selector
>>> made it more readable.
>> 
>> Not to my mind. If it is a longish selector to select the region, and
>> another longish selector to select the proper elements to change within
>> that region, then one must write a very long selector with the
>> pseudo-element approach, all on one line. And then one must write the
>> first part again and again for each separate rule one wants to apply
>> unique styling to within the region. It doesn't follow DRY principles.
>> Whereas with the @rule, ones selects the region once, and then has
>> simpler, shorter selectors for each ruleset being selected within the
>> region. A little indenting within the style sheet, and one can clearly
>> see which selectors are children of the region selector.
> 
> This is a problem with longish selectors outside of region styling (as
> François mentioned[1]). I think the proper fix

At least you do admit, then, that it is harder to read, and needs some sort of fix that the @region version didn't. 

> is to have some kind of
> selector nesting mechanism that can be used anywhere.

We have the general pattern for doing nesting with @ rules. It is in @media and other conditional rules, and we have a limited version of nesting in @page.

I would argue that "element is in this fragmentainer" is a condition of when it should be given particular styling rules, and should therefore follow the css3-conditional @rule pattern[1], rather than inventing a new pseudo-event to hold selectors between parentheses on the same line. We can already see that having selectors inside the parentheses of other selectors is messy, especially when you have to do it multiple times for the same container. So I think it is a bad solution, and we shouldn't go there. We already have a better solution with conditional @rule syntax.

>>>> I also thought @region was an improvement on the similar type of
>>>> fragment
>>>> child-element styling of @page. With @page, there are child rulesets
>>>> only
>>>> for margin boxes within the @page, and I always thought @page would
>>>> benefit by being more like @region, allowing arbitrary selectors for
>>>> anything appearing within that fragment. So, I am very disappointed to
>>>> see the regions spec going away from the clear, easy to read and write
>>>> syntax it had, instead of seeing other specs, like paged media, moving
>>>> more towards the @region example. I'm not too familiar with
>>>> ::distributed(), but it might have benefited from moving to an
>>>> @distributed syntax instead too.
>>> 
>>> I suggested that, but the feedback I received in the earlier thread
>>> weighed heavily towards the pseudo-element for both cases. I'm fairly
>>> ambivalent about which syntax to use (both have advantages). The main
>>> thing I want to avoid is two entirely separate mechanisms for combining
>>> a
>>> container selector with a content selector.
>> 
>> But you have that by diverging farther from @page, don't you, in the
>> sense that the margin box selectors are the contents, and @page is their
>> container fragment? I know it's not exactly the same, but I think it
>> would be simpler and cleaner to nudge @page towards the @region way of
>> doing things, that to introduce a ::page() pseudo-element to be used for
>> each element one wanted to have selected separately with within a
>> particular page.
> 
> I had the @region rule in the draft with a number of issues, including one
> asking to change to a pseudo-element. The majority of the feedback I've
> gotten pushed me to make the change. One major point for me is that the
> desired specificity of region styling is consistent with other
> pseudo-element syntax. I also think that region styling is closer in
> concept to ::distributed() than the current capabilities of @page.

I disagree. Pages, like regions, are fragmentainers, and have been since long before that term existed. Distributed content in a shadow DOM is not. ::distributed is being imposed on us from a different working group, without a whole lot of discussion from this WG. It also seems much more likely with shadow DOM, if it is to be used for small widgets, etc., that it would typically contain a very limited number of simple selectors to include in a ::distributed pseudo-element, compared to more rules and more complex selectors that are likely to be desired for region-specific and page-specific styling.

The specificity issue should be handled in other ways. Prose can be added to the spec to get the needed specificity added whenever there is an @region.

> Let's see what more people think now that I have ::region() in the draft.

OK. Then lets see if there are enough compelling arguments to warrant changing the working draft to use a pseudo-element instead of an @rule. 

1) http://www.w3.org/css3-conditional

Received on Wednesday, 15 May 2013 19:09:04 UTC