> how often do we really need to target something that can't be > expressed with CSS?
All the time. How can I target the following with CSS? * parent * last child * prior sibling * next sibling * first n named child of parent j * third n named child of parent j * first descendant of any name with attribute n and attribute value j * first element where name contains "abc" Name, in the above examples, refers to element name and not HTML name Attribute. As far as I know you can't do any of these with CSS, and the first is absolutely essential. I am pretty sure all these are immediately achievable in XPath. I need most of those pretty frequently and have to write conditional code in JavaScript loops to achieve some of these that XPath performs in a single simple expression that is faster to execute. I bet you need most of those too and probably just don't consider it as a selector when you are forced to write some amount of nested logic to accomplish similar objectives where such logic looks nothing like a selector. Thanks, Austin Cheney, CISSP -----Original Message----- From: jsmentors@googlegroups.com [mailto:jsmentors@googlegroups.com] On Behalf Of Scott Sauyet Sent: Thursday, September 08, 2011 6:31 AM To: The JSMentors JavaScript Discussion Group Subject: [JSMentors] Re: spaces in attribute values 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 -- 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
