Mozilla

Old tricks for new browsers – a talk at jQuery UK 2012

Last Friday around 300 developers went to Oxford, England to attend jQuery UK and learn about all that is hot and new about their favourite JavaScript library. Imagine their surprise when I went on stage to tell them that a lot of what jQuery is used for these days doesn’t need it. If you want to learn more about the talk itself, there is a detailed report, slides and the audio recording available.

The point I was making is that libraries like jQuery were first and foremost there to give us a level playing field as developers. We should not have to know the quirks of every browser and this is where using a library allows us to concentrate on the task at hand and not on how it will fail in 10 year old browsers.

jQuery’s revolutionary new way of looking at web design was based on two main things: accessing the document via CSS selectors rather than the unwieldy DOM methods and chaining of JavaScript commands. jQuery then continued to make event handling and Ajax interactions easier and implemented the Easing equations to allow for slick and beautiful animations.

However, this simplicity came with a prize: developers seem to forget a few very simple techniques that allow you to write very terse and simple to understand JavaScripts that don’t rely on jQuery. Amongst others, the most powerful ones are event delegation and assigning classes to parent elements and leave the main work to CSS.

Event delegation

Event Delegation means that instead of applying an event handler to each of the child elements in an element, you assign one handler to the parent element and let the browser do the rest for you. Events bubble up the DOM of a document and happen on the element you want to get and each of its parent elements. That way all you have to do is to compare with the target of the event to get the one you want to access. Say you have a to-do list in your document. All the HTML you need is:

<ul id="todo">
  <li>Go round Mum's</li>
  <li>Get Liz back</li>
  <li>Sort life out!</li>
</ul>

In order to add event handlers to these list items, in jQuery beginners are tempted to do a $('#todo li').click(function(ev){...}); or – even worse – add a class to each list item and then access these. If you use event delegation all you need in JavaScript is:

document.querySelector('#todo').addEventListener( 'click', 
  function( ev ) {
    var t = ev.target;
    if ( t.tagName === 'LI' ) {
      alert( t + t.innerHTML ); 
      ev.preventDefault();
    }
}, false);

Newer browsers have a querySelector and querySelectorAll method (see support here) that gives you access to DOM elements via CSS selectors – something we learned from jQuery. We use this here to access the to-do list. Then we apply an event listener for click to the list.

We read out which element has been clicked with ev.target and compare its tagName to LI (this property is always uppercase). This means we will never execute the rest of the code when the user for example clicks on the list itself. We call preventDefault() to tell the browser not to do anything – we now take over.

You can try this out in this fiddle or embedded below:

JSFiddle demo.

The benefits of event delegation is that you can now add new items without having to ever re-assign handlers. As the main click handler is on the list new items automatically will be added to the functionality. Try it out in this fiddle or embedded below:

JSFiddle demo.

Leaving styling and DOM traversal to CSS

Another big use case of jQuery is to access a lot of elements at once and change their styling by manipulating their styles collection with the jQuery css() method. This is seemingly handy but is also annoying as you put styling information in your JavaScript. What if there is a rebranding later on? Where do people find the colours to change? It is a much simpler to add a class to the element in question and leave the rest to CSS. If you think about it, a lot of times we repeat the same CSS selectors in jQuery and the style document. Seems redundant.

Adding and removing classes in the past was a bit of a nightmare. The way to do it was using the className property of a DOM element which contained a string. It was then up to you to find if a certain class name is in that string and to remove and add classes by adding to or using replace() on the string. Again, browsers learned from jQuery and now have a classList object (support here) that allows easy manipulation of CSS classes applied to elements. You have add(), remove(), toggle() and contains() to play with.

This makes it dead easy to style a lot of elements and to single them out for different styling. Let’s say for example we have a content area and want to show one at a time. It is tempting to loop over the elements and do a lot of comparison, but all we really need is to assign classes and leave the rest to CSS. Say our content is a navigation pointing to articles. This works in all browsers:

<header>
  <h1>Profit plans</h1>
