Nathan Sweet wrote: > [ ... ] [T]he more I delve into building my engine > the more I see that the philosophical argument for using CSS is weak and > tenuous. I'm planning on building another engine soon that only works for > the latest browsers only (a sort of high-end engine and library), and I > think I will probably use XPath for that.
The original reasons for CSS selectors, IMHO, was that they were familiar to web developers. Anyone who'd built anything of substance with HTML/CSS already understood how these selectors targeted particular elements on the page and could easily intuit how that knowledge transferred over to scripting the elements. I think there was also a misapprehension about how browsers used CSS that made CSS- based queries seem useful: even those in the know often conflated the notion of a CSS selector targeting a collection of nodes with the idea that the browser was targeting that set of nodes when presented with the selector. With that confusion, it was a very simple leap to use the CSS selector as a way to target the nodes from JS. For the most part this did, and still does make sense. As more developers are coming to use these tools without necessarily having worked extensively with CSS, these sorts of crutches are less relevant, though, and maybe it's time to rethink this. XPath is inarguably more expressive than CSS. And it's designed for the same sort of targeting that we expect in DOM scripting. So there is a lot to be said for using it. The biggest downfall is that it rarely gains us anything; how often do we really need to target something that can't be expressed with CSS? And what's the point of adding a new tool that adds no *needed* functionality? -- Scott -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
