[selectors4] Open issues

There's a good handful of open issues on Selectors 4 that need WG
discussion to resolve. They are:

ISSUE-223: http://www.w3.org/Style/CSS/Tracker/issues/223
   Should Selectors adopt MQ-style invalidation (per comma-separated group)?

   Proposed resolution: No change, based on glazou's response

ISSUE-316: http://www.w3.org/Style/CSS/Tracker/issues/316
   Should ID selectors accept all HASH tokens instead of #ident only?

   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?

ISSUE-317: http://www.w3.org/Style/CSS/Tracker/issues/317
   Allow child-index pseudos to select unparented elements

   * allow them to select unparented elements that have a "virtual"
     or non-element parent, e.g. for DocumentFragments
   * allow them to select unparented elements. This includes the root.

ISSUE-318: https://www.w3.org/Style/CSS/Tracker/issues/318
   Make specificity of :matches() / :not() depend on what was matched

   Proposed resolution: Just do it.

ISSUE-319: https://www.w3.org/Style/CSS/Tracker/issues/319
   Need usable selector for empty elements

   1. Redefine :empty to match elements that contain only whitespace
      1.1 Add :void if the old definition has some real use case
   2. Define a new pseudo-class that matches such elements

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.


Received on Monday, 8 April 2013 23:22:49 UTC