RE: XPath as CSS-selectors?

Herr Christian Wolfgang Hujer wrote:

> as Ian already said, CSS selectors were before XPath.

SGML were before XML. What's your point? :)

> On the other hand, XPath /to me/ seems a bit more mature
> and elaborate.

To me as well.

> Still, XPaths aren't exactly like CSS Selectors, they're
> just similar to CSS Selectors.

Of course. I don't think XPath can replace CSS Selectors
completely, but I think it could be a neat alternative in
many situations.

> As already stated, XPath is missing some of CSS's selectors.

Therefore it must be possible to combine them.

> And, which I must strictly denote, CSS is missing much of
> XPath's capabilities.

Indeed. They get closer and closer in many ways as CSS
develops, but then again XPath develops as well, and takes a
huge leap in the opposite direction. Therefore it would be
healthy for both CSS selectors and XPath that the two standards
came together in CSS, so the future versions of the two can
be more alike.

[1]It also gives the two WG's a good excuse to work closer,
which I think would be beneficial for both of them. They both
develop specifications for languages that select nodes; why
shouldn't they exchange ideas?

> I very much like these examples. I like the idea. I
> absolutely share Asbjørn's Opinion.

Thanks.

> 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)?

This is kind of the situation today, though CSS Selectors aren't
as loosely coupled with CSS as I would like it to be.

> - making CSS Selectors the default selector language?

Of course.

> - adding a syntax for alternate selector languages like XPath?

Yes. We might want to think in the direction that any selector
language can be embedded into CSS, which as of now includes XPath,
and in the near future XQuery[2].

> XPath wasn't designed to and only CSS Selectors can, e.g. :hover
> or :active.

Therefore they can, and have to, be combined

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

I know of ways to express some part of that XPath expression in
CSS3 Selectors, but not the whole shebang. So the answer to
that question is afaik "yes".

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

Yep. It's almost only the imagination that sets the limits to
what you can do if you combine XPath with CSS. :)

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

Yes. As far as I can think of, the only parts of CSS we need
to combine with XPath, are the pseudo-classes and -elements.
I might be wrong though; there can of course be other parts
of CSS that are essential to the spec., and that doesn't exist
in XPath. Either way, I don't see why and how they can't be
combined.

> 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.

This is of course an issue that almost all replies have
mentioned, but let's be serious; isn't this the developer's
responsibility? If he's such a moron that he uses dynamic
scripting with XPath/CSS, and this takes like 30 minutes to
render on his PC, it's really his problem.

This goes for anything stupid that can be done with ECMAScript;
and there can be done (and is being done) *extremely* much
stupid, I tell yer!

> Con: XPath takes more time.

Of course, but we need the power. I want the power! :)

> Pro: Machines are fast enough.

Yes they are. I'm astonished of how fast some XSLT Transformations
are done, and I really don't think that this is a *big* issue
(although it is an issue).

> Con: Extra implementation
> Pro: make it optional

This is my main concern. If we make it optional, we can be sure
that some browsers won't implement it, or at least won't do it
right (which is a case anyhoot). Though would I like to point
out that CSS itself is optional, so I'm not really that worried.

> Con: nothing optional unless really neccessary

I think some of the values of the "selection-language" argument
to the select() function has to be optional, especially since
-- in theory -- any kind of selector language kan be used.

But it might be a good idea to reduce the possible values of
the "selection-language" to a defined enumeration that lies
within the standard.

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

At least they get it from components that exists in the OS.
E.g. Internet Explorer on Windows uses MSXML to transform
documents. XPath can actually be used as a driver to get
better XML and XML-related support in browsers.

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

Can you please dredge a bit on this one? I'm not quite
following you.

> But a homogenisation between XPath and CSS Selectors by using
> the exactly same syntax for the same selectors / path
> expressions

This would be nice, but I don't think it's necessary. I can live
with CSS Selectors the way they're implemented now -- I think
it's a bit too big task to change the syntax completely. But the
future syntax for all selection might be with select() (though
the select() should of course take "CSS Selector" as an argument
at once), and so the current syntax can be depricated over time.

> 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.

Yes.

> I think it's very inconvenient to have two selector languages
> that are so close to each other but still so much apart.

I agree. If anything, I think the to WG's should work closer
together, as the two languages don't seem to take anything from
each other (not syntax, not name convention; nothing).

> 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.

No, it isn't. And I can't see why it is like that.

> Actually, currently some parts of these are all but similar.

Strange but true, yes.

> For a homogenisation, I personally would prefer to take more
> of XPath's syntax than of CSS' syntax.

We might step on some toes here, but I agree.

> It is because I find the XPath syntax more terse and convenient
> in most cases and more powerful in nearly all cases.

Absolutely.

> For instance, I find it very convenient to denote attributes as
> such by prefixing them with @.

I agree.

> I also find it very convenient that the same selector syntax is
> used within and outside predicates [].

Yes, definitively.

> This should not be understood as a discriminization against CSS
> or it's working group.

No, that's not my intention either.

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

A good idea.

> 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. 

A very good point, indeed.

____
[1] Disclaimer: I have no idea of how close the XPath WG and
    CSS WG are working, so in this paragraph I just assume
    that they are not working close. The reason i assume this,
    is that I don't think there are many similarities between
    XPath and CSS Selectors, other than functionality.

[2] There might of course exist other selector languages that
    CSS Selectors, XPath and XQuery, but I don't mind mentioning
    them now. If we get a generic solution where you specify
    what selection language you are using, this doesn't matter
    either.

-- 
Asbjørn Ulsberg           -=|=-          X-No-Archive: No
"He's a loathsome offensive brute, yet I can't look away"

Received on Friday, 20 June 2003 05:03:11 UTC