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

On May 15, 2013, at 3:55 PM, Sylvain Galineau <galineau@adobe.com> wrote:

> On 5/15/13 12:08 PM, "Brad Kemper" <brad.kemper@gmail.com> wrote:
> 
>> 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:
>>>>> 
>>>>>> 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.
> 
> I think the point is that such selectors are hard to read everywhere the
> pattern happens, not just when styling Regions.
> As such a more general selector syntax solution to this kind of nesting
> pattern may be more helpful than adding more
> at-rules?

I've nothing against a general solution for nesting selectors to avoid repeating long selector chains and improving readability. Tab even suggested @nest in the thread Alan quoted, which is also an at-rule. I don't see what the big deal is for adding more at-rules, though, when appropriate. And I think this is one of those situations where it is appropriate, where the situation is closer to the idea of a conditional at-rule and the idea of @page, which describes what happens to items appearing inside a particular fragmentainer. 

The possibility of some future device for more readable and DRY way of writing selectors for repeated chains of simple selectors should not excuse us now from creating a messy ugly syntax of selector chains inside other selectors all on one line. I'm not even clear if something like @nest would actually make much of a difference on improving ::fragment(). (More on that further down this message.)

I do know that the @region rule we have in the working draft is already much more readable and consistent with how we use at-rules elsewhere, and I don't understand the newfound prejudice against creating and using @rules, especially now that we have the conditional at-rule draft. If I've already selected the region to give it 'flow-into' why would anyone NOT prefer this for the first line of the fragment rules:

     @region flowname { 

instead of this for mixing selectors into one line:

   .select the #region box.again::region(write.a #single fragment .selector.all on::one_line:here) {

Even the fact that you can more easily visually associate the nested rules with the flow name is a huge advantage for @region. And the pseudo-element approach doesn't improve _that_ much by having a general nesting mechanism. That might just get you to something like this:

   .select the #region box.once { 
       flow-into: flowname;  
       @nest {
            ::self::region(write.a #single fragment .selector.all on::one_line:here) {

Or something like that. It is just not nearly as elegant as @page, @media, or @region, and I don't think it ever could be.

Received on Thursday, 16 May 2013 00:11:35 UTC