I presented this talk at the meeting on March 28th, 2012. It discusses the pros/cons and technical details of performing various common tasks without jQuery.
soon leave my son a curse as the almighty dollar. ~ Andrew Carnegie Things to consider: • It's elementary, my dear Watson: retrieval is key • Events are a many splendored splintered thing • Proper attribution is essential • Ajax (and other Achilles heels) • Style is a matter of taste...and complexity • APIs: the honey is sweet, but the sting is painful
by repeating, by combining and recombining a few elements over and over again just as nature does when of elementary particles it builds a world. ~ William Gass • Context is of supreme importance here: ◦ If you are targeting only modern browers, QSA (querySelectorAll) is your best friend. ◦ When aiming at a broad range of browsers, you may have to use choose between cumbersome native DOM methods or a 3rd-party library. ◦ Decisions, decisions: how much control do you have?
true word is spoken in guess. ~ Henny Youngman • Pure DOM: ◦ document.getElementById (EEI* + IE5+) ◦ document.getElementsByTagName (EEI + IE6+) ◦ document.getElementsByClassName (EEI) ◦ Example: IE<=8 Element retrieval (intnt.com) ◦ If backwards compatibility is a must and verbosity is no object, go for it! ◦ * Everyone Except IE<9
~ Emma Goldman • CSS Selectors: div.foo, div > p:lang:(en):nth-child(1n+0):not([data^="user-"]) ◦ If only using simple selectors (or only targeting modern browsers), you can likely use document. querySelectorAll. ◦ NOTE: querySelectorAll supports the same selectors that the browser's CSS engine supports (very few CSS3 selectors in IE<=8) ◦ If you need more complicated selectors consider using Qwery or Sizzle.
govern events, I govern myself. ~ Michel de Montaigne • Browsers handle events differently ◦ EEI browsers come with great out-of-the-box event functionality. ◦ IE<9 has challenges to overcome when handling events. • Thanks to Javascript's innate flexibility most of IE<9's event troubles are reasonably easy to overcome
that incessantly draw great events. ~ Ralph Waldo Emerson • EEI Browsers have a familiar API: ◦ this is the element the handler is registered on ◦ the first argument is an Event object ▪ It has a currentTarget property (this), and ▪ a target property: the origin of the event • Standards: (add|remove)EventListener ◦ Works for EEI (Everyone Except IE<9) ◦ Example: (add|remove)EventListener
a stranger totally unknown to us. ~ Antoine de Saint-Exupery • IE<9 has some challenges ◦ this is the window object! ◦ no event argument--accessed via window.event ◦ no currentTarget or target (alt. srcElement though) • How do we make IE<9 behave? ◦ use a wrapper that sets the context and event arg ◦ Example: (attach|detach)Event
way to attach|detach event handlers ◦ We'd like it to be as performant as possible. ◦ We'd prefer to make no distinctions between EEI and IE<9 • Example: Cross-browser example Eventually consistent At first, dreams seem impossible, then improbable, and eventually inevitable. -- Christopher Reeve
attribute the bad to fortune. -- Charles Kuralt • Attributes are NOT properties! • The inconsistencies between browsers are inconsistent. • The class attribute (className property) is unique enough to warrant separate handling. • As usual the camps are EEI and IE<9
which can be reasonably explained by stupidity. ~ Spider Robinson • With EEI browsers the problem is simple: "the names have been change to protect the innocent..." • With IE<9 (wait. for. it....yes, you guessed it) things get a bit more complicated. • To the code, Robin!
differences will not save you. ~ H. Rap Brown • Due to the CSS effects of multiple classes on a single element it is very useful to ◦ detect that a given class is applied (hasClass) ◦ properly add/append a new class (addClass) ◦ remove a single class (removeClass) ◦ add, if not exists or remove, if exists (toggleClass) • To the code!