</header>
<section id="content">
  <nav id="nav">
    <ul>
      <li><a href="#step1">Step 1: Collect Underpants</a></li>
      <li><a href="#step2">Step 2: ???</a></li>
      <li><a href="#step3">Step 3: Profit!</a></li>
    </ul>
  </nav>
  <article id="step1">
    <header><h1>Step 1: Collect Underpants</h1></header>
    <section>
      <p>
        Make sure Tweek doesn't expect anything, then steal underwear 
        and bring it to the mine.
      </p>
    </section>
    <footer><a href="#nav">back to top</a></footer>
  </article>
  <article id="step2">
    <header><h1>Step 2: ???</h1></header>
    <section>
      <p>WIP</p>
    </section>
    <footer><a href="#nav">back to top</a></footer>
  </article>
  <article id="step3">
    <header><h1>Step 3: Profit</h1></header>
    <section>
      <p>Yes, profit will come. Let's sing the underpants gnome song.</p>
    </section>
    <footer><a href="#nav">back to top</a></footer>
  </article>
</section>

Now in order to hide all the articles, all we do is assign a ‘js’ class to the body of the document and store the first link and first article in the content section in variables. We assign a class called ‘current’ to each of those.

/* grab all the elements we need */
var nav = document.querySelector( '#nav' ),
    content = document.querySelector( '#content' ),
 
/* grab the first article and the first link */
    article = document.querySelector( '#content article' ),
    link = document.querySelector( '#nav a' );
 
/* hide everything by applying a class called 'js' to the body */
document.body.classList.add( 'js' );
 
/* show the current article and link */ 
article.classList.add( 'current' );
link.classList.add( 'current' );

Together with a simple CSS, this hides them all off screen:

/* change content to be a content panel */
.js #content {
  position: relative;
  overflow: hidden;
  min-height: 300px;
}
 
/* push all the articles up */
.js #content article {
  position: absolute;
  top: -700px;
  left: 250px;
}
/* hide 'back to top' links */
.js article footer {
  position: absolute;
  left: -20000px;
}

In this case we move the articles up. We also hide the “back to top” links as they are redundant when we hide and show the articles. To show and hide the articles all we need to do is assign a class called “current” to the one we want to show that overrides the original styling. In this case we move the article down again.

/* keep the current article visible */
.js #content article.current {
  top: 0;
}

In order to achieve that all we need to do is a simple event delegation on the navigation:

/* event delegation for the navigation */
nav.addEventListener( 'click', function( ev ) {
  var t = ev.target;
  if ( t.tagName === 'A' ) {
    /* remove old styles */
    link.classList.remove( 'current' );
    article.classList.remove( 'current' );
    /* get the new active link and article */
    link = t;
    article = document.querySelector( link.getAttribute( 'href' ) );
    /* show them by assigning the current class */
    link.classList.add( 'current' );
    article.classList.add( 'current' );
  }
}, false);

The simplicity here lies in the fact that the links already point to the elements with this IDs on them. So all we need to do is to read the href attribute of the link that was clicked.

See the final result in this fiddle or embedded below.

JSFiddle demo.

Keeping the visuals in the CSS

Mixed with CSS transitions or animations (support here), this can be made much smoother in a very simple way:

.js #content article {
  position: absolute;
  top: -300px;
  left: 250px;
  -moz-transition: 1s;
  -webkit-transition: 1s;
  -ms-transition: 1s;
  -o-transition: 1s;
  transition: 1s;
}

The transition now simply goes smoothly in one second from the state without the ‘current’ class to the one with it. In our case, moving the article down. You can add more properties by editing the CSS – no need for more JavaScript. See the result in this fiddle or embedded below:

JSFiddle demo.

As we also toggle the current class on the link we can do more. It is simple to add visual extras like a “you are here” state by using CSS generated content with the :after selector (support here). That way you can add visual nice-to-haves without needing the generate HTML in JavaScript or resort to images.

.js #nav a:hover:after, .js #nav a:focus:after, .js #nav a.current:after {
  content: '➭';
  position: absolute;
  right: 5px;
}

See the final result in this fiddle or embedded below:

JSFiddle demo.

The benefit of this technique is that we keep all the look and feel in CSS and make it much easier to maintain. And by using CSS transitions and animations you also leverage hardware acceleration.

Give them a go, please?

