- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 17 May 2013 10:34:59 -0700
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: Alan Stearns <stearns@adobe.com>, Sylvain Galineau <galineau@adobe.com>, "www-style@w3.org" <www-style@w3.org>
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. ~TJ
Received on Friday, 17 May 2013 17:35:51 UTC