Re: [selectors] feedback

On Mon, Aug 17, 2015 at 9:05 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 04/22/2014 09:16 AM, Tab Atkins Jr. wrote:
>>
>> On Tue, Apr 22, 2014 at 3:28 AM, Anne van Kesteren <annevk@annevk.nl>
>> wrote:
>>>
>>> On Fri, Apr 18, 2014 at 8:09 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>>> wrote:
>>>>
>>>>
>>>> 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.
>>>
>>>
>>> No, pseudo-elements operate on the node you matched against. They are
>>> a good reason for making things clearer. E.g. if you have html::before
>>> you first match until you find html and then there is some kind of
>>> check for its associated before structure, if any.
>>
>>
>> [Private discussion with Anne in #whatwg resulted in the two of us
>> agreeing that it should be okay to use the DOM, but augment it with
>> pseudo-elements for the purpose of Selectors.]
>
>
> I've just been reviewing the checkins for this, and I disagree with
> normatively basing Selectors on the DOM. Especially since you've done
> extra work in showing how it can map to other formats like JSON and
> graphs.
>
> Since undoing that dependency was just a few wording tweaks (almost
> all the references to the DOM were already informative, I just fixed
> up the two that weren't), I went ahead and did that.
>   https://hg.csswg.org/drafts/rev/18893eb99b33

This is all bad, unfortunately.

1. There's no definition of an "element tree" is.  The DOM defines
itself well, which makes it easy to refer to and just get things
defined for free.

2. Changing from "the DOM" to "an element tree" didn't actually
simplify anything in any way.  The fact that your edits consisted of
just changing the name used for it in a few places shows that using
the DOM (as a well-defined data structure) was fine.  We didn't gain
anything by switching to an undefined data structure.  There was no
impedance mismatch between models that we now get to avoid, or
anything of the sort.  The DOM satisfies the needs of Selectors
*precisely*.

3.  Why did you remove the typing information from the description of
the types of information an element can have?  That's *useful*, and
now that you're attempting to move away from the well-defined DOM to
an undefined "element tree" data structure, *absolutely necessary*.
It was just a nice reminder before, in case someone was unfamiliar
with the DOM, but now there's absolutely no text defining what a
"class" is.

> I also looked over the pseudo-class flags and pseudo-elements slots
> text you wrote... and
>   a) I don't see that it's adding anything useful, since we're very
>      clear in the pseudo-class and pseudo-element sections that they
>      can rely on information not in the document tree.
>   b) I'm pretty sure adding a "first-child" flag is ridiculous since
>      that's already encoded in the document tree.
>   c) I think it confuses things more than it clarifies. For example,
>      if my element has a "first-child" flag, does that mean it still
>      matches ":first-child" after I move it?
> So I think this part needs to be removed. (If there's some need that
> you think this section fulfills, let's talk about what that is and
> then write some prose that makes a bit more sense and doesn't confuse
> anyone...)

(a) I'm just trying to settle this on something well-defined that I
can refer to.  If talking about annotations on the element isn't the
right way, okay.
(b) Again, it's just fitting things into a single generic structure.
Yes, this information is represented structurally.  That doesn't mean
it can't be reflected in some property of the element itself as well.
(c) The presence of absence of the flag is defined by the pseudoclass.

~TJ

Received on Wednesday, 19 August 2015 21:29:10 UTC