DOM Scripting is brittle
Is anyone else tempted to put an ID on every freakin HTML element so that they are easy to reference? As I write routines to locate my elements within the div an event fired on I wonder to myself - “Just what would happen if someone whacked some extra DIV tags in this template?”.
Most of our code is PHP and we put some effort into making stuff that wont fall over for our clients. I am not used to writing code which I know will break when inevitable changes are made. But what are the alternatives? Put IDs everywhere? I’d have to generate the IDs because most of my pages are dynamic. Should I attempt to write more forgiving routines that keeping searching until I find that img tag I am looking for? This brings in issues of performance and why the hell am I spending so much time writing routines to find elements on a page that I put there in the first place, just to frickin switch an image or fade some div!?
Awhile back I likened working with Javascript to an addiction. I think that is still apt and I am starting to see that the act is also fairly futile. Maybe I am just weary from a long project but maybe I am seeing the truth of this thing. I think maybe we are all blinded by the pretty moving, pulsating, bevelled corner DIVs and not being realistic about the disproportionate effort required to get a dubious gain in usability.
If you have some suggested reading for me which may ease my pain then drop me a comment and join the illustrious crowd of Dustin Diaz and some guy named John who have commented on my blog.
Stumble it!
September 28th, 2006 at 10:30 pm
Thats the point, I agree. But realistic: “the pretty moving, pulsating, bevelled corner DIVs” making the world go round!
September 29th, 2006 at 10:31 am
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.
September 29th, 2006 at 6:37 pm
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.
September 30th, 2006 at 4:22 pm
Threre was some talk about extending the DOM Collection util to have a getElementsBySelector or a getElementsByXPath. Both would be pretty nice.