 <?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: DOM Scripting is brittle</title>
	<atom:link href="http://blog.wioota.com/2006/09/28/dom-scripting-is-brittle/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.wioota.com/2006/09/28/dom-scripting-is-brittle/</link>
	<description>I have nothing to say and I say it.</description>
	<pubDate>Thu, 04 Dec 2008 18:51:26 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Dustin Diaz</title>
		<link>http://blog.wioota.com/2006/09/28/dom-scripting-is-brittle/#comment-13</link>
		<dc:creator>Dustin Diaz</dc:creator>
		<pubDate>Sat, 30 Sep 2006 23:22:44 +0000</pubDate>
		<guid isPermaLink="false">http://blog.wioota.com/2006/09/28/dom-scripting-is-brittle/#comment-13</guid>
		<description>Threre was some talk about extending the DOM Collection util to have a getElementsBySelector or a getElementsByXPath. Both would be pretty nice.</description>
		<content:encoded><![CDATA[<p>Threre was some talk about extending the DOM Collection util to have a getElementsBySelector or a getElementsByXPath. Both would be pretty nice.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: wioota</title>
		<link>http://blog.wioota.com/2006/09/28/dom-scripting-is-brittle/#comment-11</link>
		<dc:creator>wioota</dc:creator>
		<pubDate>Sat, 30 Sep 2006 01:37:37 +0000</pubDate>
		<guid isPermaLink="false">http://blog.wioota.com/2006/09/28/dom-scripting-is-brittle/#comment-11</guid>
		<description>Hi again Dustin,

Not sure how its structured at Yahoo! but any number of developers at my company may edit the templates. The issue as I see it is there is low visibility on what DOM structures are dependencies for JS. This is rarely an issue for small teams but becomes an issue when a maintenance task can accidentally disable Javascript functionality. QA would find it but then we are back to writing more DOM search routines.

Use of the 'getElements*' series of functions that the JS community has contributed allows us a bit more room to move but doesn't really guarantee that what we are looking for will still be found. The whole exercise seems unproductive and makes me think there has got to be a better way.

Jquery has xpath support built in - its been awhile since I have played with XPath but maybe it has the simplicity and the expressiveness I am after? I guess it would be straight-forward to expand the YAHOO.util.Dom module to implement XPath as well.</description>
		<content:encoded><![CDATA[<p>Hi again Dustin,</p>
<p>Not sure how its structured at Yahoo! but any number of developers at my company may edit the templates. The issue as I see it is there is low visibility on what DOM structures are dependencies for JS. This is rarely an issue for small teams but becomes an issue when a maintenance task can accidentally disable Javascript functionality. QA would find it but then we are back to writing more DOM search routines.</p>
<p>Use of the &#8216;getElements*&#8217; series of functions that the JS community has contributed allows us a bit more room to move but doesn&#8217;t really guarantee that what we are looking for will still be found. The whole exercise seems unproductive and makes me think there has got to be a better way.</p>
<p>Jquery has xpath support built in - its been awhile since I have played with XPath but maybe it has the simplicity and the expressiveness I am after? I guess it would be straight-forward to expand the YAHOO.util.Dom module to implement XPath as well.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dustin Diaz</title>
		<link>http://blog.wioota.com/2006/09/28/dom-scripting-is-brittle/#comment-10</link>
		<dc:creator>Dustin Diaz</dc:creator>
		<pubDate>Fri, 29 Sep 2006 17:31:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.wioota.com/2006/09/28/dom-scripting-is-brittle/#comment-10</guid>
		<description>The best way to tackle these kind of routines is to target HTML collections. It is indeed tempting to put id's on everything, but it gets exhaustive and bloated. Try doing things like Dom.getElementsByClassName or just simply document.getElementsByTagName.

Then again, you have to question who's messing with your template. If it is in fact the clients themselves... well that road gets scary even for the "internet savvy" folks who think they know what they doing. Once you give a client access to throw HTML into a content area - anything could happen.</description>
		<content:encoded><![CDATA[<p>The best way to tackle these kind of routines is to target HTML collections. It is indeed tempting to put id&#8217;s on everything, but it gets exhaustive and bloated. Try doing things like Dom.getElementsByClassName or just simply document.getElementsByTagName.</p>
<p>Then again, you have to question who&#8217;s messing with your template. If it is in fact the clients themselves&#8230; well that road gets scary even for the &#8220;internet savvy&#8221; folks who think they know what they doing. Once you give a client access to throw HTML into a content area - anything could happen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John</title>
		<link>http://blog.wioota.com/2006/09/28/dom-scripting-is-brittle/#comment-9</link>
		<dc:creator>John</dc:creator>
		<pubDate>Fri, 29 Sep 2006 05:30:30 +0000</pubDate>
		<guid isPermaLink="false">http://blog.wioota.com/2006/09/28/dom-scripting-is-brittle/#comment-9</guid>
		<description>Thats the point, I agree. But realistic: "the pretty moving, pulsating, bevelled corner DIVs" making the world go round!</description>
		<content:encoded><![CDATA[<p>Thats the point, I agree. But realistic: &#8220;the pretty moving, pulsating, bevelled corner DIVs&#8221; making the world go round!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
