Most of the advanced CSS selector examples you have provided are only CSS level 3, which less widely supported than XPath. Therefore many of arguments favoring use of CSS selectors for specific targeting less valid.
> Funny the different things that we find essential. I use multiple > classes all the time for styling and for JS-hooks. I don't find this style of development to be wildly reusable outside of its initial context, and I certainly find it to be less efficient to reference than unique identifiers. I say it is less reusable because rarely is this style of development applied entirely outside the reference of some instance's structure, but because the hooks are always reusable those context requirements are ambiguous. This means I cannot typically reuse functionality based on reusable identifiers without also reusing some of the initial document instance's structure or context, defeats a significant amount of reuse outside the initial document. This said it seems the only wildly valuable application for this style is reuse within the context of a single document instance, but there are certainly other less arbitrarily binding options available. I say this form of development is less efficient to execute because pointers to unique identifiers perform a pass/fail to the first match of a single node opposed to searching the entirety of a document and building out a result set. > Do you work only with static HTML? I work with dynamically-generated > and continually modified markup. I can never count on knowing the > whole class value until I already know the node. Logically you are saying you cannot know the effectuality of your design mistake until the causality is exposed as flawed in the wild. I fail to how this makes any sense. As far as dynamically-generated and continually modified markup I built the following over the past weekend and I am working on building an API to allow custom panel creation per target. http://prettydiff.com/jsgui/ You can see that this contains dynamically generated HTML that allows for custom input without using any class values for identifiers. > I'm curious how you would do that with XPath inside myfunction. > `this` would refer to the button which has no id or other obvious way > to select the h3. How do you do it? The path is: ../../h3[0] The DOM equivalent is: x.parentNode.parentNode.getElementsByTagName("h3")[0]; This would work because you already know what the button uniquely is in the context of the DOM without a unique identifier. This is so because of the known event instance and the internal reference from the event provided by use of the 'this' keyword. You would still need to evaluate this in JavaScript, which could be done with the document.evaluate method. I have not actually used this so I have no idea how XPath performs in the context of JavaScript, but I would imagine this method leaks the instruction from a JavaScript interpreter to a different interpreter, such as how regular expressions are processed. If the performance is similar to regular expressions then there is a minor performance hit for each time the separate interpreter is accessed but a net performance gain for each operation removed from the JavaScript interpreter, so therefore this could be costly in a frequently iterating JavaScript loop, but otherwise would result in a massive cost savings by creating a single access point to the DOM in a given statement opposed to the operation of DOM methods where each step is a point of access. I am not sure if this method is supported in IE9. Thanks, Austin Cheney, CISSP -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Scott Sauyet Sent: Thursday, September 08, 2011 9:10 PM To: The JSMentors JavaScript Discussion Group Subject: [JSMentors] Re: spaces in attribute values Austin Cheney wrote: > Scott Sauyet wrote: >> 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. What I was suggesting is that this top-down nature was dictated by the needs of progressive rendering. CSS was developed when the most common method of internet connection was dial-up. Anything that could be done to enable speedier-seeming downloads was considered essential. And that meant that the user agent should be able to progressively render the document as it's downloaded. But this would be impossible if CSS selectors included the equivalent of XPath's `ancestor-*`, `parent-*`, or `preceding-*` axes. Imagine a CSS-XPath hybrid rule-set that looked like: //div { background: white; } //p[/span[@class='warning']/../preceeding-sibling::div { background: red } When the browser encounters a DIV element, should it give it a white or red background color? It cannot know that the second rule does not apply until all of that DIV's siblings have been parsed and found not to contain a P element containing a SPAN element with class "warning". And of course it could be much worse than this. To be fair, something of this sort did sneak into the CSS specs, the `nth-last-*` have the same issues. IMHO, they should simply be removed. But I'm pretty sure that, excluding those, most elements can be rendered as soon as they are parsed. > 2) Selection is designed for wide cascading only and not for descendant > Specificity. I'm afraid I don't understand what you mean here. > 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. Yes, if you need that sort of targeting, CSS, or CSS-like selector engines won't do it. I simply have rarely found the need. > 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. How about a selector that targets decedents of a previous sibling of a node that has a certain property? If the document is only partially loaded, how can you know for sure that any particular node does not match that selector? Any future nodes that are decedents of siblings of any ancestors of the current node might have that property and make the current node match. > 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. Maybe I'm just tired. I'm not seeing what it is that you suggest represents a permissive allowance model and what sort of pass/fail validity model you're comparing it to. What technologies are you suggesting require less work from you? -- 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]
