Re: [selectors] feedback

On Thu, Apr 10, 2014 at 7:18 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> Reviewing http://dev.w3.org/csswg/selectors/ ...

Thanks for the detailed review!

> * Section two writes "Selector" whereas the remaining text writes it "selector".

Looks like just a typo.  Fixed.

> * The Selectors API is obsolete. Probably best to avoid referencing it.

Removed.

> * In section 3.1 the structure of selectors is defined. It seems
> whitespace should not be mentioned there (at best in a note) as it is
> syntax and not structure. Similarly, defining a combinator as
> punctuation in that section seems somewhat sketchy. Are you defining
> structure or syntax?

Fixed.

> * For "evaluating a selector" when would you want to provide an
> explicit "selector match list" rather than a "selector match root"? It
> seems the typical scenario would be to match against a tree of sorts.

Evaluating a list of compound selectors against a particular set of
elements, such as in <content select>.

> Providing all the elements as input seems rather odd.

In what way?  All the elements are possible outputs.

> * You don't define the term "context".

That's because I'm not sure how to define it.  :/  Any suggestions?

CSS in a Document is one context.  Individual functions that use
selectors are more contexts.  CSS in a ShadowRoot is another context.

> * Instead of "for HTML" in 3.2, you want to see, "for DOM" or some
> such as that would cover HTML, XML, arbitrary documents, etc. HTML and
> XML are syntax, and selectors don't operate on syntax.

Done.

> * In 3.3 you renamed "selector match list" to "element tree"?

Different sections written at different times.  I've moved it to
"selector match list".

> * Again, it's not that in HTML the DOM is used, the DOM is simply
> used.

Fixed.

> You don't mention namespace here. Pretty sure matching is
> against local name and not tag name.

Fixed.  (Sorry, the minutia of what precisely a "tag name" is escaped me.)

> It's not entirely clear to me why
> selectors does not directly operate on the DOM and we need this level
> in between. In other contexts it seems people can define a mapping to
> the DOM as needed.

It does directly operate on the DOM, when the DOM is what's being
matched against.

For anything else, it seems like mapping to the DOM rather than
mapping to CSS's simpler structure is just requiring more complexity
than is really needed.

> Part of why this is problematic is that you do not
> define your elements very well yet assume in other sections that terms
> such as "sibling" make sense.

How much definition needs to be given for a tree?  (Serious question;
it seems like a generic computing term that we don't need to define,
any more than we need to define "byte" in Syntax.)

> * "Default attribute values in DTDs" is this actually implemented
> anywhere? I would prefer we make no requirements on this one way or
> another. Seems like something we might want to simplify down the line.

I think the section already makes no requirements.  All the normative
stuff is a MAY.

What do you mean by "simplify"?

> * Actually, the way classes and IDs are proposed to work is with a
> generic class="" and id="" attribute defined by DOM. HTML, SVG,
> MathML, xml:id, are all irrelevant.

Has that been accepted?  I'm happy to edit Selectors if that's
definitely happening.

> * Can we settle on the name :any-link so Gecko can remove the prefix?

I'll bring it up on the call this week.

> * :hover should mention that the specifics of hit testing are not
> defined (but should be at some point). Suggesting it's as simple as a
> box the mouse is hovering over is misleading.

Added a note.

> * Same comment for :active, :dag, and :drop.

Put the note in the intro to the section.

> * It seems like :current could use some elaboration. E.g. that its
> behavior depends entirely upon context that is not provided by this
> specification. Same for :past and :future.

That's already defined, no?

# CSS does not define this timeline;
# the host language must do so.
# If there is no timeline defined for an element,
# these pseudo-classes must not match the element.

> * In :root it has "In HTML 4" which seems bad. HTML4 is dead and with
> scripting that's not true. You probably want to clarify it only
> matches the root element of Document objects.

I've rephrased the examples to talk about DOM.

> * DOM no longer has CDATA nodes. Seems inappropriate for :empty to mention them.

Sure.

> * Why is parsing a selector an API hook?

It seems similar to the structure exposed by Syntax for its parsing algos?

> Are other parts of CSS not
> using those parsers?

Not directly, not yet.  This'll be fixed.

~TJ

Received on Monday, 14 April 2014 23:42:18 UTC