All of these things work across browsers we use these days and using polyfills can be made to work in old browsers, too. However, not everything is needed to be applied to old browsers. As web developers we should look ahead and not cater for outdated technology. If the things I showed above fall back to server-side solutions or page reloads in IE6, nobody is going to be the wiser. Let’s build escalator solutions – smooth when the tech works but still available as stairs when it doesn’t.

Translations

30 comments

Comments are now closed.

  1. Vladimir Carrer wrote on February 13th, 2012 at 08:52:

    The day will come that we can use querySelector and querySelectorAll without worrying about the browser support and replace all current Selector Engines like Sizzle and others also we will no longer need big frameworks like jQuery and everything can be done with few lines of pure JavaScript.

    About Event delegation I also build one script based on querySelectorAll that can handle multiple areas at once.

    The syntax is:

    delegate($(“.wrapper”), $(“ul>li>a,#paragraph>a”), “click”, function () {
    alert(“Bang!!!”);
    });

    All the code can be found here: http://www.vcarrer.com/2011/05/event-delegation-javascript.html or here https://gist.github.com/986000

  2. Draeli wrote on February 13th, 2012 at 09:25:

    Thank you for this resume who is clear and watch real good practice.

  3. Mustafa wrote on February 13th, 2012 at 09:31:

    Im really liking classList :) thanks to your talk ive been experimenting with it :)

  4. Chris wrote on February 13th, 2012 at 11:56:

    Event delegation is nice :) but unfortunatly it is not working properly across browsers some events do not bubble on certain elements in IE. :( change, submit
    So js frameworks still are a good options for this.

  5. Mustafa wrote on February 13th, 2012 at 12:40:

    So would you say js frameworks Will eventually go the same Way as flash as they are not the standard?

    1. Simon wrote on February 13th, 2012 at 15:42:

      The two aren’t really comparable, are they? Frameworks like jQuery might become unnecessary as the native Javascript APIs improve, but they’ll never be in the same category as an external plugin like Flash…

      1. Mustafa wrote on February 14th, 2012 at 02:23:

        True, but i was thinking more of the industries view as a whole to frameworks. They kinda are similar in what we are doing with them now and what we did in the beginning with Flash.

        1. Buzu wrote on February 14th, 2012 at 10:36:

          Not necessarily. DOM oriented frameworks will die, but there are other frameworks that will continue living for a while. For example templating frameworks.

  6. Mohamed Jama wrote on February 13th, 2012 at 16:06:

    Nice, little typo @ $(‘#todo a’).click(function(ev){…});
    its not an anchor is it ?

    1. Chris Heilmann wrote on February 15th, 2012 at 04:09:

      Fixed. The accessibility guy in me was cringing at applying click to LI elements :)

  7. Drew wrote on February 13th, 2012 at 17:08:

    jQuery is pretty good about incorporating the fastest native methods, when available, but still normalizing the desired effects across all browsers. It’s in many ways becoming partly a modernizr+polyfills engine for DOM-based javascript.

    1. Buzu wrote on February 14th, 2012 at 10:38:

      There are things jQuery wont be able to do. How would it implement CSS animations that are better that writing them by hand? Besides, keep CSS on CSS files should be a way of life for real devs. I must admit, I don’t always do that though, but I will try from now on.

    2. Chris Heilmann wrote on February 15th, 2012 at 04:08:

      True and it is great at that. jQuery is changing, there is even debate to move all the legacy browser support into a plugin. This would mean a lot of redesign for a lot of already existing implementations though.

  8. Neil Rashbrook wrote on February 14th, 2012 at 04:51:

    I still prefer document.getElementById(‘todo’) over document.querySelector(‘#todo’).

    1. Chris Heilmann wrote on February 15th, 2012 at 04:07:

      The latter is more flexible of course. The former is supported on all browsers, albeit in a broken way (IE6 reports elements with the name attribute todo as well)

  9. Jim wrote on February 14th, 2012 at 08:15:

    @Chris + all

    “the element you want to get and each of its parent elements”.
    An element has exactly one parent element.
    Mankind has long before the web solved that problem recursively by introducing the concept of “ancestors and descendants” and aditionally the concept of “axes”.
    So one would more correctly say something like:
    “the element and its ancestors”,
    but there still is no order specified. Let’s fix it:
    “the element and along its ancestor axis”.

    @Chris
    This mistake is seen a lot, and I assume it’s often caused by the attempt of simplifying an explaination. But as these are fundamental and even universal concepts, which already are well understood by everyone, simplification to an extent such that relevant information is lost, is inappropriate, and may confuse especially the beginner, who in this case
    might imagine looping over elem.parents to find the div it’s contained in, or believe that the event is dispatched to elem.parentNode and elem.offsetParent.

    Please spread the word!

    1. Chris Heilmann wrote on February 15th, 2012 at 04:05:

      Good point. Thanks for this. I am not sure if that really is a problem as you would explain event delegation in more detail (and a illustration) but it is nice to see that somebody cares about the proper semantics. I will take that on for the future.

    2. thinsoldier wrote on February 16th, 2012 at 09:09:

      “who in this case
      might imagine looping over elem.parents to find the div it’s contained in”

      = (

      I’ve done this far too many times. The shame.

  10. pd wrote on February 15th, 2012 at 02:45:

    You first example is flawed. Your jQuery wouldn’t even work:

    $(‘#todo a’).click(function(ev){…});

    there isn’t even an a tag in your HTML.

    Regardless your whole premise is false for normal developers:

    “Newer browsers have” …

    It must be nice to live with the evangelist fairies in a HTML5 standards, all-implementations-match kinda world. When was the last time you did some actual development for a real world client in current-day situation?

    I thank the real-world legends behind Firebug and jQuery every day because they achieved something all the browser vendors have pig-headedly failed to do for around one-third of the web’s existence: listen to, and provide tools for, present-day developers! The latest example is Mozilla’s disgraceful treatment of Firebug. Here is a tool that took web development from guesswork to logical. In doing so it gained a lot of credibility for it’s parent Mozilla product both in terms of developer love and market share when all those developers told their friends just how good Firefox was. However Firebug has one big flaw: memory leaks or ‘zombie compartments’. What is Mozilla doing to fix this? Sweet F A. Instead it’s investing developer time in re-writing the Firebug wheel.

    Stop evangelizing future or ‘modern’ or ‘newer’ code to developers who just want Firebug to be fricking fixed! If you really care about developers and the open web, as it would seem your evangelist job would suggest, you’ll take care of developers before we all move to Chrome (if there are any left like me who haven’t moved already)!

    1. Chris Heilmann wrote on February 15th, 2012 at 04:01:

      Mozilla has a full-time employee on the Firebug project as you can read up in the weekly notes of the developer tools team: https://wiki.mozilla.org/DevTools/2012-02-09 – you can also happily see the progress of Firebug on the blog http://blog.getfirebug.com/. You are welcome to give feedback – if you keep it constructive and stop attacking people personally and waste half your time on sarcasm. As to the decision why we build tools in the browser for development – this is just part of a process to make the browser a development platform. If you want to be dependent on add-ons for that, that is your choice.

      The point of advancing web technologies is that we make the open web with the agreed technologies a starting point for new developers without having to resort to libraries and workarounds. If you don’t believe in that and prefer to do “real work”, thank you, somebody needs to do this while we can fix the underlying issues. But please don’t be in the way of progress just because you found a way of working that feels familiar but far from comfortable. All the technologies we talk about here are open and ready for feedback. If all your feedback is “fix my problems” and you accuse people of not doing “real work” and “live with the fairies” why waste time with a comment like that? It doesn’t help the cause and it costs a lot of your precious time you could be doing the same workarounds you had to do for years now. If that is the development environment you are happy in, great. I for one have spent far too many years of my life working in a flawed and hacky development environment. I think it is our duty to the developers that come after us to make their lives easier. We will not do that by keeping things as they are and keep calm and carry on.

      1. pd wrote on February 15th, 2012 at 06:02:

        I just wrote a over 4000 characters in reply to this however I’m not sure it was as productive as it needed to be. Hence in the spirit of trying to achieve something, I’ll try again.

        > Mozilla has a full-time employee on the Firebug project

        Uno, singular, not plural, one. I know this and it’s a common
        defense. Those inside Mozilla seem to think one full time
        developer is a gift to the developer community that Mozilla
        is quite generous in providing. Time for a wake up call:
        there are more developers working on native tools than Firebug.
        That needs to be addressed, immediately, because Honza
        can’t move mountains or close zombie compartments alone.

        > as you can read up in the weekly notes of the developer tools
        > team: https://wiki.mozilla.org/DevTools/2012-02-09 – you
        > can also happily see the progress of Firebug on the
        > blog http://blog.getfirebug.com/.

        It’s interesting that you assume I am not already familiar with
        these sources of information. Rather than assuming my reply
        was nothing more than another troll, maybe you could see it
        as the most restrained I could manage given the years of
        reading such progress reports? Why would I be happy to see
        a few minor bugs being fixed every fortnight passed off as
        progress? Perhaps I might be a little angry that one massive
        bug that hinders me more than anything IE6 or HTML4 does,
        every day, is not getting the resources it needs?

        Firebug causes immortal zombie compartments

        and

        create a tool to analyze why compartments are alive

        > You are welcome to give
        > feedback – if you keep it constructive and stop attacking
        > people personally and waste half your time on sarcasm.

        I’ve given tonnes of non-sarcastic, non-personal feedback
        and the result has been thus Honza referring to the above
        bugs in that he’s waiting on one devloper to be given
        enough time to focus on 695348 and then Honza *might*,
        just *might* be able to fix the problem.

        Do you reckon that is good enough? Sorry, I don’t! Call me
        human, I get frustrated. You’re the same as you suggest,
        having “spent far too many years of my life working in
        a flawed and hacky development environment”.

        I mean really, am I reading that correctly? We’re saying
        exactly the same thing in different ways and coming up
        with somewhat – not totally – different answers. This
        environment you mention, you speak of it in the past
        tense. This alone makes me ask whether you are
        actively coding these days and if so, what is the
        environment you use now? If it’s still flawed, we live
        in the world. If you’re not coding and instead you are evangelizing HTML5 as the solution rather than fixing everyday tools that are used and relied upon right now, such as Firebug, this is seemingly where we disagree. However we are not that far apart.

        You are or were an active developer. Me too. You are heavily involved in Mozilla, the open web and so forth. Me too. You want to see the open web move forward. Me too. You are excited about HTML5 and wish it were here right now. Me too.

        Hopefully this explains how my intentions were not meant as a personal attack and that we are not that different. If anything I am / was attacking your role. Mozilla does all too little liaison with developers. hacks.mozilla is great as the exception, except when all we hear from it is ways to do things in the future or alternatives on how to do things we can already do. That seems to be the bulk of your content and this is what I am upset about, not you as as individual.

        > As to the decision why we build tools in the browser for
        > development – this is just part of a process to make the
        > browser a development platform. If you want to be
        > dependent on add-ons for that, that is your choice.

        That’s such a misguided statement. Firstly, welcome to the party! Mozilla was all too happy to rely on Add-Ons and it does, it has, it always will. If you really think that developers can or should work without Add-Ons, then Firefox has been the worst browser for years because Mozilla has confined us to developer through Add-Ons and done absolutely nothing about it for years! Personally I don’t want to be dependant on anything that is not being actively supported. That’s kinda the whole point of my argument. Mozilla claims Firebug is not going away but the reality, as you are alluding to but which nobody at Mozilla has the honesty or courage to admit: appears to be that Firebug is essentially being abandoned or reclassified as a third party tool with a single Mozilla developer’s help.

        > The point of advancing web technologies is that we make
        > the open web with the agreed technologies a starting
        > point for new developers without having to resort to
        > libraries and workarounds.

        New developers? Are you implying that at some point the web developer community will freeze and there will be new developers and old developers and the old ones are not your concern?

        > If you don’t believe in that
        > and prefer to do “real work”, thank you, somebody needs
        > to do this while we can fix the underlying issues.

        I believe in the open web. Why do you think I’ve been torturing myself supporting and evangelising Firefox for so long? In your mind you have already written me off as a luddite who doesn’t accept change. That you mind went to this assumption immediately is perhaps a sign of the problem. I support moving the web forward as much as the next person. In fact I find it dubious whenever Mozilla develops ahead of the W3C (though of course the W3C moves slower than climate change). For me you’re either standards compliant or not. But hey I can see that is a bit puritanical and not very productive.

        My reference to real work was meant to express that someone such as yourself, in your defined role, does seem to not pay a lot of attention to the present. It was not meant to denigrate the need for future-thinking work as not real.

        > But please don’t be in the way of progress just because
        > you found a way of working that feels familiar but far from
        > comfortable.

        Define ‘progress’? I am not in the way progress, I am in the way of what you and Mozilla see as progress. For the last 8 months we’ve seen the great work on MemShrink but this progress has failed to solve the Firebug zombie compartments. Right now we are seeing ‘progress’ in the form of native developer tools that are very inferior to Firebug and seemingly will be for quite a while. Unless of course you rate the (Add-On derived) tilt view of a web page? Apart from that native tools have delivered very little that is new compared to Firebug and very little in the way of comparable or better functionality than Firebug. If progress is re-writing the wheel and leaving those using the wheel with flat tyres then yes I’m against it. But for you to again label me as change-phobic and a part of the problem rather than the solution is false. It’s just an attempt to dismiss and discredit what you don’t agree with, based on a misunderstanding of my views.

        >All the technologies we talk about here
        > are open

        and future gazing?

        You’re throwing around the word ‘open’ as if I’ve ever suggested I’m against open source. Strange.

        If the people behind this blog can get one thing out of my comments and nothing else, please let it be that more articles focusing on solutions to everyday problems developers face *now* would be very welcome.

        > and ready for feedback. If all your feedback
        > is “fix my problems”

        my problems? When did I say that? What are you using quotes for? I never wrote this is a problem that is just mine and that I demand a fix. Again you’re misinterpreting the nature and intent of my comments. I am fighting for the colleague writing HTML5 now, in Drupal, whose Firefox crashes at least once every day. He’s not a big Add-On user but he’s a developer so he uses Firebug. Is that selfish of me to fight for him? I’m also fighting for the developer who rightly sees the disastrous Firefox two-year performance/memory debacle (as the MemShrink guru admitted to) that was the integrration of all these HTML5 features whilst ignoring the massive memory issues in the meantime. Read Nick Nethercote’s non-Mozilla-PR-approved (I expect) comment replying to a question about when Firefox would be as good as 3.6 again. Version 10 he said! Kinda funny how the crazy major-version-very-6 weeks can come back to bite you, huh? 6 versions to get back to the memory performance of 3.6? Well ‘major’ version release numbering or not, it’s been 2 years! What has happened in that two years? Chrome has dominated.

        So no, I’m not talking about ‘my problems’ no more than I am a change-phobic luddite. I’m talking about developer problems and how to fix them – now! Not in the months longer it will take for native tools to be even feature comparative with Firebug now. Not in the months it will take for 3rd party developers to convert the bizarre UI crowding nature of the native tools into something resembling the much more effective Firebug UI that exists right now.

        > and you accuse people of not doing
        > “real work” and “live with the fairies” why waste time
        > with a comment like that?

        I spend my evenings reading Planet Mozilla. Unlike you I am not paid to work on Mozilla. I use what methods I have access to and which seem the most appropriate (assuming this blog and others are more *open* and visible than a google group, I post here rather than mozilla.deve.*).

        > It doesn’t help the cause

        I took the same approach for years with regard to memory performance. I suggested the now-accepted about:memory in a blog post (not claiming I was the impetus for it). I suggested that the issue was so bad it needed dedicated resources. Finally MemShrinks starts (and is thankfully lead by another straight-talking Australian).

        The concept of so-called trolls as worthy community exiles is slowly becoming accepted http://bryonycole.com/2011/12/10/the-value-of-a-troll/

        I am not wasting my time. I am displaying my loyalty and passion for Mozilla and Firefox. That Mozilla claims to be open but might not have the tolerance for (admittedly better written, less personal and more constructive than my previous post) feedback has always worried me. Of course like Linux the ‘open’ description is a myth within Mozilla as it’s generally only as open as a merit or technocracy. That makes it as vulnerable to being dictated by a certain type of people as any other construct. But I digress …

        > and it costs a lot of your precious time you could be doing
        > the same workarounds you had to do for years now.

        I never said my time was precious, that is your assumption. However I do feel my time is valuable yet I am still willing to spend it on planet mozilla and by writing these sorts of posts if it means the status quo is shaken up a bit (I can only hope this is possible).

        It’s quite funny you speak of HTML5 so ardently and mention my time management. The massive irony is that I am interested in HTML5 but have no time at work to research it – because I waste too much of my day waiting for Firefox to perform something that has been slowed down by Firebug’s zombie compartments!

        A great example is that an evangelist type like yourself drank the HTML5 Koolaid and set up a recent project using section and aside and all these other glorified tags that do nothing except give slightly more semantic meaning that a div tag with the same id or class name. Low and behold who should end up fixing a plethora of display bugs in IE7 which does not recognise any of these new tags? You betchya, moi! Whilst I could have been researching and looking at solutions like normalize.css, I was hacking around the misguided ‘solutiuons’ of a developer who had paid too much attention to the sort of hype a HTML5 evangelist is responsible for.

        So no, I don’t need advice on my time usage thanks.

        > If that is the development environment you are happy in,
        > great.

        Erm, happy? Again you’re completely ignoring the premise of my argument because you have labelled me as an ‘old’ developer part of the problem not the solution.

        I’m not happy spending “far too many years of my life working in a flawed and hacky development environment”, just like you, but unlike you, I am unable to abandon that life for one of HTML5 dreams. I have to stick with it and it’s far from happy state .. unless … Mozilla would fix the damn Firebug zombie compartments!

        That’s my very point!

        I don’t need much!

        > I for one have spent far too many years of my
        > life working in a flawed and hacky development
        > environment.

        One that was made infinitely better by Firebug I presume? Despit it’s weaknesses. One that would have been much better years ago with less Mozilla resources dedicated to HTML5 and the like, and more than *one* resource dedicated to fixing the flat tyre on the Firebug wheel? If you answered yes to the above, you’ve understood my point. Whilst I can’t go back in time and you are ‘happy’ looking forward in time, all I’m asking for is some more resources dedicated to the current present time!

        P u h l e a s e Mozilla, fix the Firebug zombie compartments problem now. If you still doubt my motives, maybe reading the MemShrink comment where I have offered money out of my own low-paid developer’s income to help solve the problem?

        > I think it is our duty to the developers
        > that come after us to make their lives easier.

        I think it is the duty of Mozilla to help present day developers as well.

        > We will not do that by keeping things as they are and keep > calm and carry on.

        That binary dichotomy thinking is all too familiar in IT, perhaps unsurprisingly. Future or the past? There’s more than that. Some parts of Mozilla even believe that nowadays. Witness the rapid release process. All I’m suggesting is a bigger focus on present-day issues. Until it is proven that native tools are more accepted than Firebug, it is not unreasonable to at least assign equal resources to the two. As Mozilla keeps saying about the browser market: competition is everything. Why not let the Firebug and Native teams compete to see who can produce the best product? Mozilla just got more money in the Google deal. Whilst I’m sure there’s many ways to spend it, if Mozilla really cares about developers, still values add-ons and the *volunteer* developer community behind them, boosting the resources for Firebug is not a difficult decision.

        1. Chris Heilmann wrote on February 15th, 2012 at 07:04:

          I’ve forwarded your comments to the developer tools team as this is what you are actually on about here – well, actually Firebug. This is getting off-topic and doesn’t bring anything to the matter at hand.

          You made me think about what content to put here – not change, but think and I will address that in a few posts in the future.

          As to me supposedly pigeon-holing you, this seems to be a misconception that works both ways. I will not stop being a “dreamer” – ever. Sorry about that.

        2. Kevin Dangoor wrote on February 15th, 2012 at 07:08:

          Hey pd,

          I do appreciate your passion for this subject, though we clearly do not see eye to eye and I don’t think anything I write can change that.

          The people who work on Mozilla’s developer tools are not the same people who work on memshrink. The memshrink project has many moving parts and it’s a complex system. From what I see in the bugs, they’re working at different angles to track down the issues. Memshrink is important and getting attention, but I’m sure those developers also have other features that they are working on in addition.

          Regarding Firebug, I’ve heard you loud and clear that you believe we should be investing more resources in Firebug. Proof by repeated assertion doesn’t make it so.

          > Until it is proven that native tools are more accepted than
          > Firebug, it is not unreasonable to at least assign equal
          > resources to the two.

          Yes, it is actually unreasonable (in my opinion, at least). We have chosen a path that we think is in the best interests of the project and we know it’s a good deal of work to get there. Within the mythical man-month and available resource constraints, we’d like to get there as quickly as we can.

          I read *a lot* of feedback after Firefox 10’s release and a great many people appreciate the direction we’re headed in. There are some, like you, who don’t. That’s fine, everyone has their opinion.

          Use the tools you like.

          Kevin

  11. Marcus Tucker wrote on February 15th, 2012 at 06:13:

    I find it difficult to reconcile the implicit contradiction between your early comment that “jQuery [was] first and foremost there to give us a level playing field as developers. We should not have to know the quirks of every browser and this is where using a library allows us to concentrate on the task at hand and not on how it will fail in 10 year old browsers.” with your later suggestion to abandon using jQuery’s .addClass / .removeClass / etc functions and use the new browser native classList object instead, as according to https://developer.mozilla.org/en/DOM/element.classList#Browser_compatibility it isn’t supported by any current version of IE, and though it can be polyfilled, this would add significant complexity while conferring negligible practical benefit over continuing to use the functions that jQuery provides.

    In fact rather ironically, I think this is a perfect example of a situation where jQuery has the ability to simplify our work by abstracting away such differences, i.e. detecting and using the native classList object internally where present, and where not present continuing to manipulate className instead.

    Drew’s comment “jQuery is pretty good about incorporating the fastest native methods, when available, but still normalizing the desired effects across all browsers. It’s in many ways becoming partly a modernizr+polyfills engine for DOM-based javascript.” mirrors by own thinking, though of course jQuery will never be a magic bullet for browser compatibility, nor should it attempt to polyfill all features, a balance must be found.

    1. Marcus Tucker wrote on February 15th, 2012 at 06:20:

      PS – while performing event delegation without jQuery can certainly be said to have been “forgotten” by many familiar with JS (including myself), the classList object is relatively new, so it doesn’t fit your general theme/complaint about “forgetting” either.

    2. Chris Heilmann wrote on February 15th, 2012 at 06:25:

      I never claimed you should use this instead of the jQuery methods when you use jQuery. The point I am making is that if you need to support all the browsers, then use jQuery. That does not mean though that you need to write everything in jQuery. We need to find a balance in usage here – why should browsers bother to add native support for features like that when people don’t use them? We’ve been held back long enough by IE6.

      1. Marcus Tucker wrote on February 15th, 2012 at 06:55:

        Well then it sounds like we’re both in agreement about balance and pragmatic usage of jQuery where it’s the best approach rather than blindly using it for everything – that’s just not how the article came across to me.

        And amen regarding the agonisingly slow death of IE6! ;)

  12. Hannes Hirzel wrote on February 20th, 2012 at 01:46:

    I think this article is very useful as a reminder that using Event delegation and querySelector and querySelectorAll (https://developer.mozilla.org/en/DOM/document.querySelectorAll) covers a considerable part of jQuery applications. The ‘toDo’ example is illustrative. Let’s use these possibilities.
    David Flanagan has a complete polyfill for classList in his book ‘The Definitive Guide to JavaScript’, 6ed. It is just a bit more than one page (p. 438).

    The remark ‘jQuery is in many ways becoming partly a modernizr+polyfills engine for DOM-based javascript’ is helpful as well.

  13. Billy wrote on March 23rd, 2012 at 18:38:

    The web is a real mess right now, and we’re making it messier with useless snowing effects in CSS3, vendor prefixes, HTML5 boilerplates, Javascript fallbacks for every little thing we can think of, new nonesense JS/CSS libraries, new this, new that, coffeescript, less, mess, sass, ass… on and on, and on… stuff, stuff, and more stuff!

    The Web, the Internet, and your wall’s plug were build on standards and protocols. Follow the standards, ignore all other distractions!

  14. Abolfazl Beigi wrote on September 6th, 2012 at 13:51:

    Thank you very much. so useful.

Comments are closed for this article.