W3C home > Mailing lists > Public > public-cssselfrags@w3.org > March 2012

Re: :target [via CSS Selectors as Fragment Identifiers Community Group]

From: Robin Berjon <robin@berjon.com>
Date: Thu, 8 Mar 2012 16:54:58 +0100
Cc: public-cssselfrags@w3.org
Message-Id: <1E8C4304-E97E-4B7C-B422-A8C1BC1F7898@berjon.com>
To: Eric A. Meyer <eric@meyerweb.com>
On Mar 8, 2012, at 15:46 , Eric A. Meyer wrote:
> At 11:46 +0100 3/8/12, Robin Berjon wrote:
>>>   My feeling is that the spec should explicitly permit structural pseudo-classes, :not, and :lang.
>> I can think of a few others, for instance :matches and :dir, plus all the nth-* and friends ones. I wonder if the :column ones could be useful for horizontal scrollers.
>   All the :nth-* selectors (and friends) are the structural pseudo-selectors I mentioned.

Oh, right, punctuation matters. I read "permit structural pseudo-classes :not and :lang" :) The fact that they aren't structural was tucked away to the side. Sigh.

>   I left out :matches, :dir(), and the column selectors because they're still in the CSS4 selectors Editor's Draft and may well change.  Basically I limited myself to CSS3 selectors for reasons of stability.

Fair enough.

>   This is why I prefer listing what's permitted, by the way.  It establishes a known baseline that can be expanded later, as opposed to a possibly expanding set of unexcluded things that might have to be further restricted.

So long as we stick to a must-ignore approach to versioning, I don't really care if we define the extensibility through whitelisting or blacklisting :)

>> Hmmm, how about linking to the first form element that's not :disabled? Or those that are :invalid?
>   I considered those, but they don't feel like reasonable use cases to me.  I'm certainly willing to be argued out of that view.

Two things. First, I see a use case, at the very least for :invalid. "Your application has been reviewed and was found to be in error, please make sure that you correct these fields: http://kafka.org/bureau/form2035.html#css(:invalid)".

Second, and more importantly, for most implementations (which is to say, those starting from an existing implementation) I would assume that the more things that are not like baseline CSS the more work it is. I reckon that removing only the obviously degenerate cases would make for a simpler spec overall.

Robin Berjon - http://berjon.com/ - @robinberjon

Coming up soon: I'm teaching a W3C online course on Mobile Web Apps
Received on Thursday, 8 March 2012 15:55:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:36:19 UTC