I didn't understand you wanted me to say why I dislike XPath or what
are the reasons I don't use it.
I don't dislike it really. It could be as fast or faster than QSA and
I believe it to be an extremely powerful technology too.
However, adding to the reasons you and Austin have already given, at
that time (2007), I just believed XPath would have never become a
solid cross-browser Web API, QSA have had more chances especially for
it's simpler CSS like syntax and for having introduced the much wanted
"matchesSelector()" method.
The reasons to have a selector engine using querySelector API or XPath
should probably be driven by their final application. Both are good in
selecting groups of elements. Prototype devs have been using XPath in
their library since its appearance.
NWMatcher development has been driven by the idea of having an API
agnostic and cross-browser engine driven by a fast bottom-up DOM
"match()" method for event delegation. XPath was barely available at
that time and querySelector API was still a dream.
XPath was not suitable to build a "match()" method, we would still
have to go through the result set in search of the element.
NWMatcher solved this on all browsers, old or new and has been tested
to work on headless JVM engines (using env.js).
Element matching and event delegation brings higher performances and
resources savings.
NWMatcher has turned modular, it can work with or without QSA and have
HTML5 forms add-ons.
--
Diego
On Wed, Sep 7, 2011 at 6:55 PM, Nathan Sweet <nathanjsw...@gmail.com> wrote:
>>>I would attempt to use XPath entirely. If that is not an available option
>>> I would fall back on something else entirely and not attempt to mix parts of
>>> XPath with something unrelated.
> @Austin:
> Thanks Austin for your insight, I agree that if you can't go "whole-hog"
> with XPath you might as well not do anything. The problems I have with XPath
> are what you have already stated, and the fact that IE only allows it to be
> used for strict XML. Other than that, I think I agree with the sentiment
> that XPath is much better syntactically for DOM selection than CSS3
> selectors. Diego hasn't said this yet, but I know that the reason he
> advocates for strict adherence to CSS3 is because it will produce results
> very close to "querySelector", but the more I delve into building my engine
> the more I see that the philosophical argument for using CSS is weak and
> tenuous. I'm planning on building another engine soon that only works for
> the latest browsers only (a sort of high-end engine and library), and I
> think I will probably use XPath for that.
>>>Also, you can see the problem here:
>>><a class=link disabled>
> On Wed, Sep 7, 2011 at 8:54 AM, Diego Perini <diego.per...@gmail.com> wrote:
>>
>> Also, you can see the problem here:
>>
>> <a class=link disabled>
>>
>> without quoting is 'disabled' a second class name or a second attribute
>> name ?
>>
>> --
>> Diego
>>
>>
>> On Tue, Sep 6, 2011 at 5:48 PM, Nathan Sweet <nathanjsw...@gmail.com>
>> wrote:
>> >>>jQuery('[class="first last"]')
>> >>>
>> >>>works fine on
>> >>>
>> >>><li class="first last">
>> >
>> > I should amend my claim. Try it without quotes now. Why are quotes
>> > important
>> > in this case, and certainly the spec never says they are required or
>> > change
>> > the process in anyway, maybe this is where I'm going wrong. My engine
>> > works
>> > with and without quotes, but maybe it shouldn't?
>> >
>> > On Tue, Sep 6, 2011 at 8:19 AM, Cheney, Austin
>> > <austin.che...@travelocity.com> wrote:
>> >>
>> >> Values in CSS are space separated string literals. A single value
>> >> instance of a single property may contain spaces apart from other
>> >> single
>> >> values of the same property, however there must be a distinguishing
>> >> characteristic to prevent unexpected separating of your single value
>> >> instance that does contain spaces. This is accomplished with quotes.
>> >>
>> >> font-family: monospace, 'Courier New', 'Lucida Console';
>> >>
>> >> CSS, like HTML/XHTML accepts double and single characters equally so
>> >> long
>> >> as the terminating character of a given pair matches its opening
>> >> counterpart. If other engines are throwing an error at this behavior
>> >> then
>> >> they are performing improperly. If they are throwing errors at the
>> >> following example then they are perhaps less forgiving, but not
>> >> necessarily
>> >> acting improperly.
>> >>
>> >> font-family: monospace, Courier New, Lucida Console;
>> >>
>> >> In this second example there is a list of values, but what is the value
>> >> separator the space, the comma, or both? In this case it may be
>> >> preferable
>> >> to throw an error if this complicates interpretation during some
>> >> algorithmic
>> >> process. If this example is acceptable then your engine is more
>> >> forgiving
>> >> and will likely be more welcomed in the public space. You will have to
>> >> decide whether you want your tool to be simple and maintainable or
>> >> popular
>> >> and widely reused. You do not get both without significantly
>> >> increasing
>> >> your development costs.
>> >>
>> >> Thanks,
>> >> Austin Cheney, CISSP
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: jsmentors@googlegroups.com [mailto:jsmentors@googlegroups.com] On
>> >> Behalf Of nathanJsweet
>> >> Sent: Tuesday, September 06, 2011 10:02 AM
>> >> To: The JSMentors JavaScript Discussion Group
>> >> Subject: [JSMentors] spaces in attribute values
>> >>
>> >> Hey all,
>> >> I'm building my selector engine still (for those of you who remember
>> >> my ill-fated test suite), I'll be submitting it for code review
>> >> shortly, but I ran into an interesting issue that I was hoping someone
>> >> could resolve for me. Nowhere, that I can find, in the CSS spec does
>> >> it say that an attribute-value may not contain spaces in it using the
>> >> attribute selector. In fact, quite the opposite seems to be stated in
>> >> section 6.3 of the spec it says:
>> >>
>> >> "Attribute values must be CSS identifiers or strings."
>> >>
>> >> This is in explicit reference to the attribute selector, which would
>> >> lead me to believe that whitespace is certainly allowed. However, I
>> >> have noticed that in Sizzle and other selector engines, including the
>> >> native querySelector function, that whitespace throws an error; also,
>> >> not one of the examples in the attribute selector section of the CSS
>> >> spec has an example with whitespace. My question is: is there
>> >> something I'm missing?
>> >>
>> >> My selector engine can handle whitespace in this situation, and I see
>> >> no reason why it shouldn't, because it's not as though whitespace in
>> >> this situation can create syntactic confusion as a brace, "]",
>> >> delimits the whole selection.
>> >>
>> >> --
>> >> To view archived discussions from the original JSMentors Mailman list:
>> >> http://www.mail-archive.com/jsmentors@jsmentors.com/
>> >>
>> >> To search via a non-Google archive, visit here:
>> >> http://www.mail-archive.com/jsmentors@googlegroups.com/
>> >>
>> >> To unsubscribe from this group, send email to
>> >> jsmentors+unsubscr...@googlegroups.com
>> >>
>> >> --
>> >> To view archived discussions from the original JSMentors Mailman list:
>> >> http://www.mail-archive.com/jsmentors@jsmentors.com/
>> >>
>> >> To search via a non-Google archive, visit here:
>> >> http://www.mail-archive.com/jsmentors@googlegroups.com/
>> >>
>> >> To unsubscribe from this group, send email to
>> >> jsmentors+unsubscr...@googlegroups.com
>> >
>> > --
>> > To view archived discussions from the original JSMentors Mailman list:
>> > http://www.mail-archive.com/jsmentors@jsmentors.com/
>> >
>> > To search via a non-Google archive, visit here:
>> > http://www.mail-archive.com/jsmentors@googlegroups.com/
>> >
>> > To unsubscribe from this group, send email to
>> > jsmentors+unsubscr...@googlegroups.com
>> >
>>
>> --
>> To view archived discussions from the original JSMentors Mailman list:
>> http://www.mail-archive.com/jsmentors@jsmentors.com/
>>
>> To search via a non-Google archive, visit here:
>> http://www.mail-archive.com/jsmentors@googlegroups.com/
>>
>> To unsubscribe from this group, send email to
>> jsmentors+unsubscr...@googlegroups.com
>
> --
> To view archived discussions from the original JSMentors Mailman list:
> http://www.mail-archive.com/jsmentors@jsmentors.com/
>
> To search via a non-Google archive, visit here:
> http://www.mail-archive.com/jsmentors@googlegroups.com/
>
> To unsubscribe from this group, send email to
> jsmentors+unsubscr...@googlegroups.com
>
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
