W3C home > Mailing lists > Public > public-webapi@w3.org > April 2008

Re: [SelectorsAPI] Selector detection needed?

From: Francois Remy <fremycompany@yahoo.fr>
Date: Sun, 20 Apr 2008 16:43:50 +0200
Message-ID: <77A166B0330544F08EA4CF6675922882@FremyCompany1>
To: <html@nczonline.net>, <bzbarsky@MIT.EDU>
Cc: "CSS 3 W3C Group" <www-style@w3.org>, "DOM Implementation W3C Group" <public-webapi@w3.org>

I think the best way to test UA features should to use (and improve)

Current hasFeature signature :
    hasFeature (feature:String, version:Number) : Boolean

Proposed hasFeature signature :
    hasFeature (feature:String, [version:Number]) : Boolean
    hasFeature (mainFeature:String, subFeature:String, [version:Number]) :

Samples :

   "hasFeature", 1 (current version of hasFeature)
   "hasFeature", 2 (improved hasFeature version)

    "CSS-Selector-", "+"

    "CSS-Pseudo", ":hover", 1
    "CSS-Pseudo", ":hover", 2
    "CSS-Pseudo", ":after"
    "CSS-Pseudo", "::after"

    "CSS-Property", "border"
    "CSS-Property", "content"

    "CSS-Value", "border:initial"
    "CSS-Value", "width:fit-content"

    "HTML-Tag", "MARQUEE",
    "HTML-Attribute", "MARQUEE@scrollAmount",



In response to :
    > The try-catch statement does carry overhead with it in terms of an
    > scope. If you're doing a bunch of queries and you need to surround
each of
    > them with a try-catch, it can affect performance (see
    > http://dev.opera.com/articles/view/efficient-javascript/?page=2).

    What this is saying is that if you have to run the catch clause (that
is, an
    exception was thrown) you get a small performance hit.  If you don't
throw, no hit.

    But in this case, that means that you're going to use a fallback
    implementation anyway, so you're getting a big performance hit no matter
    I'd be interested in how the overhead of the catch compares to that.  My
    instinct is that it's pretty insignificant.

    It might be that the article isn't quite clear, so there is a hit even
    nothing is thrown.  Again, hard data would be much appreciated.  Safari
has a
    querySelector implementation that could be used to test this, for
    Alternately, I have a Gecko with such support here and would be happy to
run a
    timing test if you come up with one.

    > Errors should be thrown only for things that aren't easily detectable
    > beforehand.

    I'm not sure I agree.  There are plenty of DOM operations where it would
be easy
    to add an API to check whether the operation is allowed before
performing it...
    and they all throw if the operation is not allowed.

    Given that querySelector would continue throwing on unsupported
    whether the pre-check is added or not, how is this situation different?

    > Not supporting a selector is not the same as a syntax error.

    Sure it is, from the point of view of a UA.  A CSS parser +
    really can't tell the two apart.

    > Again, you're focusing in on the specific solution.

    No.  I'm asking for two things:

    1)  Concrete use cases.  I have yet to see a decent one suggested.
    2)  Proposed solutions to solve those use cases.

    These are somewhat orthogonal.  (1) is more important.

    > The DOM has tons of different ways to determine what is
    > implemented and possible to use.

    Most of them highly unreliable.  And as I said before, it also has
plenty of
    cases where such things are not available and operations either succeed
or throw
    and let the caller deal.

    > An unsupported selector doesn't necessarily break CSS syntax. Consider
    > :after and :hover match the same pattern.

    The "CSS syntax" (as opposed to the grammar) is something that doesn't
    There is a "CSS2.1 syntax", which is the set of all things allowed in
CSS 2.1.
    There is the "Selectors syntax" which is the set of all things allowed
in the
    Selectors CSS3 module.  But a parser that only supports part of the
    doesn't have any idea whether the other things are "syntax errors" or
just CSS
    it happens to not support.  Nor is introducing such a dichotomy really

    An example.  Is "a::before:hover" a syntax error?  Or an unsupported
    How do you know?

    > A support status page could be useful, but I'm thinking more

    Yes, practical is good.

    > How can a JavaScript library that currently supports CSS querying
determine if it
    > should use its implementation or the browser one?

    I'd be interested in some feedback from actual JavaScript library
authors on
    what they would find useful here, for what it's worth.

    > Again, writing a try-catch around every call adds performance overhead

    As I said, I'd love data here, especially as compared to proposals to
    selector support.  For example, is it more overhead than parsing the
    twice on every call (once to test support, once to run the query)?

    > With some way to detect
    > the capabilities of the query engine, a JS library could determine up
    > whether or not to use the browser-native version.

    If it's only doing the detection once up front, it doesn't really matter
    the detection is expensive...

    > var goodEnough = document.querySelectorSupport(":hover", ":not",
    > "tagname", "#id");
    > In this paradigm, you can pass in a string representing each selector
    > test, with special ones for single class names (.a), multiple (.a.b,
    > etc.), tag names (tagname), IDs (#id).

    Maybe I'm missing something... how would this work in practice?
Wouldn't this
    require the JS library to parse every selector it needs to query to see
    it's in its precomputed "safe" set?  My gut feeling is that this is more
    overhead than a try/catch.  Of course actual data would be welcome.

    I should note that your ":not" example above seems to fail my
":not(.a.b)" test,
    by the way.

Received on Sunday, 20 April 2008 14:44:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC