Re: proposal for a new css combinator

On Jan 14, 2010, at 3:01 AM, Niels Matthijs wrote:

> Indeed.
>
> So I guess we have established that the proposed new combinator has no
> solid alternative in the existing css specifications?
>
> Apart from that, I want to stress the importance of the selector for
> easier (styled) content syndication or working on frameworks. This
> particular issue was a real pain when I was asked to develop a html/css
> framework for a company. My job was to provide html and css for
> components (think building blocks) so they could develop pages of their
> own.
>
> This framework actually featured some A->B and B->A nestings, which 
> were
> really horrible to style, especially since there needen't be a limit 
> for
> the level of nestings.
>
> For reference, check out the css of the yahoo grids, which clearly
> display a similar problem (unless they reworked it this last year or
> so).
>
> I checked the scoped css proposal again, but I don't think this would
> provide a good alternative solution.
>
> Conclusion: I still firmly believe in the need for the new combinator,
> especially with styling components independently in mind.
>
> (original proposal: In short, I'd like something between the space and
> child combinator. A combinator that allows for an (x) number of levels
> between parent and child, but stops at the first matching level it
> hits.)
>
> Greets,
> Niels Matthijs

What about allowing multiple limits? A combinator could let the depth 
of control be stated, or limited by the designer.

Just as an example, "h1 (1-2)h2" might select the first two levels of 
h2 elements under an h1 element.

Even more, the (an+b) syntax might allow each nth child (or other 
combinator) to be selected, so, for example, alternate headings could 
be different colors.

The use cases are the same as the thread which started this discussion, 
but now with even more control.

The question is: will implementation of this be too difficult or slow 
down other CSS actions?

Please be forgiving about the syntax, as I thought of the concept, but 
have not had a chance to consider what might work best with the current 
syntax. If anyone has a better suggestion for syntax, I would vote for 
it with no hesitation.

<James />

Received on Thursday, 14 January 2010 15:58:48 UTC