Re: element existence selector

Hello,
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)
any2"
   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,
        http://stackoverflow.com/q/1817792/287948
    "(...) 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

- - - -
Brian,

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 (!).




krauss



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
>> NOVALISTIC
>> <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
>