Add this blog to Del.icio.us, Digg or Furl | Create Watchlist for this blog

Proposal for a CSS ancestor grouping syntax

What we need

I am missing a syntax to apply a common ancestor to a set of rules. As far as I know, there’s no such concept in CSS selector syntax.

With the increasing usage of CSS definitions to style HTML markup, CSS files grow bigger and bigger. With this it’s getting more and more complex to find rules that apply the a special element and/or to have one’s code structured properly. When ie8 will support the more sophisticated locators like adjacent siblings or attribute selectors the locators and files likely will continue to grow.
Also CSS gets used in situations where you import content from several providers to display it inside one “mashup” site or (like in iGoogle or the Vista desktop) as “snippet”. In this situation one needs to separate the CSS rules of the different providers from each other and from the mashup’s home style.

Basically I want to grab remote content then wrap the grabbed sourcecode into a i.e. a <div id=”#GG”> and integrate that code together with it’s CSS in my site (or fridge display or whatever).

How it could work

The solution to this would be a ancestor grouping concept, i.e.:

ancestor "#GG" {
a { color: black; }
p { margin-top: 3em; }
}

This syntax should then expand to:

#GG a { color: black; }
#GG p { margin-top: 3em; }

Far more added value would be provided by the following construction:
ancestor "#GG" { @import(google.com/styles.css); }

or inside the HTML markup:
<link rel="StyleSheet" href="http://google.com/style.css" type="text/css" ancestor="#GG">

I think the goal should be clear now.

About a syntax for ancestor grouping

The curly braces from above are already taken for block definitions (see this W3C doc). And I don’t want to propose the introduction of a completely new syntax. So, what comes in handy is the @-syntax, actually the set of “media” rules.

I like to propose the new at-rule @ancestor.
This rule should conform to the existing CSS3 W3C-Grammar.

ancestor grouping within the stylesheet

@ancestor selector {
/* style rules descendant to selector go here */
}

ancestor grouping in documents

<link rel="StyleSheet" ancestor="selector" href="uri" type="text/css">

ancestor grouping together with the import at-rule

@import "uri" ancestor:selector;
This is not as beautiful as it could be because in the “@import A B” syntax, B is already predefined to be a media channel. So here we need the “ancestor:” workaround to stay in the “media” syntax-scheme.

In all proposals above, selector would be the selector from the referenced W3C grammar (selector : any+;).

Please send me comments

What do you think? Would this be a useful syntax extension to CSS?

Social Bookmarking:
Add to social bookmarking sites.
  • Digg
  • del.icio.us
  • Netvouz
  • DZone
  • MisterWong
  • Furl
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati

2 Responses to “Proposal for a CSS ancestor grouping syntax”

  1. Paris Holley Says:

    That is an interesting concept and I am up for anything that would help consolidate CSS files. Only issue I can see coming up is if that change to syntax would cause CSS rendering to become slower due to the additional parsing of rules by the browser. As rarely as CSS files are accessed, I don’t think that the CSS saved using that method would be beneficial to the user. There is also the issue with backwards compatibility, because this will surely not work on browsers that do not adapt this spec. Things to think about it…

  2. Greg Says:

    What I’d really like to see is being able to modify an element’s style if it contains another element, such as:

    tr < td < input[type=checkbox][checked] {
    background-color: grey;
    }

    The style would apply to the tr element that had a child td that had a child checkbox that was checked. So you could highlight rows if a checkbox is checked in that row. There would be other useful scenarios, but that’s the most obvious. It’s annoying to have to use javascript to accomplish that. Then again, it might be insanely difficult and/or processor-intensive to allow for that in browsers, I don’t know.

    (resubmitted because the server thought my markup was html and removed it)

Leave a Reply

I appreciate all comments that add substantial content to my articles. I do not like "link-building" comments and I do not like "congratulation" comments. Every such like data posted here will go to akismet hell.