W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: [selectors4] Open issues

From: Simon Sapin <simon.sapin@exyr.org>
Date: Tue, 09 Apr 2013 09:35:27 +0200
Message-ID: <5163C4BF.90309@exyr.org>
To: www-style@w3.org
Le 09/04/2013 01:22, fantasai a ťcrit :
> ISSUE-316:http://www.w3.org/Style/CSS/Tracker/issues/316
>     Should ID selectors accept all HASH tokens instead of #ident only?
>     http://lists.w3.org/Archives/Public/www-style/2013Feb/0437.html
>     Pros: Merge quirks and non-quirks parsing.
>     Cons: We have interop on #ident.
>     See:http://lists.w3.org/Archives/Public/www-style/2013Feb/0449.html
>     Side-question: If we don't accept this, should this quirk be
>                    described in Selectors 4?

Should quirks be described: yes, always, IMO.

This case is a bit weird as it is the "non-quirks" parsing (#ident) that 
requires extra effort in both specs and implementations.

Iím in favor of doing the simpler thing (always parsing as HASH) if 
there is no web-compat risk, but I donít know how to assess that.

> ISSUE-318:https://www.w3.org/Style/CSS/Tracker/issues/318
>     Make specificity of :matches() / :not() depend on what was matched
>     http://lists.w3.org/Archives/Public/www-style/2010Sep/0534.html
>     Proposed resolution: Just do it.

This is good to have, but please not that it is somewhere between very 
hard (and costly), and impossible to do with cssselectís approach of 
"translating" Selectors to XPath.


But this approach has its limits even with Selectors Level 3. For 
example I donít know if these selectors even have an XPath 1.0 
equivalent. (If you do, please tell me!)

     .foo ~ :nth-child(3)

For this reason and others, I want WeasyPrint to move away from 
cssselect eventually anyway. So maybe translating to XPath should not be 
a concern at all.

> ISSUE-320:https://www.w3.org/Style/CSS/Tracker/issues/320
>     Profile :matches() / :not() for fast vs. complete implementation
>     People keep being confused about :matches() and :not()'s intention
>     to allow full complex selectors. The only reason they're not
>     allowed is perf, so we propose to just make two profiles for
>     Selectors and let things like Selectors API and PDF processors
>     implement the full version.

This feature is great, and having different profiles for different 
"contexts" is fine. (eg. stylesheets vs. Selectors API.) But Iím more 
reluctant to recommending different profiles for different UAs 
(interactive vs. non-interactive) in the same context (stylesheets.)

One great strength of using HTML/CSS for making PDF is that the same 
document can be viewed in a browser too. Not having eg. page-margin 
boxes when viewing on screen is fine, but selectors are more fundamental.

Simon Sapin
Received on Tuesday, 9 April 2013 07:36:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:10 UTC