W3C home > Mailing lists > Public > public-css-archive@w3.org > January 2017

Re: [csswg-drafts] [selectors] some inconsistent concepts and descriptions

From: SelenIT via GitHub <sysbot+gh@w3.org>
Date: Tue, 24 Jan 2017 10:49:11 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-274770005-1485254949-sysbot+gh@w3.org>
I agree that order of the simple selectors in the compound selector is
 sometimes meaningful and the grammar should reflect it. For example, 
is `[href]a` (instead of more usual `a[href]`) a valid selector? Maybe
 the grammar should be clear that type selector is a rather 'special' 
sort of a simple selector and, if present, should always come first in
 the compound selector (and, obviuosly, be the only one)?

Does it make sense to change the definition of the compound selector 
from `<simple-selector>+` to something like this?
```
<compound-selector> = <type-selector>
                    [ <id-selector> | <class-selector> | 
<attribute-selector> |
                      <pseudo-class-selector> | 
<pseudo-element-selector> ]*
                    |
                    [ <id-selector> | <class-selector> | 
<attribute-selector> |
                      <pseudo-class-selector> | 
<pseudo-element-selector> ]+
```

And one more question about pseudo elements: the spec currently 
explicitly allows 
[pseudo-classing](https://drafts.csswg.org/selectors/#pseudo-element-states)
 for _some_ pseudo-elements (and this is widely supported in browsers,
 e.g. in form of `::selection:window-inactive` or 
`::-moz-range-track:hover`), but does it prohibit pseudo-elements with
 classes (e.g. `::after.test`)? The existing grammar seems to allow 
it, and at least Safari 9+ (unlike other browsers) considers such 
selectors as valid ([codepen 
example](http://codepen.io/SelenIT/pen/OXVrRv)). But do these 
selectors make any sense?

-- 
GitHub Notification of comment by SelenIT
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/386#issuecomment-274770005 
using your GitHub account
Received on Tuesday, 24 January 2017 10:49:17 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:37 UTC