Re: XPath as CSS-selectors?

Hello Asbjørn, Chris, Ian,
Dear list members,
Dear CSS WG,

On Wednesday, 18th of June 2003 14:05, Asbjørn Ulsberg wrote:
> I've been reading the CSS3 specification the last days, and
> particularly about the new additions to the CSS-selectors.
> What I notice, clearer than with CSS1 and 2, is that the CSS-
> selectors just is a way of selecting nodes, exactly like
> XPath.
as Ian already said, CSS selectors were before XPath.
On the other hand, XPath /to me/ seems a bit more mature and elaborate.
Still, XPaths aren't exactly like CSS Selectors, they're just similar to CSS 
Selectors.
Which is not an argument against your argumentation, Asbjørn, just a 
conclusion and an indicator for even more odds.

> In the former versions of CSS I can understand the need of
> creating a syntax for selecting nodes, as there weren't many
> alternatives in those days. Now, however, there are alternatives.
> We have XPath.
As already stated, XPath is missing some of CSS's selectors.
And, which I must strictly denote, CSS is missing much of XPath's 
capabilities.

> I can't really see why XPath can't be incorporated into CSS
> as an alternative, or instead of, CSS-selectors. Why do we need
> different syntaxes for doing the same thing?
>
> A way of doing this, could be:
>
>   xpath(/html/body/p) {
>     color: blue;
>   }
>
> Or a more generic one:
>
>   select('xpath', '/html/body/p') {
>     color: blue;
>   }
>
> "select()" returns a set of nodes, and can be viewed as any other
> CSS selector, like:
>
>   html>body>p {
>     color: blue;
>   }
I very much like these examples.
I like the idea.
I absolutely share Asbjørn's Opinion.

What about:
- giving CSS a seperate selector language, CSS Selectors (which as far as I 
know already is a seperate module and could be treated as seperate language)? 
(Okay, just say CSS Selectors are a language and you're done ;-)
- making CSS Selectors the default selector language? (Again, just say it and 
you're done)
- adding a syntax for alternate selector languages like XPath?

> Many would say that "XPath si too heavy for CSS" and such, but
> why settle for the topping when you can have the whole cake?
> There are many arguments for incorporating XPath in CSS;
>
>   1. The language is already well defined and standardized.
Applies to both, CSS and XPath.

>   2. It is widely used.
Applies to both, CSS and XPath.

>   3. It is isolated as a stand-alone language, outside of any
>      other standard (which CSS-selectors isn't). XPath can,
>      without any major problems, be used to select nodes in
>      an Enamel[1] document.
>
>      This isolation makes the language more focused on it's
>      task, which is to select nodes.
True. But this also gives a drawback. Because of that, XPath cannot select 
some parts of the document XPath wasn't designed to and only CSS Selectors 
can, e.g. :hover or :active.

>   4. It is imho more powerful than CSS-selectors.
True, though it lacks some of the features CSS Selectors have, like :hover, 
:active, :first-line, :visited, :link etc..

Selectors like ul[count(li)>3 and li[2]/@class='important'] currently only are 
possible with XPath, are they?
They could be useful:

<table>
	<tr><th>Quarter</th><th>Revenue</th><th>Expenses</th><th>Profit</th></tr>
	<tr><th>1st</th><td>154,187</td><td>167,145</td><td>-12,958</td></tr>
</table>

with

select("xpath", "tr/td[0 > number(concat(.//text()))]") {
	color:red;
	background-color:inherit;
}

in the stylesheet

Con: Contra XPath
Pro: Pro XPath

Pro: XPath is much more powerful.

Con: Though CSS can't do everything XPath can, XPath can't do some really 
important parts of CSS.

Pro: CSS Selectors and XPath Selectors could be combined (e.g. select("xpath", 
"..."):hover).

Con: The above example also gives a glance of the drawbacks of XPath's power. 
Imagine a document gets modified, e.g. by ECMAScript using DOM. The dom 
tree's properties need to be reassigned by reevaluating the selectors against 
the dom tree.

Pro: Also CSS expressions need to be re-evaluated against the DOM tree.

Con: XPath takes more time.

Pro: Machines are fast enough.

Con: Extra implementation

Pro: make it optional

Con: nothing optional unless really neccessary

Pro: Most UA's already get XPath support for transforming XML documents with 
XSLT.

Con: Limited devices without XPath (XSLT) and without thousands of MIPS. We'd 
probably get a two class world.

Pro: Limited devices will only use a subset of CSS, we will have a two class 
world anyway.

Con: Those that know XPath would usually use XSLT to generate docs, anyway, so 
they could circumvent the drawbacks.

Pro: The drawbacks sometimes can't not easily or even at all be circumvent 
under some circumstances, e.g. in content management systems.


These are the arguments that came to my mind so far.


My personal opinion is pro XPath support in future CSS Selectors. Wether 
directly or via a function-like syntax element like "select()" - currently I 
don't mind.

But a homogenisation between XPath and CSS Selectors by using the exactly same 
syntax for the same selectors / path expressions, some modularisation and 
defining module sets that are to be supported by / allowed in the various 
XPath/CSS/Selectors using host languages would be the most preferable 
solution.

I think it's very inconvenient to have two selector languages that are so 
close to each other but still so much apart.
Of course, CSS and XPath up to now address somewhat different purposes of 
selectors. But that's not a reason against the equal parts of each other 
being equal to each other. Actually, currently some parts of these are all 
but similar.

For a homogenisation, I personally would prefer to take more of XPath's syntax 
than of CSS' syntax. It is because I find the XPath syntax more terse and 
convenient in most cases and more powerful in nearly all cases. For instance, 
I find it very convenient to denote attributes as such by prefixing them with 
@. That allows to differ between 
E[foo="bar"] and E[@foo="bar"].
I also find it very convenient that the same selector syntax is used within 
and outside predicates [].

This should not be understood as a discriminization against CSS or it's 
working group. I very much appreciate the CSS WG's work and am really keen on 
seeing the first UA's with CSS Level 3 support out there! You've done a great 
work!

(I'd also homogenise much of XSL Formatting Objects and CSS)

I suggest:
- Modularise XPath
- Modularise CSS Selectors
- Homogenise the similarities
- Call the result XPath Selectors
- Define an XPath Selector module set for use with CSS
- Define an XPath Selector module set for use with XSLT
- Define an XPath Selector module set for use with XPointer
- Define an XPath Selector module set for use with XQuery
And better do it now than later.
And better don't care about CSS Selectors backwards compatibility now 
otherwise you will have to care about them later. Do the cut now, the cut 
introduced by the incompatibility between XHTML 1.x and XHTML 2 is the ideal 
chance to also cope with incompatibilities between CSS Selectors.


Bye
--
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter (Shareholding CEO)
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/