- From: Alan Stearns <stearns@adobe.com>
- Date: Tue, 14 May 2013 10:52:11 -0700
- To: "www-style@w3.org" <www-style@w3.org>
- CC: Brad Kemper <brad.kemper@gmail.com>
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. > > >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. Thanks, Alan >
Received on Tuesday, 14 May 2013 17:52:43 UTC