W3C home > Mailing lists > Public > www-style@w3.org > March 2012

Re: [selectors4] Should the reference combinator really be a combinator?

From: L. David Baron <dbaron@dbaron.org>
Date: Thu, 8 Mar 2012 17:34:58 -0600
To: www-style@w3.org
Message-ID: <20120308233458.GA12331@pickering.dbaron.org>
On Wednesday 2012-03-07 14:57 -0800, fantasai wrote:
> On 03/07/2012 01:29 PM, Tab Atkins Jr. wrote:
> >
> >There are some other relationships that we could potentially express
> >as combinators but have instead chosen to represent as pseudoclasses,
> >such as :col(), but that's because the relationship there is very
> >specific to HTML (and other languages that have tables which are
> >represented in row-major form, plus childless column elements) and not
> >general-purpose.  The reference combinator is potentially
> >multi-purpose.
> Actually that's an interesting point. Hixie's original proposal for
> :column() used // as a combinator instead. Using a combinator there
> does avoid the branching possibilities present with :column(), and
> might therefore make more sense. What do you think?

So far, the reference combinator syntax in selectors4 doesn't make
much sense to me.  I prefer :column() as it is, and would rather see
the reference combinator use a functional pseudo-class (if we have
it at all).  (That said, as a pseudo-class it's clearer that it's
the backwards-reference pseudo class... which makes it clear how odd
a construct it is.)

(Also, if we're inventing reference and backward-reference selectors
for IDREFs in the markup, what happens when markup starts using
selectors?  Will we want reference and backward-reference selectors
to match a selector in the markup?)


𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Friday, 9 March 2012 02:13:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:13 UTC