Re: [selectors4] Open issues

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.

http://pythonhosted.org/cssselect/

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!)

     *:first-of-type
     .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.

Cheers,
-- 
Simon Sapin

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