> CSS, though, was designed for progressive rendering (the only > exceptions I can come up with are the `:nth-last-*` selectors), > whereas XPath really only makes sense on a full DOM. I think that > explains much of the difference.
I can't say I fully agree. I don't think progressive rendering fully explains the nature of the problem. The CSS selection model is created solely for cascading inheritance only. This is necessary because pages paint from top to bottom and from parents to children. While progressive rendering is a logical effect it is not the technical cause. The limitation here is twofold: 1) Selection is directionally only top-down. 2) Selection is designed for wide cascading only and not for descendant Specificity. In CSS these are not bugs, but when you need to specifically target a possibly not fully known location on a tree graph from a different location that may not be known and where the path between these points is a mystery CSS fails. CSS is designed more for simplicity than for specificity. For complete targeting you must be able to move up or down a graph and you must be able to target a node apart from otherwise identical peers of a set. Furthermore, I would not be so quick to say that a certain selection mode is only for a complete DOM. What makes a DOM incomplete, for instance. Additionally, XML can be fragmented and the DOM of a given fragment is always complete provided that if namespace resolution is required that namespace declarations are supplied, and not necessarily to a root element. As far as the costs are concerned in my opinion a pass/fail validity model always results in faster development than a permissive allowance model because then you know immediately if you have an error with some idea of what/where the error is. In other words always fail yourself before you fail your customers. I also believe that technologies that require less work from me without exposing technology costs or usability barriers to end users always generate a cost savings. As a result I would recommend that users only use XPath for projects where backwards compatibility is a lesser concern. Thanks, Austin Cheney, CISSP -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Scott Sauyet Sent: Thursday, September 08, 2011 12:27 PM To: The JSMentors JavaScript Discussion Group Subject: [JSMentors] Re: spaces in attribute values Nick Morgan wrote: > Scott Sauyet wrote: >> 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? > > The difference between XPath and CSS is that XPath is targeted towards > XML, whereas CSS is targeted towards HTML (primarily). So, when you're > only working with HTML, XPath is un-necessarily verbose. It is more verbose, but I'm not sure that I agree with their targets. CSS is also targeted at general XML. Really the only part of the CSS spec I can think of that deals with the quirks of HTML is the .class selector that matches against a space-separated list of classes. CSS, though, was designed for progressive rendering (the only exceptions I can come up with are the `:nth-last-*` selectors), whereas XPath really only makes sense on a full DOM. I think that explains much of the difference. I am not recommending that people switch to XPath for DOM queries. I don't think it brings enough advantages to outweigh the issues, but it is an interesting idea. -- Scott -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected] -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
