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

On May 17, 2013, at 10:34 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Thu, May 16, 2013 at 8:29 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On May 15, 2013, at 5:18 PM, Alan Stearns <stearns@adobe.com> wrote:
>>> On 5/15/13 5:10 PM, "Brad Kemper" <brad.kemper@gmail.com> wrote:
>>> 
>>>> 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.
>>> 
>>> I'm not following your use of @region above. You don't use the flow name
>>> in the old @region rule, you use the selector for the region. So for your
>>> example, it would have been:
>>> 
>>> @region .select the #region box.again {
>>> write.a #single fragment .selector.all on::one_line:here {
>>>   /* declarations */
>>> }
>>> }
>> 
>> Ah, well no wonder you didn't think it was hugely more readable. I was thinking it was '@flow' followed by the name of the flow, similar to @page and named pages. But I guess that wouldn't work, since more than one element can receive the same named flow. Hmm. I guess regions doesn't have the equivalent of css3 page's named pages, or a 'region' property to jump flow content to a particular named region, but maybe it should.
>> 
>> Anyway, the rest of my argument stands. I still think @region is more elegant and readable and writable, without resorting to workarounds for the inherent problems of the pseudo-element approach, workarounds which can't really give it enough help to restore the original simplicity and elegance of the @rule approach.
> 
> While I agree with you that the grouping allowed by @region was good
> (we've received feedback that the repetition required to use
> ::distributed() isn't great either), I'd rather solve it generically
> by reworking my Hierarchies (Nesting Rules) draft.
> 
> In other words, I support keeping ::region(), and then working on a
> generic nesting solution that'll fix the repetition.

I just don't understand the motivation for moving to a pseudo-element, other that not having to say in the spec how @region affects specificity. How can anyone look at this pseudo and think it is better for authors than the at-rule? 

The at-rule was elegant. Changing to this new monstrosity is like throwing some mud on pearls and then saying, "it's OK, we anticipate having something later on to make the mud look prettier." I find it very doubtful that something like @nest is going to help it much (I tried to see how that would work, in an earlier email, and it wasn't pretty). 

And what if you want to write rules to style something differently when it is in one particular region which is inside another particular region? Or if you have regions inside ::distributed()? Nested parentheses? Seriously?

Received on Sunday, 19 May 2013 05:37:48 UTC