2011/3/21 Jarek Foksa <[email protected]>: >> Oh, and you don't have to take my word for it: >> >> Kangax, "What’s wrong with extending the DOM", 5 April 2010 >> http://perfectionkills.com/whats-wrong-with-extending-the-dom/ > > Very nice article and discussion beneath it, thanks for pointing this out. > > But I still think that extending Element.prototype would be the best > option in my case as I will be using the code inside Cocoa/Webkit > wrapper only. > > I now realize that it's really easy to have naming clash, especially > on form elements, so I should probably keep all my extensions in > separate namespace, e.g.: > > Element.prototype.ext = {} > Element.prototype.ext.disabled = function() { blah; } > Element.prototype.ext.hasClass = function() {blah; } > Element.prototype.ext.isSVG = function() { blah; } > > Alternatively, I could use certain naming convention, e.g.: > > Element.prototype._disabled = function() { blah; } > Element.prototype._hasClass = function() {blah; } > Element.prototype._isSVG = function() { blah; }
And if that browser, or it's handling of host objects change at a future point (in an OS upgrade), or on some devices it behaves differently, you still need to start from the kitchen sink. Like relying on if the browser is IE then it cannot do certain things, but as IE9 came out, a bunch of applications are now broken, because they think, that IE behaves in a non standard way, but now it does (YMMV). -- Poetro -- 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]
