Re: [selectors4] Editorial comments on the 2013-04-17 ED

On Sun, Apr 21, 2013 at 8:04 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
> §3.1. should add "selector list" (as in §4.1) to the terminology.
>
> §3.2. should mention that the subject indicator is only allowed in the
> complete profile.

Done.

> §3.3 says "Some host applications may choose to scope selectors to a
> particular subtree of the document." It should also say that CSS stylesheets
> are typically not scoped, and what happens in this case. §7.5 already
> defines that :scope defaults to being equivalent to :root when no contextual
> reference element set is given, but it would help to remind that in §3.3.

I'm not sure your first request is necessary - if you don't mention
that something is scoped, it's not, by default.

I'm also not sure we want to repeat the details of the :scope
pseudoclass here, given that it's defined quite clearly in the
(linked) :scope section.

> §3.4 says "The pseudo-class concept is introduced to permit selection based
> on information that lies outside of the document tree or that cannot be
> expressed using the other simple selectors." This a bit misleading in the
> case of the 15 tree-structural pseudo-classes defined in this spec. The
> general syntax of pseudo-classes is an extension mechanisms: it allows
> adding new tests/conditions by naming them instead of inventing
> punctuation-based syntax. Only some of these tests are based on information
> that lies outside of the document tree.

Clarified: "or that can be difficult or impossible to express using
the other simple selectors."

> Same section: "A pseudo-class always consists of a "colon" (:) followed by
> the name of the pseudo-class and, for functional pseudo-classes, by a value
> between parentheses." This seems imply that functional pseudos can only have
> one component value (as defined in Syntax and Values & Units) between
> parentheses, but really it could be any list of nested component values.
> Perhaps refer to Syntax for the concept of "a function"?

Clarified.

> "Pseudo-class names are case-insensitive." should precise ASCII
> case-insensitive with a link to §3.6.

Done.

> §3.5 should say that pseudo-elements are also ASCII case-insensitive,
> although this is implied by §3.6.

Done.

> §3.6 should have an exhaustive list (and explicitly marked as such) of
> "parts that are not under the control of Selectors". If the rest of that
> paragraph is that list, just clarify that it is exhaustive.

Made it less informal.

> Although almost out of scope, it could be useful to link in a note to the
> relevant section of HTML: (the existence of which I learned pretty late in
> my time implementing WeasyPrint)
> http://www.whatwg.org/specs/web-apps/current-work/multipage/selectors.html#case-sensitivity

Done.

> "Characters in Selectors can be escaped with a backslash according to the
> same escaping rules as CSS. [CSS21]." Perhaps add a reminder that escaping
> "cancels the meaning of special characters". For example, #foo~a contains a
> combinator, but #foo\~a does not.

Done.

> §4.2 should clarify: "In the fast Selectors profile, only compound selectors
> are allowed within :matches(): combinators are not allowed." But
> comma-separated lists of compound selectors are allowed, right? (Same
> comment for :not() in §4.3)

Done.

> "Default namespace declarations do not affect the subject of any selector
> within a matches-any pseudo-class unless the argument is an explicit
> universal selector or a type selector." I only understood this based on the
> examples. Suggested rewording: "Default namespace declarations do not affect
> any implied universal selector within a matches-any pseudo-class."

Done.

> §6.1 "[att] Represents an element with the att attribute, whatever the value
> of the attribute." I’m nitpicking, but I would add "even if that value is
> the empty string."

When is the empty string not a value?

> §6.6 Paraphrased: ".foo is the same as [class~=foo] in HTML but has higher
> specificity." Unless I missed something this is not the case: they have the
> same specificity.

Deleted.

> Same section: "If an element has multiple class attributes, …" That never
> happens with HTML or XML, right? (The parser only keeps one.) Perhaps the
> note should say that, and §6.1 and §6.2 should have similar notes.

Isn't that already implied by the end of that paragraph, which states
that we have no idea how such a situation could arise?

> §6.7 "an CSS identifiers", shouldn’t that be "a CSS identifier"? (Remove on
> N and one S.)

Done.

> "Selectors does not specify how a UA knows the ID-typed attribute of an
> element. The UA may, e.g., read a document's DTD, have the information
> hard-coded or ask the user." Just say that this is defined by the document
> language? There is already a note about XML and DTDs.

Clarified.

> §7, §8, §10, §11 Although almost out of scope, it could be useful to link in
> a note to the relevant section of HTML: (the existence of which I learned
> pretty late in my time implementing WeasyPrint)
> http://www.whatwg.org/specs/web-apps/current-work/multipage/selectors.html#pseudo-classes

I've added references to most of them.  Some I couldn't figure out how
to do without sounding clumsy or just verbatim repeating HTML's
conditions, so I left them out.

> §7.1 ":any-link matches an element if the element would match :link or
> :visited." That’s a great example for :matches().

Added.

> §7.4 Clarify that :target matches not the target on anything (such as links
> that exist in the document), but the target on of the document’s own URL.
> Note that the document language determines which element is the target of a
> given fragment identifier. The relevant HTML section is:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-indicated-part-of-the-document

Done.

> §9 Are time-dimensional pseudo-classes appropriates for slides, only one of
> which is shown at a time?

Assuming that your document language assigns a time-position to them, sure!

> §9.1 "The :current pseudo-class represents the innermost element, or
> ancestor of an element, that is currently being displayed." I don’t
> understand "innermost or ancestor".

I don't understand "innermost" either.  Removed.

> §10.2 The section has several occurrences of both "language range" and
> "language identifier". Are they the same thing? Shouldn’t only one term be
> used?

Yes, they're the same.  I've changed to "language range" consistently.

> §11.2.1 Perhaps add a note: Even in HTML, input[type=checkbox]:checked may
> not be the same as input[type=checkbox][checked]: the attribute only
> determines the initial state: it is not change when the state is toggled eg.
> through user interaction.

I changed it to refer to "checked checkboxes", rather than an explicit
reference to the element.

> §12.3 I read the linked section of css3-text, but I’m not sure exactly which
> characters are "subject to whitespace processing". It especially should not
> depend on the results of the cascade in general or the value of the
> 'white-space' property in particular. Is it doable to have an exhaustive
> list of characters in Selectors?

In section 4.1 of Text, the first paragraph says "White space
processing affects only ...".  That's what we're referring to.

> §12.4.2 "If an "n" token is provided (the first clause in the grammar)" N is
> the second clause.

No it's not?

> "If an "n" token is not provided (the second clause in the grammar), the
> integer gives the offset, and the step defaults to 1." The handling of 'odd'
> and 'even' is missing in this sentence.

Those keywords are defined in the previous section, but I agree that
it looks like this section should be exhaustive.  Added.

> §12.6 "among elements of the same type (tagname)" I’m not sure if tagname
> could be interpreted as as local name. Expanded name could be used instead.

I don't want to obfuscate the meaning with XML stuff, so instead I've
just linked it to the type selector section, which goes into full
detail.

> §15 This section defines the specificity of a *complex selector*. In a
> selector list, each comma-separated complex selector has its own
> specificity.
>
> "ignore the universal selector." Shouldn’t that be plural? Each compound
> selectors in a complex selector can have a (possibly implied) universal
> selector.

This phrasing is singular because it's referring to the universal
selector generally, not some specific universal selector instance in
the selector.

~TJ and fantasai

Received on Wednesday, 24 April 2013 22:33:44 UTC