move from xpath to css selectors for refs

[Pike]

We shouldn't use xpath to reference nodes, only evil specs do that. Let's go for CSS selectors instead.

[stasm]

I see two big problems with XPath:

• it allows the localizer to step up out of the context node, by specifying an upward axis such as ancestor or parent; we'd need to disable this somehow,
• it introduces a new syntax that the localizer should be familiar with, although arguably, for basic uses, the syntax is pretty straight-forward (e.g. element[1]).

OTOH, it's an established technology whose purpose is exactly what we want.

As far as CSS goes:

• querySelector is faster than XPath,
• safer, doesn't allow to step out of the context node,
• the syntax is a little bit more verbose, e.g. element:nth-child(1)
• ..but, in general, CSS is a pretty well-known technology, so I'd assume most of the localizers will be familiar with it

There's one big drawback to CSS regarding the syntax: it doesn't let you explicitly select children, as opposed to all descendants.

In XPath, you can do:

• element (short for ./element) which means all element children of the context node,
• //element which means all element descendants of the context node.

In CSS (or, more specifically, the Selectors API), you can only do:

• element which means all element descendants of the context node.

There is nothing like > element, because there is no way to reference the context node itself (which in XPath can be achieved by typing a single dot .).

This seems to be a pretty big limitation, especially when we assume that most of the uses of l10n-path will be very simple ones, targeting immediate children of the context node. Having a way to reference immediate children would be a plus.

The way Sizzle (and jQuery) solve this is to add a temporary ID on the context node and then run the query from its parent:

https://github.com/jquery/sizzle/blob/master/sizzle.js#L1202-1233

[fabi1cazenave]

I’d suggest keeping XPath (l10n-path) and implementing CSS selectors along (l10n-select). L20n could be very interesting in a document engineering approach, where people are very familiar with XML workflows.