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