W3C home > Mailing lists > Public > www-style@w3.org > March 2015

Re: element existence selector

From: Peter Krauss <ppkrauss@gmail.com>
Date: Sun, 1 Mar 2015 00:36:36 -0300
Message-ID: <CAHEREtuARBNxztg_z9F-D0Fv-Wbdq1u5XLxCT8k1tOBfa1LT1g@mail.gmail.com>
To: Brian Kardell <bkardell@gmail.com>
Cc: lists@novalistic.com, "www-style@w3.org" <www-style@w3.org>
First a general and summarized reply:

Only now I understand better what Tab Atkins said, sorry (!),
about "*fast profile*"... It is in fact a standard for CSS,

   http://www.w3.org/TR/selectors4/#fast-profile   (2013)
   http://dev.w3.org/csswg/selectors-4/#profiles   (2015)

so, we can put the discussion in this more objective terms:

1* the pseudo-selector* ":has()"*  not is a good candidate to *fast-profile*...
 (All agree with the W3C csswg 2015's draft??)

2* the suggestion of an *":hasID()" can be a good alternative to
the fast-profile*??

NOTE:  *fast-profile* is a standard, so, we MUST agree that the standard
defines a line separating fast from slow,
it is not a personal taste matter... We can imagine a standard threshold in
a standard benchmark-kit .

- - - - -
My position about item 1:
  I agree  that is not fast.
  Selector ":has()" is good for PrinceXML, but is not good for web-browsing
in a tablet.

My position about item 2:
   I understand that "e1:hasID(#id1) #id2" is faster than "e1:has(any1)
   I understand that the only-ID  reduce the risk of complexity in a
worst-case-set of selectors,
   and CSS-parsing implementations based in  *getElementById()*  is faster
than any others.
   So, an ":hasID()" pseudo-selector can be use without performance
reduction in a tablet.

- - - -
   As Henrik suggested when replying Tab, perhaps we need to "elaborate on
why it is slow"
   with worst-case examples and some benchmarking (ex. by jQuery).
   Some explanation about "why is slow" is here,
    "(...) The document can be traversed once, matching elements as you go,
        with no need to ever go backward to adjust a match

- - - -
Thanks Daniel for correct syntax, yes,
    html:has(#id1:hover) #id2

- - - -

I not agree that "(...) there's not really a functional difference (...)"
the little difference is what decides if a selector goes to the
*fast-profile* or not,
and getElementById() is the faster (!).


2015-02-27 18:16 GMT-03:00 Brian Kardell <bkardell@gmail.com>:

> On Fri, Feb 27, 2015 at 4:04 PM, Daniel Tan <lists@novalistic.com> wrote:
>> On 2/28/2015 1:30 AM, Peter Krauss wrote:
>>> Thanks Tab, now you find exacly what I was looking for (!)...
>>> Well, let's confirm it, with another words,
>>>   1* you are  referring to the  "4.4. The Relational Pseudo-class
>>> /:has()/ <http://dev.w3.org/csswg/selectors-4/#relational>";
>>>   2* what I need is to use /:has()/ as a root's condition, like
>>> /html:has(#id1)/;
>>>   3* the samantic of "/a:has(b) c/" is "if /b/ then selects /c/";
>>>   4* the semantic of "/html:has(#id1):hover #id2/" is "when
>>> on-mouse-over /#id1/, selects /#id2/";
>> Syntactically, the correct way of writing such a selector would be
>> html:has(#id1:hover) #id2
>> /* or :root:has(... */
>>  is it? assuming we agree until here, about this 4 assertions...
>>> And perhaps I understand  when you say "(...) too slow, and makes
>>> invalidating styles too difficult",
>>> but now imagine a more specific selector, a /:has()/ that can be used
>>> only with IDs,
>>> */:hasID()/ *
>>> so, why  "/html:hasID(#id1):hover #id2/"  will be slow? What the
>>> validation problem?
>>> Perhaps this ID constraints "put in rails" my suggestion:
>>> you see some parsing or validation problem with this hypothetical
>>> /:hasID()/?
>> Based on the explanation Boris has now given, I don't see how this will
>> be any better than :has() except that it's restricted to an ID, which by
>> itself has very little performance impact if at all.
>> What I can tell, as an author, is that this basically forces you to use
>> IDs, so you will only be able to use it with unique elements in a
>> conforming document. If you only have one (or two) elements that you'll be
>> using this with, I guess it's fine, but if you have several related
>> elements that you would normally otherwise select with a class, things will
>> get very unwieldy from there.
>> --
>> Daniel Tan
>> <http://NOVALISTIC.com>
> Actually, there's not really a functional difference between a class and
> an ID other than some minor internal details and the fact that
> getElementById will automatically get you the first one in document order,
> so an ID really wouldn't make much difference here on either the author or
> performance end.
> --
> Brian Kardell :: @briankardell :: hitchjs.com
Received on Sunday, 1 March 2015 03:37:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:52 UTC