W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: XPath and find/findAll methods

From: Robin Berjon <robin@berjon.com>
Date: Wed, 23 Nov 2011 11:13:21 +0100
Cc: public-webapps WG <public-webapps@w3.org>, "Martin Kadlec (BS-Harou)" <bs-harou@myopera.com>
Message-Id: <0E9C13E5-43C3-4958-9D24-1DE201DDDCD2@berjon.com>
To: Tab Atkins Jr. <jackalmage@gmail.com>
On Nov 22, 2011, at 22:24 , Tab Atkins Jr. wrote:
> On Tue, Nov 22, 2011 at 12:02 PM, Robin Berjon <robin@berjon.com> wrote:
>> Developers will need to learn new syntax for new features anyway, and when you don't need the new stuff you can still use CSS anyway. I don't see how this is an argument.
> 
> Come on, Robin, you're being unreasonable.

I don't know if I'm being unreasonable, I'm just speaking from experience. I started knowing Selectors, I needed more for a project, I picked up XPath. It wasn't hard. And I certainly don't think that I'm smarter than other web hackers

Besides... HAML. Stylus. Jade. jQuery.tmpl. Markdown (with flavours). CoffeeScript. Sass. YAML. LESS. SCSS. Objective-J. Mustache. Handlebars. TT.js. eco. Textile. And that's just the ones I can think of off the top of my head.

It sometimes seems that in contemporary web development, you can take an arbitrary string and make it do what you need it to simply by picking the right processor for it. So, no, I don't buy the syntax argument.

> Look at the platform as a whole.  There is *no way* to justify having
> two completely separate mechanisms for accomplishing the exact same
> thing unless you're planning on replacing one with the other.

I think that that's essentially where you're wrong. I'm happy to use Selectors and I'm happy to use XPath in the very same way that I'm happy to use file globs and I'm happy to use regular expressions. It's a good thing that I don't have to use globs to extract URIs from text and it's a good thing that I can write foo.* rather than /foo\.\w+/.

Trying to cram the expressiveness of XPath into Selectors will just burn cycles to create a monster. There certainly is room to add a few things to Selectors, and I very much welcome those additions. But when you start talking about "Selectors for Batch Processors" you're really scaring me. I think that you're underestimating the differences in expressive power of the two, which in turn is leading you to propose that we beef up a bicycle so that it can also be a car, simply because they're both vehicles. We have different types of vehicles for a reason.

> It's about producing the best API for authors and the
> future, because I intend to remain a webdev for many years.

Well, so do I. That's why I need Selectors not to become a monster, and need efficient ways of making more advanced queries. It's not as if it were a major undertaking either  we basically need a bit of interface polish.

> (Also: "CSS WG has a deeply held grudge" and "the 'battles' you so
> fondly mention"?  You're projecting, Robin.  I expressed nothing of
> the sort, and *feel* nothing of the sort.

Hey man, you used "battle", "won", "rivals" in 4/5 of the emails you posted to this thread  don't blame me for not reading your feeling from this far away :)

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 23 November 2011 10:13:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT