CSS Challenge 8

A scenario that I often stumble upon is the following case:

<a><b/></a>
<a><c/></a>

…and depending on whether <a> contains a <b> or a <c> I would like to style it differently. Can this be achieved using CSS3 selectors? If so how?

If I had a G-Mail account and had some free G-Mail accounts I would give them away to anyone who knows the answer ;-)

  • Martijn

    Afaik, this is not possible.
    There was some discussion with :matches pseudo-class. But that was just some discussion. Nothing has been formalised afaik.
    So in this case I guess it would be a:matches(>b) then.

    There was some time ago the :contains() pseudo-class in the css draft, but they removed that. It allowed styling based on the text some elements contain.

    You don’t have a Gmail account? Do you want one? I think I still have one.

  • http://erik.eae.net Erik Arvidsson

    I was almost sure that the answer would be that it is not possible but then again I’m still hoping some smart person with superior CSS knowledge could come up with some mysterious way to achieve this.

    Gmail: If you have extra accounts that you don’t know what to do with I’ll be glad to get one. If someone really needs it give it to them instead. I’ll manage without one.

  • http://hzr.dzygn.com hzr

    Erik, check your mail.

  • http://youngpup.net/ Aaron Boodman

    One again, I have to point out that this is already possible with XPath, along with everything “new” in CSS1, 2, and 3.

    Why they continue to feel the need to reinvent a node selection syntax is beyond me.

  • http://erik.eae.net Erik Arvidsson

    Aaron: I understand your point. From a users perspective XPath would work fine… maybe even better than CSS selectors. But from the point of an implemantator XPath is not as efficient as CSS selectors. XPath finds one ore more nodes starting from a context node. CSS matches a node to a pattern. In most cases it is trivial to see that an XPath matches a node but is that always the case… I’m trying to come up with an XPath expression that would be very inefficient to do matching on… I could not come up with a good example here. If one sticks to LocationPath and does not use functions it should be easy to do the inverse computation needed to tell whether a path matches an element.

    Since CSS existed long before XPath it is too bad that the XPath people did not look at CSS and made XPath a superset of CSS selectors.

  • YuppY

    Martijn: :contains() pseudo-class is in css3 draft (http://www.w3.org/TR/css3-selectors/#content-selectors), but it selects only by textual content. However, if hidden generated content considered textual, this solution can work:

    a > b::before { content: “$b-element$”; display: none }
    a > c::before { content: “$c-element$”; display: none }
    a:contains(“$b-element$”) { … }
    a:contains(“$c-element$”) { … }

    And the best solution would be parent combinator:

    b < a { … }
    c < a { … }

    But I doubt that something similar will become css standart…

  • http://www.ventesol.org/forum/ assa

    I’m a little surprised that such a situation would be desirable. Though it looks beatiful as a simply piece of code, is use of classes really so difficult? And isn’t JS a good option for setting up such rules for variables where CSS is unable to?

  • http://erik.eae.net Erik Arvidsson

    assa: Classes are not sufficient… Here is pretty good example where this would be useful.

    <item>
       <title xlink:href=”someuri” xlink:type=”simple”>Title</title>
       <p>Some text</p>
    </item>

    item, title, p {
       display: block;
    }

    title {
       font-size: 150%;
       margin: 1em;
    }

    p {
       margin: 1em;
    }

    title:visited < item {
       opacity: 0.5;
    }