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

On 5/18/13 10:37 PM, "Brad Kemper" <brad.kemper@gmail.com> wrote:

>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?

Go back through the archive. From May 2011 on, the debate on at-rule
versus pseudo-element has been fairly constant and fairly evenly matched
on how many commenters prefer one side or the other. At one point we
discussed using a pseudo-element *within the at-rule* to denote that the
styling only applied to the fragment of the element displayed in the
region. So an additional point of motivation is to make it clear that
::region() is like ::first-line in that what's getting styled does not
necessarily correspond to an entire element.

> 
>
>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? 

Do you have a use case for nesting region styling? The draft not allow
nesting of region styling with the at-rule, either.

Thanks,

Alan

Received on Sunday, 19 May 2013 13:43:14 UTC