Re: [selectors] feedback

On Thu, Apr 17, 2014 at 1:41 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Apr 15, 2014 at 11:27 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Tue, Apr 15, 2014 at 3:53 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> On Tue, Apr 15, 2014 at 12:41 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>> 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.
>>>
>>> Except now you put the complexity (and bugs) on the dominant case.
>>
>> You keep asserting that there's complexity or bugs, but I'm having
>> trouble seeing it.  Can you elaborate?
>
> E.g., now the wording is that it's an element tree. If it was a pure
> element tree however, there could be no other nodes in that tree,
> meaning you cannot meaningfully define :empty or :blank.
>
>
>> The paragraph transforming the DOM to an element tree is just:
>>
>> # In a DOM document,
>> # the DOM is used as the <a>element tree</a>.
>> # Each DOM element is an element in the <a>element tree</a>,
>> # with the DOM element's namespace and local name as the type,
>> # and its ID, class list, attributes, and child elements
>> # as the ID, classes, attributes, and child elements in the <a>element tree</a>.
>> # The rest of the information in the DOM is also accessible
>> # as the arbitrary additional information in the <a>element tree</a>.
>>
>> That's as close to an identity transform as I can get.
>
> This does not seem clear to me with respect to the above remark. You'd
> have to interpret "arbitrary additional information" which is not a
> defined term, in creative ways.

It's defined as *arbitrary additional information*.  Plain english
words.  Anything additional your tree structure might have.  Because
it's arbitrary, that includes things like more types of nodes, etc.

Another reason I'm somewhat against switching to basing it on DOM is
that the tree model used by Selectors is *wider* than DOM.  It
contains pseudo-elements, for instance, which don't exist in DOM.  So
even if I switched over, I'd still be working off a somewhat abstract
tree with more information in it.

>> I think it's probably good to mention that default values may or may
>> not be matchable by Selectors.
>
> If you define matching against a tree, as you do, there's no need to
> mention this. DTDs may or may not influence the DOM, whether that
> happens is immaterial to the Selectors Standard.

I'm okay with simplifying this down to a note that some document
languages may allow attributes to have values by default.  Would that
work?

>>> In syntax you are not calling it in API hook. If e.g. syntax uses this
>>> algorithm (and I hope it can) it seems rather weird to name it an API
>>> hook.
>>
>> True, I call them "Parser Entry Points" or "Parser Algorithms" in
>> Syntax.  Are you just objecting to the naming of the section?
>
> Not objecting, but yes.

I plan to rewrite the parsing section into a Syntax-style parser, at
which point it would have the same structure as Syntax wrt "parse a
foo" algorithms.  Would that work?

~TJ

Received on Friday, 18 April 2014 18:10:30 UTC