W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [selectors] Reference Combinators removed?

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Mon, 8 Feb 2016 06:03:07 +0100
To: www-style@w3.org
Message-ID: <f42cf2b4-1de0-b7a9-9a1c-d183b08e172d@disruptive-innovations.com>
On 05/02/2016 11:11, James Craig wrote:

> The Reference Combinator was removed from the CSS4 selectors draft citing "lack of interest."
> Yes, all this can be done with JavaScript, but if one of the goals of CSS is reduction of reliance on scripting, the interest could remain.
> For example:
> /* CSS-only highlight of the Maps POI pin when hovering over a sidebar details list, and vice versa */
> .pin:hover /data-sidebaritem/ .sidebaritem  { /* highlight styles */ }
> .sidebaritem:hover /data-pin/ .pin { /* highlight styles */ }
> It looked like it would have also been especially useful for ARIA, which leverages IDREFs. 
> /* display the tab panel whose controlling tab is selected */
> .tab[aria-selected="true"] /aria-controls/ .tabpanel { display: block; }
> /* highlight the current autocomplete suggestion for a custom combobox */
> input /aria-activedescendant/ li { background: yellow; }

Wow, sincerely. I've always regretted we are unable to follow IDREFs
in CSS or even HTML. One of the very early times we faced that lack was
our inability to use inside the body element anchors reusing the
navigation links potentially present in the head element ( la <link
rel="next">) without duplicating the URL itself instead of just using
the <link>'s ID on the anchor. Granted, that was less stylistic than
your own examples, but still.

I'm not entirely sure at all a /.../ combinator is the best answer
here (although I have no counter-proposal in mind yet) but I can
definitely see why the feature is both useful and needed.

Things I like in your proposal:

  - the feature!
  - an ID/IDREF relationship can happen between two totally
    arbitrary elements in the tree, with no child or sibling
    relationship. A combinator makes then more sense than
    a "deferred" ID selector.

Things I dislike:

  - I don't find it very readable
  - we don't count combinators when the specifity of the selector
    is computed but here, your combinator is really an ID selector.
    This new combinator would force to change that.

Received on Monday, 8 February 2016 05:03:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC