RE: XPath as CSS-selectors?

Robin Berjon wrote:

> Browsers typically render as they see things. That is, for
> a long document, you'll start seeing rendering before the
> document is loaded. I believe that browser makers feel quite
> strongly about this (and rightly so).

Yup.

> If however the rendering of the first element depended on some
> information in the last one (eg /*/following-sibling::*[last()]
> /@foo) that wouldn't be possible.

True. Though it isn't impossible to think of a design that
renders things without the later-node-dependant styles first
(that is the text with the applied "static" styles, typically),
and when the document is finished, applies these styles as well.

It would be almost as the current implementation of images
without the "height" and "width" attributes set; first the
browsers render the image containers with a default size (either
N x Y pixels, or fitted to the "alt"-text) with the "alt"-text
in them, and then the size gets applied to the container when
the image itself loads and the size of it is found out.

Ok, it might look a bit quirky, but it works, and the information
is at place at all times. We must not forget that CSS is a bonus
for visual browsers, and not at all a prerequisite for viewing
HTML files.

>>> And Xpath does not have the equivalent of pseudo-elements or
>>> pseudo-classes.
>> 
>> As I wrote to Ian, this can be combined.
> 
> Or you could have XPath functions.

What kind of functions are you thinking about? The existing XPath
functions like string() and such, or functions in CSS to embed
XPath, like the "select()" i use as an example?

> But why bother?

Because I think XPath has better syntax and is better fitted for
the pure task of selecting nodes than the existing CSS selectors.
But this is not to be misunderstood with that I don't like the
CSS selectors, because I do. Really. I just don't think they're
optimal for the task.

> CSS is widely deployed in browsers. Why fix something that
> ain't broken?

It's not about fixing anything. It's about employing an alternative
to the current CSS selectors, that I think is more powerful and
has a better syntax for the job.

> I think a full fledged comparison of what can be done with either
> would be very interesting indeed.

Absolutely.

> I wouldn't be surprised if subtle differences in design made
> worlds of difference in highly dynamic situations.

It might. But I'm not sure (of anything).

> XForms isn't typically highly dynamic, XForms aren't usually
> meant to move and change all the time.

True.

> XHTML and SVG however, are much more likely to require
> frequent reevaluation.

And what selector language would be preferred in conjunction with
SVG, for instance?

-- 
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 03:39:35 UTC