Nate Koechley: “Professional Frontend Engineering”

From Professional Frontend Engineering

Nate and I recorded this last week, capturing the class he’s been teaching at Yahoo for the last couple of years to help new or backend engineers understand the world of frontend engineering. Nate does a wonderful job synthesizing the ideas that the YUI group has been working on since its inception, and this is the only resource I know of that brings all of this content together in a single video.

The long transcript of this 90-minute session follows.

Transcript

Hello. My name’s Nate Koechley — I’m a frontend engineer at Yahoo! Today we’re going to talk about professional frontend engineering. It’s a bit of a murky discipline, it’s an evolving discipline — unknown, in some places, exactly what it does, and what’s important about the work that frontend engineers do. So, today we’re going to try to claim some of that territory, and explain exactly what it is we’re doing, and how.

The purpose of the talk is really to reiterate the core values of frontend engineering, to champion the discipline - and in doing so, to help promote a healthy web. I’ve broken the talk into four sections. First, we’re going to talk about a bit of historical perspective — where we’ve been, and where we are today. Second, we’re going to talk about the beliefs and the principles that drive professional frontend engineering. Then we’re going to go into a little bit more detail about some of the key knowledge areas within our work. And finally, I’m going to try to tie it together and talk about why this matters.

So, up first is historical perspective. This is the Yahoo Homepage in about 1994, I think. You’ll notice it’s even before Yahoo had an exclamation point. And down here, just for fun: 31,000 links in the database, which is — I think I have that many unread email messages. But anyway, the internet has come a long way. One thing to note about this page, for people interested in web standards, and semantic markup, and things like that, is that this page is very clean from those perspectives. It’s a header, a series of links, and then a list of links and categories. So we started strong, but it’s been a long time since then.

This is Yahoo! a couple of years later, in 1996. The first few images at the top there, and just below that, a link to a text-only version of Yahoo! So from the very beginning, Yahoo!’s had an empathy for users and their different needs, and an appreciation and desire to maintain an accessible site.

A few years later — this is now 1997. A little bit more fidelity on the page; some more images, a lot more content. You start seeing the tables, to do multi-column layouts for the first time — but by and large, similar as it was two years earlier. And that trend continues. In 2000, more content, more visual fidelity - we’re starting to do borders, and use colors in different ways. But still, fundamentally, the same page as earlier. This trend continues — this is now 2001.

And only when you get to about 2003 do you start seeing some noticeable differences — a lot more control over visual design, better control over how the bullets are rendered, and how the headers had some back on images — just a lot more things going on within the page. And here’s the Yahoo! Homepage today, in early 2009. A really sophisticated and complex page, with lots of opportunity for interaction, and personalization.

So if we jump in the middle of that fourteen year history, in 2001, and think about what was going on at Yahoo! then. Yahoo! had been around about seven years, it was the largest website in the world, employed about 3,000 people — 0 of them frontend engineers. So we’d built out this great site, great services, relied upon by people around the world every day, without the help of any frontend engineers at all.

So, starting at this middle point, and then looking forward. In 2001, they hired the first frontend engineers — people really to specialize in managing browsers, in building the interfaces that the users interact with. Today, there’s approximately 700 people working at Yahoo! working on frontend engineering fulltime, spread around our offices worldwide.

In 2001, the site was build with tables, and font tags, and was a very static experience. Today, we’ve used semantic markup; we’ve used standards in the way they were designed; the page is highly dynamic, lots of areas to tab through and to personalize — but it’s still as fast as it ever was. We’ve found techniques for putting more on the page, and giving users more control, while still maintaining the speed that we were known for.

In 2001, the website was available and accessible to everybody — none of the markup really got in the way of people interacting with the content. And we’ve maintained that as we’ve brought more sophistication to the page. In 2001, it was a pretty plain and predictable site — testing was a little bit easier, because there was less going on, and the experience was fairly stable and consistent across the world, but plain. In 2009 it’s very highly visual, very adaptive, but still as dependable as always.

Users have evolved along with the technology, and in 2001 there were really modest expectations for how websites should act and behave, and be built. The user expectations were sort of in pace with everybody. Today, users have very sophisticated, very demanding expectations for how sites should behave, and what services they should offer. And these interactions, these user experiences, can become quite complex.

And in 2001, finally, the intersection of design, development, was unknown — different teams worked in different ways, and the people tying the front end to the back end together, were using vague and undefined processes. And I think today we’ve seen the emergence of frontend engineering as really the true intersection of where these things come together.

History from a different perspective, here — Irene was the leader of the User Experience and Design department at Yahoo!, and she was responsible for hiring the first frontend engineers. She did so to help pioneer these richer offerings that we wanted to build, and users were demanding. They needed specialists to really get this new work done. A second motivation was to bring discipline to the work we were doing. Instead of just making it happen, we wanted to have a rigorous process, and use technology in appropriate ways, so that we had more flexibility and we were more efficient down the road.

I’m not sure how many people remember this book — it’s called “Creating Killer Web Sites” by David Siegel. It was well known, sort of as the book that taught people how to design, and how to build sites in a tables-based fashion. And in the preface to this book, the author writes that “the Framers of the Web saw browser differences as beneficial, and believed that visitors should choose how their browser displayed the page…” And he had a problem with that, and he wrote that he “wanted more control over the page,” so he “threw his HTML book in the trash and started from scratch.” And this is OK, then, because browsers were evolving, the industry was evolving — we didn’t know how to do all the things we wanted to do, and so finding ways to work around the system was the order of the day.

But the web is still recovering from these sort of bad decisions, and these corruptions of the technology underpinnings. I really think that frontend engineers are the radiologists — the ones who can see the disease, and understand what’s wrong, and find a course to make the web better.

So a basic question: what exactly is frontend engineering? I have a few different ways to define it, and then we’ll look at what it’s made of as we continue. One simple way to say what we do is that we’re the ones that write software in JavaScript, CSS, and HTML. And I purposely said writing software, because it’s not just a matter of marking up pages, and moving graphics around — today’s websites are sophisticated software applications. In the case of the Yahoo! Homepage, and in the case of more traditional applications, like Yahoo! Mail - in both cases there’s significant amounts of complex JavaScript, and other pieces of software, driving those pages on the client side at the front end. So we’re really the ones: frontend engineers are the ones that write those pieces of software.

Another way to think about it is that frontend engineers tell browsers what to do. We’d all love it if that were easier, but there’s such a diversity of browsers, and browser capabilities, that figuring out how to instruct them to do what we want, is our job. An even simpler answer might be to say we’re responsible for “view source”. So, regardless of how your organization or your team is structured, the frontend engineer is responsible for everything that gets sent over the wire to the user’s browser. So if you “view source” on any page, everything you see there is the result of decisions made by frontend engineers.

The Yahoo! Stack looks a little bit like this — this is another way to think about the sphere of influence of frontend engineers. At the bottom, we’re still C/C++ shop, primarily. Lots of PHP doing the middle lifting. And then the pages themselves, the HTML and CSS and JavaScript, at the top. And so there’s sort of a distinction there between traditional backend work, and traditional frontend work. But it’s important to remember that across all these different pieces of the puzzle, there’s lots of PHP happening, or whatever the language is on your team — and so no matter where you are, where you’re focused, you’re still doing engineering work using a lot of the same languages to generate that coinciding view.

So it doesn’t sound that complex so far — it sounds sort of simple. But it’s not, and here’s sort of why. I just said how we write a lot of PHP, or whatever the language may be, but even if you discount all that stuff on the server side, there’s still a tremendous amount of technology to master for frontend engineers. We can think about this in terms of various knowledge areas. One of the knowledge areas is HTML — and it’s not just about knowing HTML, it’s about knowing different dimensions of that. So the first thing you need to understand is the specification for the language — what’s possible, what’s legal, and what capabilities does this language offer by design? The second dimension of each knowledge area is understanding the actual implementation of that technology. Various browsers decided to implement different parts of the spec — either subsets, or some new additions. And so in addition to understanding the spec, we also have to understand how browsers attempt to implement that spec. And like any implementation, it’s filled with various bugs and quirks, and so understanding the spec, and the implementation by design, and the bugs that were introduced, are each important. Woven throughout that is the need to understand the theory and practice for the best way to apply this knowledge area.

So that’s just for HTML — but there are a bunch of other knowledge areas that are important to frontend engineers. The Document Object Model, CSS, the API has to interact with the browser and to interact with the document, JavaScript, and over the last few years, a lot more work in data transportation — passing information between the client and the server; Ajax, and things of that nature. That can take the form of JSON, or XML, or various other things, but the whole notion of continuous server interaction.

So many knowledge areas, many dimensions to each one — and of course we’re doing this across multiple operating systems, multiple browsers on each of those operating systems, and multiple versions of each of those browsers. So you start to see that there’s a lot of moving pieces in the world of frontend engineering. So if you turn over a cocktail napkin and do a little back of the napkin arithmetic, add up these things — I forgot to mention, there’s multiple rendering modes in each browser — and so a conservative number may be 672 different things we’re trying to balance as we built out these websites. I think those things are in addition to other concerns, like usability, performance, security — all the things around the website that impact the overall experience, and that have either influence or impact on frontend engineering.

So, Stu from “Lifted” I think had it right when he was a little flabbergasted by the amount of different things to turn. And sometimes frontend engineers don’t know which knob, exactly, to turn to achieve the desired effect. This is all made more difficult by the fact — this is a Douglas Crockford quote — that browsers are “the most hostile software development environment imaginable.” It only gets worse with mobile, but if you’re just talking about desktop browsers, it’s a very challenging deployment environment for software engineers.

And fundamentally frontend work is different from backend work, because we never have an opportunity to compile anything, we can’t trust what’s going on — we don’t know exactly what equipment the consumer has — we can’t predict anything, we can’t trust the JavaScript that’s happening, we always need to have a defensive posture. From a performance perspective, we can never install or store anything on the client — it’s sort of stateless. That presents challenges. And then, interestingly, we can never hide, because all the work we do is visible when you hit “view source”, or in the webpage itself. So our work’s there — our dirty laundry’s hanging out there, and so it’s important to clean things up.

But those are some of the reasons it’s different from backend, and some of the complexities involved in this job. And of course it’s critically important — Yahoo!, our value is extracted from being online. Most companies extract a lot of value from their websites, and all that depends on the work of your frontend engineers.

So that’s a bit of a historical perspective, and a bit of a definition about what we do. Now I want to talk about how we do it, and what principles guide our decisions — when we’re faced with all these choices, how do we know which choice is the right choice for our project? Over the years at Yahoo!, we’ve settled on several sort of guiding principles, and I’d like to talk about four of those today.

First is availability — this is the bedrock of building a website. If the site’s not available to people, game over, we might as well not even bother. And so our job is to make sure that everything we do is out there, working, available to everybody. This needs to be true regardless of where they are in the world, or what special circumstances they may be under — everything needs to be available and accessible. And I purposely used the word availability — you hear a lot of talk about accessibility, but availability applies to everybody, and it’s an umbrella term that encompasses accessibility also. And so I like to think about just making the sites available to everybody, whatever that entails.

A second one is a sense of openness. The web was built on open technology and open platforms. Many hobbyists and web developers have viewed source and reverse engineered how things happen; that openness is a key part of the web, a key part of what keeps it healthy and vital. And so there’s the philosophical goal of openness, but also it’s a survival technique for understanding the work that we do. It’s important that we, as an industry and as a discipline, continue to share what we’re learning, continue to advocate for better technology, better practices, better policies — all these things together help ensure that we have a healthy internet, which benefits everybody in the world. Openness, I think, is at the root of that.

The third pillar is richness. There’s been a large rise in DHTML development, and Ajax development over the past half-decade, and that’s what we always want to always be striving towards. It’s our job as software designers, and interface designers, and frontend engineers, to make tools that are useful to users — and richness provides them with richer services, richer featuresets. And so we always want to do this, but we can never forget our first goal, which is availability; so there’s a balance between richness and availability. If you raise the bar too high, you may be excluding some other people. And so as we build into this richness, we do so in a layered fashion, so that we start with a solid core and we layer on more and more richness, and then that core and various degrees of richness are accessible to users, no matter where they’re coming from, and what they’re coming from.

Another thing to keep in mind about richness, as a developer, is that you’re probably not the average user. Here at Yahoo!, we sit on top of a tremendously fat internet connection - everything’s blazing fast, many of us work on brand new hardware with lots of memory — and so as we’re doing rich JavaScript development, as I’m writing lots of software that gets executed in the browser, it may work really well for us, but we need to remember that different people have different sort of equipment, and bandwidth, and so forth. And so remember that — that’s another reason to build in the layers, and to make things defensive.

And then the fourth thing is stability. We want to build sites that are stable, so that we’re always up, that things are always working, in terms of availability — but also in terms of a forward-looking perspective. The web is young; we don’t know what’s coming around the corner. We don’t know what’s going to be invented next, what technology’s coming next. And so it’s important to continually invest in stability, in strong infrastructure, in stable code, so that we have that strong platform to stand on as the next thing happens. So by focusing on stability, you’re really investing in your future, and again, preparing for that future — whatever it might bring.All these things really start today. You can’t get ready for tomorrow by starting tomorrow — you need to do these things in every aspect of your practice.

So those are the four guiding principles, and I know they’re sort of lofty, but as we try to find our right path through all this technology, they really point us in the right direction. Up next, are three core techniques that support these principles.

The first technique is the notion of progressive enhancement. Often, I ask for a show of hands: how many people are familiar with progressive enhancement? And I get a few hands. And then I ask: how many people are familiar with graceful degradation? And almost everybody raises their hand. Progressive enhancement is a flipped definition of graceful degradation — it gets us to almost the same place, but it does so in a different order. Instead of thinking graceful degradation, and saying: I’m going to build my site, I’m going to build my project, and then I’m going to know that certain things are going to break under certain circumstances, we turn that upside down, and we start to progressively enhance a strong core. So we build out our strong core, and then we layer on these enhancements, until we get to the same place. But because we’ve started from the inside out, we know that we’re standing on solid footing. Sometimes in the heat of the moment, and as deadlines approach, if you’re following a graceful degradation philosophy, then towards the end of the project you might not have time to go back and do those things, and to make sure that it’s feeling graceful in these certain ways. If you do it in the other order — if you start small and then build up — you know that you’ve got that safety net underneath you.

So what exactly is progressive enhancement? How do you do it, what are the rules? Here’s a few of them. And they really entail starting at the core, like I’ve said, and building your way up. And so first we use markup to enrich content. We start with our content, we get our content on the page, then we give it more meaning through markup. Once we have that foundation, then we can test that and make sure that everything’s working fine, and that’s our safety net. We’ll talk about why it’s a safety net in a few minutes. Once we’ve done that, then we can start using CSS to design the page — the lay out the columns, to bring in the imagery, and the color, and the topography. Once we’ve got in those two pieces of the puzzle, then we bring in JavaScript to start bringing in the DHTML, and the behavior, and the Ajax communication, that makes things faster for people that have that capability.

Throughout this process, we’re respecting user preferences, both conceptually by letting them choose which layer to interact with, but also actively, by being aware that font sizes may change, that screen sizes and resolutions may change, and building those things in, building that support in from the beginning. Throughout this all, we’ve taken pains not to create any barriers to entry. You can build up — when we build up, anybody can come in at any piece of the process without needing to reach a certain bar. We build a strong foundation, people can interact with that, or anywhere up the ladder. So those are some of the broad concepts behind progressive enhancement.

Related to progressive enhancement, but more specifically about JavaScript, is the notion of unobtrusive JavaScript. And if you do a web search for unobtrusive JavaScript, you’ll quickly find this link — http://onlinetools.org/articles/unobtrusiveJavaScript. Our colleague, Christian Heilmann, wrote this, and it’s a beautiful self-paced tutorial walking you through the aspects and techniques of unobtrusive JavaScript.

We’ll cover just a little bit of that now — some of the highlights. Basically, we want to keep things separate. We don’t want the JavaScript to get in the way of anything else; we don’t want it to be obtrusive, and so we don’t put any JavaScript in the HTML file itself - we call it in later as an external resource. As we’re building out our interfaces, we can never depend on JavaScript — it might not be there, and so it needs to work if it’s missing. Also, we can’t trust JavaScript — so although client-side form validation presents nice usability advantages, at the server level, we can’t trust that that validation is accurate. We can do quick checks on the client side to keep the user happy, but then we always need to remember to validate those things again on the server side, where we have more control and trust. As we’re writing JavaScript, and interacting with various objects on the page, it’s good practice to test to make sure those objects exist before doing something with them. You want to write JavaScript in a way that it’ll fail safely, when it does fail. Fourth, because of the characteristics of JavaScript, we need to be sure to mind our manners. This means not polluting the global namespace with unecessary global variables, and things of that nature, worrying about scope and functions and of our objects. And then, finally, to support parallel events. All users don’t interact with a mouse, and all users don’t interact with a keyboard, so it’s important to provide parallel interaction points. If something might happen on mouse-over, perhaps it should also happen when that note [?] receives focus.

One of my personal pet peeves these days, an example of obtrusive JavaScript, are when we take away an HREF and we replace it with a JavaScript only interaction. So, when I’m doing code reviews these days, these are one of the first things I look for. The web is built on links; HREFs are what tie the web together, what link one document to another one. Whenever we take away that pointer, and instead just put something meaningless in there — either a JavaScript protocol, or a placeholder — we’ve broken that interaction for some people. Again, we can’t depend on JavaScript — we want to be able to navigate, and link, without the need for JavaScript on the page. So, we don’t want any JavaScript protocols, we don’t want any click handlers in our JavaScript either. We’ll talk about this in a little more detail in a few minutes.

The third technique — and again, progressive enhancement, unobtrusive JavaScript, and graded browser support, are all pieces of the same puzzle; they all support the same goals. Prior to the notion of graded browser support, we considered browser support to be binary. When I was doing agency work, before joining Yahoo!, I would often get asked at the beginning of a project: “which browsers do we need to support on this project? Are we going to support Netscape 4? Are we going to support IE 5 on the Mac?” And it was always asked in a binary sense, where the answer is either yes or no. And we realized over time that that’s counter to our goal of maximum availability - if we’re ever choosing not to support a particular browser, that means we’re choosing to have less than complete availability. So that was the first thing that we had to understand, is that support is not binary. The second thing we had to understand is that support doesn’t mean identical. Forcing every pixel to be in the exact same place on every user agent in the world isn’t what it means to support the user agent. Instead, to support a browser, we want to give the browser what it can handle, in the most efficient way possible.

And so with both these two things in mind, we came up with the notion of graded browser support, instead of binary browser support. And we’ve defined three grades of support. At the lowest level, our stable foundation, our safety net, is the C-grade experience. We give C-grade browsers to a blacklist of browsers that we’ve identified as being incapable of handling modern technology. If they can’t handle CSS, if they can’t handle JavaScript, something of that nature, then we’ve put them on a blacklist as being a known browser that can’t handle those technologies. When a blacklisted browser comes to Yahoo!, we withhold the JavaScript, we withhold the CSS, and we just give them the rich, meaningful HTML. So they won’t experience the visual design as intended, nor the DHTML behavior, but they will have access to the all the content — they can do web searches, they can read the news, they can send an email message. And that’s supporting that browser.

At the other end of the spectrum — we have a blacklist for C-grade support — at the other end of the spectrum, we maintain a whitelist of A-grade browsers. These are browsers that are capable, and that we’re committed to doing rigorous QA testing for. These browsers get all the CSS and all the JavaScript in addition to the HTML, and basically a pixel perfect experience, as designed and developed.

And then — so we’ve got our blacklist on one side, and our whitelist on the other side — in the middle are the X-grade browsers, sort of everybody else. They’re not incapable, or they’d be on the C-grade list, but they’re not tested either, and so they end up on the X-grade list. And some people would be surprised to learn that there are thousands, and thousands, and thousands of browsers out there. Most people can name Firefox, and Internet Explorer, and Safari, and Opera - maybe also Camino, and Flock, and SeaMonkey, and Galeon, and all the others. But those are just the most common brands — maybe the 30 or so brands that are most common. But in fact, on a given month at Yahoo! we see more in the neighbourhood of 10,000 different user agents come request our pages. And so this X-grade is our catch-all for that. If, over time, we notice that one of those rare browsers is incapable of our modern technology, then we’ll give it the C-grade experience — but if not, we assume that it can handle it, we’re optimistic by design. We give it the full experience and hope that it serves them well. And so by having this graded notion, this continuum of support, we’re able to invite everybody to experience our website, and able to maintain that 100% availability.

Yahoo! publishes a graded browser support chart of A-grade browsers periodically. This is the current chart: Firefox 2 and 3, IE 6, 7, and 8, Opera, and Safari, across common operating systems. It’s important to remember that just because a particular browser operating system isn’t listed here, doesn’t mean that it’s not getting great support. It just means that we’re not devoting tons of QA resources to verify that report. Browsers like Flock share Firefox’s Gecko core, and render identically in almost every scenario. And so they’re getting great experience, they’re just not treated as a — they’re just not getting the A-grade level of support.

So you might understand the concept, but what does it look like in practice? Here’s a screenshot of Yahoo! Search in the C-grade experience, where all the JavaScript and all the CSS has been withheld. You can see that we’re using meaningful markup — we have an ordered list of links, we’re using headers, we’ve still got the same search box functionality at the top of the page, but it’s rendered just in a single linear layout; there’s no CSS to control the layout. So you have no second column, there’s not DHTML around the form box, and so if you click “images” instead of “web search” it’ll actually do a round trip to the server, bring you back to that new vertical search. In contrast, here’s the A-grade experience. You can see the multi-column layout appears, various iconography and better typographical control - and, you can’t see it in this static screenshot, but now the search box is DHTML based, and changes the context of your search as you click those tabs. So, the C-grade experience is there and functional for everybody - most people get the A-grade experience with all the bells and whistles.

Here’s another example from a photo site at Yahoo! Here, we’re trying to rate a particular photo. And if you think about, conceptually, what’s going on with a rating interaction - I’ve got an ordered list of rating choices, and when I click that it’s going to send my vote to the server, and log my rating, and then display it on the page. Without JavaScript and CSS, we just display those links and let that round trip to the server happen. When we look at the A-grade experience - we view CSS to suppress the text links, and instead replaced it by a familiar star rating widget, which uses Ajax, JavaScript behind the scenes, to log the vote without refreshing the page. So even sophisticated interfaces are possible with this graded approach, when you’re following sort of progressive enhancement techniques.

So those are the three core techniques that all help us reach the - keep our eye on those four priorities we laid out at the beginning. So there’s a lot of choices to be made in how to go about these things. And we want to pick choices that support our principles - but here are a few other things to keep in mind as you make particular technology choices in your day to day work.

First, we always want to do the right thing. And the right thing means following standards whenever possible. If a standard exists, it’s our job to follow it - if it works, in our case. In some cases, there isn’t yet a standard, or the standard is still emerging, and in those cases it’s OK to follow conventions. So if we can’t do it standardly - if there’s not a standard process defined - then we’ll look at sort of an emerging standard, or a common convention across the industry, and try to do that. And then only when those things fail - only when we can’t follow a standard, and can’t help support an emerging standard - then do we go back to the drawing board and come up with some technique that gets the job done in this particular case. As engineers, and as designers, it’s tempting to always reinvent a new, clever way to do something - but for the health of the internet, and for the stability of your project, it’s always wise to follow the standards and to support emerging standards whenever possible. If you are doing whatever it takes - if you are going down the road less travelled - then remember the principle of openness, and document what you’re doing, and help put it out there for discussion as a potential future standard.

In addition to doing the right thing, we always want to be considerate. We want to be considerate of our fellow developers, and of our users. This means doing the simplest thing possible - you don’t get bonus points for finding a more complex way to do something. There’s usually beauty in simplicity. The second way to be considerate is to be flexible. We have many different properties at Yahoo!, and when we’re flexible in the work we do, it can benefit people across the company, and across the industry. So don’t just think about your ratings widget for your photo website, also imagine how it can be used on your movie website, or on your blog, or on someone else. So things that we flexible across context, and also flexible across technology - things that’ll work as pages are localized around the world. And then finally, be considerate by being open. Take what we’ve learned, document it, and come up with APIs and processes that, by definition, are open.

The final thing to keep in mind as you’re making decisions, is to maintain a sense of empathy. We work at the service of our users, and it’s our job to provide a fantastic user experience - but they’re not our only constituents. We also need to remember that our work impacts developers, around the industry and across our company, and also the machines that power these websites. Certain JavaScript patterns are more compressible than others, and so if it’s the same to the user, and the same to the fellow developer, then choose the one that’s going to be the most optimized for the machines. But always remember - even though I’ve outlined these three different audiences, that users are our chief concern. It’s OK for us to suffer a little bit to give the user a better experience; that’s what we’re here for.

So now we’ve looked at the historical perspective, and we’ve talked about some of the beliefs and principles, so now I want to dig a little bit deeper and talk about some of the key things to keep in mind with the different pieces of technology that are important to frontend engineers.

Up first is the content layer: the HTML layer. It should always be up first in your day to day work - we always want to get that solid foundation in place, before we start enhancing it with other pieces of technology. Before you can write HTML, you need to figure out which type of HTML you’re writing, and we do that through the doctype. So what is a doctype? A doctype is the first thing in your HTML document. The element is called the doctype, and it contains a pointer to a document type definition - which is a pointer to a machine-readable definition, an explanation, of the technology that you’re using. In practice, this matters because it triggers a different rendering mode in the browser. Earlier this decade, as more modern browsers were being developed, there was a concern that if they fixed all the quirks of the old days, sites that didn’t update would have a difficult time rendering in these new browsers. And so they wanted to provide a way to support this notion of, sort of, backward compatibility with these older, quirky sites, even as developers were starting to create more standards based sites. And so the browser vendors chose the doctype as the way for authors - page developers, frontend engineers - to choose which of those modes to have. At Yahoo!, we use the HTML 4.01 strict DTD inside our doctype, and this, along with several other doctypes, triggers standards mode within the browser.

One more thing about standards mode versus quirks mode. Browsers do a great job of guessing - we’re able to throw very low grade code at them, error prone code, and browsers are designed to be resilient, and so they’ll fix a lot of those things or they’ll make their best guess. They do a fair job of that, but they do a much better job if we don’t ask them to guess on our behalf. And so as professional frontend engineers, we can tell them exactly what language we’re writing - in this case, HTML 4.01 strict - and it’ll reward us by having the best possible visualization.

So the second thing I want to talk about in terms of markup is: what’s the default presentation of HTML elements? What does a strong element look like, what does an H1 element look like, what does a list element look like? And it’s really a trick question, because markup has no inherent visual presentation - there’s nothing in HTML itself that says that an H1 element should be big and bold, and have lots of margins around it. That’s actually brought on by CSS within the browser. And so realizing that markup has no inherent visualization frees us up to use it as it was designed. Markup’s job is to enhance the content on the page, by wrapping it in these elements that give that content more meaning. We can take a string of text and say: this is a header. We can take a series of phrases and say: these are a list. Markup takes what’s already there, and enriches it with more meaning.

But as I said, different browsers provide internal CSS file that does give a presentation to CSS, to those HTML elements, even though they’re not part of HTML itself. That’s one of the reasons that we’ve created, as part of the YUI library at Yahoo!, a file called “CSS Reset”. Reset normalizes and removes that presentation that different browsers bring to HTML elements. When you have a CSS Reset in place, either the one from YUI or one you’ve made yourself, then everything on the page is going to look the same — we’ve taken away that initial presentation that the browser wants to use, and we’ve levelled the playing field. So in this case, you can see, the first line there is an H3 header, and then H4, H5, H6. Here we’ve got a list and a list. And you might expect that a list would have bullets, or numbers in front of it — we’ve suppressed that, so that we’re just dealing with HTML without thinking about how it might look on the page. This really frees us up to choose which element to use based only on its meaning.

Here’s a screenshot of the Yahoo! News page. Because we’ve taken away the bullets from lists, we’ve taken away the presentation that the browser brings, we’re free to use them based on the meaning of the content, like I said. And if you look at this page, there’s lots of places where we’re actually looking at list based content. At the very top of the page, all these navigation tabs are fundamentally lists — this is a list of the different sections of the page. Over here, these are the lists of the different tabs within a particular module. This looks more like a traditional list, where you’ve got a list of headlines. And even over here, where we’re showing the slideshow, or a video, associated with this article - those are really a list of other ways to experience that content. So by freeing ourselves up from the presentation — the CSS presentation that the browser brings to these elements — we’re able to use them in the way they were designed.

So, two things about markup fundamentally: one, use it as it was designed, and two, use it fully. There are lots of pieces of HTML that go underused, because people have forgotten that they even exist in some cases. So I want to show you a few examples of that.

The first example we’re going to look at is how to build a better table. Tables were used for many years as a way to do multi-column page layouts — not as a way to present tabular data. Now that we’re freed from the visual constraints, and we have powerful CSS to help us lay out the page, we only use tables for tabular data, like this product comparison grid. So as you go in to build a table, we can think about new elements, new attributes, and new ways to bind those things together, to create the richest possible HTML document. Some of the elements people overlook from time to time are the table header, table footer, and table body element. Often, people are tempted to go straight from TABLE right to the TR, the table row. But there are different types of table rows — some of them are the header of the table, some of them are the footer, and some of them are in the body area - and HTML has an element that lets you clarify which of those it is. One interesting note, here, is that the table footer is actually supposed to come before the table body — and this makes sense if you imagine a table full of a million rows, where, as a browser, I want to read initially the header, lay out the header, then read the footer, lay out the footer, and then tackle all the content that’s going to go in between those things. And so the spec says that they should come in those order, and every modern browser out there — all the ones we offer A-grade support to — support, and do the right thing, in this case. So, three new elements there to keep in mind.

Also, some new attributes. The table element itself has a summary attribute, where you can put a description of what the table is — in this case, “detailed features comparison on the Canon EOS D40 Digital Camera.” This shows up to screen readers, even though it’s not visual on the page — this is sort of similar to the ALT attribute of an image element, where we can provide more information for non-visual users of the page. The second thing, here, is a new element. I can capture my table — I can say “Table 1.1, Feature Comparisons for this product.” Often feature designers will suppress this from their final visual design, which is easy to do in CSS — but just because something doesn’t end up in the visual presentation of the page, doesn’t mean it shouldn’t be there in the markup. We want to always use markup to make the richest possible core document.

A few other attributes to keep in mind. For each table header, you have an opportunity to define the scope of that table header, whether or not it’s a column header or a row header. And if you have a really long table header — in this case, the full product name of this camera — you can do an abbreviation, so that as this content’s extracted by a screen reader, or a search engine spider, it doesn’t need to repetitively bore you with the full description if there’s an obvious abbreviation to be used instead. So the first one here is a column, and then this second header, price, goes horizontally as in the row scope.

And then finally, as tables get more complex, it’s useful to bind particular data cells to the series of headers that they may be related to. And so each header can take an ID, where we’re giving it an actual identifier in the code, and then every table cell in the page has a headers attribute, where you can explicitly state which of those headers is in play. We’ll look at the final results here, and you can see that there’s many pieces of data, and if you were to close your eyes and I were to read this page to you, it’d be really easy to lose track of where we were. So by building in those bindings — saying that this cell relates to this header, and this header, and that header — really makes the page richer and more usable. So that’s some tips about tables.

I want to also mention forms really quickly. Some of my favorite elements when I’m writing forms are the fieldset element, which lets you wrap whole collections of inputs, and the legend element that goes with it. A common way to think about this is in a check out form from some online store — you have a whole set of fields relating to your billing address, and a whole set of fields relating to your shipping address, and that’s a perfect case to use a fieldset element to encapsulate those things, and a legend element to describe which is which. And then finally, the label element lets you bind the text of an input to that input itself. If you don’t use an input, then I have a hard time knowing exactly which checkbox this is — visually, I can see that it’s related to this, but there’s no binding at the code level that ties those things together. This is also an important usability feature, because now, instead of just the checkbox being the target area for my mouse click, this whole thing becomes a target area, and I can click anywhere on here to toggle that textbox, that checkbox.

So those are just a few of the HTML elements that are available in the menu of HTML — in the catalogue of HTML elements. Here’s a list of a lot of the ones we use on a day to day basis — and here I’ve called out some of the ones that aren’t used as much as I think they should be. The cite elements - one of my favorites when I want to do various things with pieces of content within an article. So the point here is to refamiliarize yourself with HTML. It’s an often overlooked piece of technology; it’s not terribly complex, but there’s a lot of hidden gems that we should all do a better job taking advantage of.

But it’s not just knowing which pieces of markup there is — it’s also about thinking about how to use them, in what scenario. And so here’s just a little quiz we’ll walk through quickly to think about in which scenario to use which elements. And hat tip to Dan Sederholm and his Simple Bits website, the inspiration for some of these questions. So up first, is if you want to markup the title of a page, what’s the best way to do it? You could have a “span”, and then say it was a title through the class attribute; you could use an H1 element, which stands for the number one header on a page, or you could just call it a paragraph and then give it some bold. And I think, clearly, here the best choice is H1 — that element was designed for the primary header on the page, so that’s the right choice here.

What about lists - what’s the best way to write a list? You could just separate them visually with a carriage return, using the BR element. Some browsers let you get away with just using a single list item, assuming that if you don’t close it and you start another one, you meant to close it. That’s another example where we don’t want to let browsers guess, and so we want to always make sure to close everything we’re doing. And then even though browsers continue to guess, and they assume this is probably a list, we haven’t told it which kind, and so it’s important to be thorough and say: in this case, it’s an unordered list. So choice four, here, is the best way to probably markup this piece of content.

Sometimes it’s not so clearcut. In both of those examples, header was the right choice, list was the right choice — but what about something like this, where I’ve got a list of stuff, and then the stuff. In this first option, we’re using a definition list — we’re calling the ‘List of Stuff’ the header, we’re calling it the definition term, and then we’re using the DD, the definition description element, to define that term. That creates a relationship between this content and its header. In the second choice, we’re using a header, because that’s what this is, and then we have a list of stuff. This is an example of a conundrum that presents itself to frontend engineers all the time — which is these non-perfect things is best? And there’s really no great answer. The answer is that you need to understand which each is doing, and then make the best choice in your scenario. If it’s really important that you maintain the relationship between the header and the content, then choice number one is going to be best. If, instead, you want to know this is a header, regardless of what follows it, then choice two is best.

A final one, here to look at, is how would you markup the footer of a page? In the first case, we’ve got a DIV, which is a region of the page, we’ve called it footer, and we’ve put our footer content inside there. In the second case, we’ve done the same thing but we’ve wrapped the content in a paragraph element. You could argue that the first one is better, because it’s lighter weight — you don’t need that extra element, because it’s already encapsulated in the DIV element. But in my opinion, I think choice number two is better, because we’ve actually — not just encapsulated the region, but we’ve encapsulated the content within the region. If we’re doing a partnership with some other content provider, and all of a sudden we need to have a secondary, or a third, or a fourth footer on the page, if we already invested in this encapsulation here, we can just slap in another paragraph for each of the other footers, without needing to go back and touch the first one again. So here’s an example where if this is the only thing I had to build, either choice would work — but because I want to invest in the future of my site, I want to build the strongest platform possible, I want to be forward thinking and recognize that this content might evolve over time, and be prepared for that now.

The other thing to keep in mind with markup is it’s a chance to avoid what we call divitis, or classitis. These diseases refer to the misuse, or the overuse, of these elements when there might be something better to use instead. If markup’s job is to apply meaning to the page, we want to apply as much meaning as possible — so even if there isn’t the perfect element for our particular type of content, there might be some element that has some meaning, and we want to use that instead of the semantically empty development. The second reason to be wary of using too many DIVs is we really want to be building the strongest Document Object Model we can. Using a variety of meaningful markup gives you a richer document to apply your CSS, and to apply your JavaScript to down the road.

So here’s an example. This is an indicator that you’re suffering from the divitis disease, and we see this frequently — people are moving away from using tables based design, but they’re not yet using the full range of HTML elements. In this case, they’ve wrapped everything in a DIV, and only differentiated them using the class attribute. So here we’ve got divitis — too many DIVs — and an overreliance on the class attribute. This can be better, and more quickly, written using meaningful markup itself. So here, we’re still using a DIV to wrap the whole thing - because the DIVs are for regions of the page, that’s appropriate — but inside here we’re using a header element, and a cite element, and paragraphs to wrap the content itself. This also shows a good time to use classes. If cite is the right element, here we’re citing where the story came from and when it came from, we might want to sub-class that element, and that’s how I like to think about classes. Here we’re saying: of all the sites in the world, these are the ones that define “publisher”; of all the sites in the world, these are the ones related to “date”. So we’ve taken something with some meaning already, and we’ve given it even more meaning through the class attribute.

You may have noticed that that example had one DIV wrapping the whole thing. And we’ve found that the web is primarily rectangular, regardless of the visual flourishes that we are able to bring to the page — the rounded corners, and the drop shadows, and the speech balloons — the web is primarily made up of boxes at the skeleton level. Recognizing that, we’ve adopted what we call the Standard Module Format. Every piece of content on the page, every chunk of content on the page, is a module, and so we wrap it in a DIV, and give it a class of MOD for module. Inside there, most modules have a header area; all modules have a body area, or they wouldn’t be anything at all; and some modules have a footer area. And so we’ve created these other structures to house those pieces of content. So now we have a really predictable, dependable structure that we know is going to be in place everywhere, that we can depend on — it becomes part of the platform, part of the strong foundation we’re trying to build.

Here’s how to think about it — here’s an example of a module from Yahoo! Sports. You’ve got a list of headlines; you can jump between headlines, and rumors, and the most popular stories of the day; then the body of the module; and then some other choices down here in the footer. We always start at the beginning, we always start at the inside, we start with the content first — we figure out how to mark that up in a meaningful way. Something like this. Up at the very top, we’ve got the two headers — they’re a list of choice of choices, so we wrap those in a list. Then we’ve got a header for this piece of content, and then a list of links. At the bottom, another list of more things to do. Once we have that content marked up, we see the whole thing is a module; we give it a unique identifier, and then the pieces within there are clearly a header region, a body region, and a footer region. So this Standard Module Format’s flexible enough to hold a wide range of content, and gives us a solid and predictable foundation.

So the second area of specifics I want to talk about is about CSS, or the presentation layer. The first thing about CSS is: how do you get it on the page? And we’ve found that the best way to get it on the page, in almost every case, is through the link element. You can also bring it in through inline, right in the elements themselves — you can bring it in through a scriptblock, sorry, a styleblock at the top of your page, or you can bring it in through various importing techniques. But the most performant, and the cleanest way — and the way we choose to use it — is using a link element pointing to a CSS file directly in the head of the document.

We talked about classes a little bit — I want to touch on them again, briefly, here. Remember that classes and ID values, even though we think about them in terms of CSS — we often say a CSS class, and a CSS ID — they’re actually part of the HTML layer; they’re values, or they’re attributes, with values, in the HTML themselves. Because they’re part of HTML, they follow the same practices we follow when we’re writing other parts of HTML — they should be as meaningful as possible, and add to the meaning and the richness of the HTML document. I talked earlier about how classes can be considered “element sub-classes” — the citation element related to publishers, the citation element related to the dateline, or the byline — that’s an appropriate time to use classes.

And then Matt Sweeney thinks about IDs as being three-dimensional; what we mean by that is they exist in all three dimensions of your frontend engineering work. At the HTML layer, every ID becomes a fragment identifier to that part of the page. Fragment identifiers are bookmarkable, they’re visible to the user; they can be visible to the user. And so you need to pick something that’s A) meaningful, and 2) user-friendly, and human-readable. These IDs are also used in CSS as a handy selector — as a very specific selector — also, for targetting your CSS rules, just to that idea of [xx]. So you’re going to use it in HTML, you’re going to use it in CSS — you’re also going to use it in JavaScript, as an easy way to get to a certain note on the page. So when you think of the names, the values, for your ID, pick ones that are going to work across all three dimensions, not just ones that only make sense in terms of CSS or in terms of JavaScript.

Building a strong DOM does make life better for the frontend engineers. In this case, we’ve got an abbreviated sort of news article here, where a link to something happening, and the citation of who’s reporting it. Now we’re able to define CSS, to attach CSS to these nodes just based on the strength of this Document Object Model. The Document Object Model refers to, sort of, the tree of nodes — so it says that this anchor is inside this citation, which is inside this list element. It’s sort of the node structure of the page. If everything were DIVs — if all of these meaningful markup elements were replaced with meaningless DIV elements — we wouldn’t really have that same structure. You’d still have a descendancy tree, but you wouldn’t know that it was a list item inside an unordered list, for instance. So this matters in terms of good markup — it also matters in terms of CSS.

And this is how it’s going to make your life better. Assume we want to give some content the color red, and different content the color blue — how do you go about that, without adding any new classes to the page, or any new IDs to the page? Just based on the strength of our DOM. If we say that “A”s become red, then both of these are going to be red — or, in this particular case, because I’ve then said that they’re going to be blue, they’re both going to be blue. And so I need a way to distinguish this anchor from this anchor. And I do that through its place in the DOM tree of the page — this one is different, because it lives inside a cite; this one doesn’t. And so in the CSS up there at the top, I’m able to say: all the anchors are red, then, the anchors that are inside a cite element, those are blue. So by taking the time to use markup in the right way, creating these rich structures, it makes it much easier and more efficient to apply CSS subsequently.

Here’s a little screenshot of a piece of CSS — and you can start to see how this Document Object Model plays out in CSS also. It helps to have… there are certain IDs on the page; this is the more area, this is my sidebar; and as I start to write CSS it almost self-documents itself. You can see that all these CSS rules and related to this region of the page, this sidebar region of the page. The other thing to note, here, is that there’s very few classes being used. Almost everything is applied directly to an HTML element — in some cases, based on its position inside of our Standard Module Format. Here, it’s the H3s that are just inside header regions; here, it’s the anchors that are just inside the footer. But one of the takeaways here, again — you can write a lot of CSS, you can have very specific selectors and target particular nodes without needing to have a whole lot of classes, without needing to have a whole lot of IDs. Just a few used smartly, combined with the rich DOM created for meaningful markup, gives you all the control you need to write great CSS.

So we just hinted at this a little bit — we were able to be more specific about our CSS rule by talking about its relationship to other nodes on the page. We were able to say that there’s a whole bunch of anchors, but the specific anchor that’s inside a cite element — we want to treat that differently. And this is where a lot of the power of CSS comes from. If you think about a CSS expression, where I’ve got a selector on one side, and a declaration on the other side — anchors red — a lot of time is spent thinking about the declarations; learning all the CSS properties that are available to us that are supported in the various browsers. But a lot of the professionalism of CSS, in my opinion, comes from really focusing on the selector side of the equation. So there’s a lot of different types of selectors — we’re not going to cover them all today, but I want to let you know that I think it’s important, and show you some of the ways you can do this.

We talked about element selectors, where I’m saying: all H1s on the page should share this declaration. I can also say that all… I can be more specific, and say that headers within the particular module should have this particular declaration. And there’s a lot of different ways to do this. Here, I can say: only if that module is a DIV, as opposed to a table, or a span, or a paragraph. This allows you to have one CSS file, and one notion of module, but have it behave differently in different contexts. These can get more complex — I can say: of all the pages that this CSS is being used on, only body’s that are shopping carts, where the whole template of the shopping cart should this rule apply, and even in that case it should only apply to anchors inside headers with a particular class, inside a particular ID. So you can build out these long expressions, these long selector expressions, and have very fine-tuned control over where the rules are applied. Here, without using any extra classes, we’re just being very specific about what level of depth of list to impact. So here, only lists nested inside other lists. Lots of different ways to go about that, and I encourage people to focus these days as much on the left side of the equation — the specificity of the selector — as on mastery of the declarations of the CSS properties.

The second topic I want to touch on in CSS is really two topics — background images, and the notion of CSS sprites, or image sprites. Background images are one of the most powerful aspects of CSS, when it comes to visual design. It’s great; they’re very well supported in all the browsers, they’re very powerful in terms of what they bring to design - bringing background images onto different parts of the page is how we create really beautiful pages, in most cases — and they’re highly efficient.

There are two types of images you encounter on a webpage. The first are content images, and the second are decorative, or decorative images. Content images are related to the content of the page - so thinking back to a news page, the news content is the text of the story, and the pictures associated with that story. Those pictures are part of the meaning, part of the content itself. In contrast, the iconography, and the rounded corners, and the other visual flourishes on the page, are decorative images. Because they’re decorative, because they’re part of the presentation instead of the content, they belong at the CSS level, and we get those on the page generally as background images. When I talk about them being effiicient, it’s really related to how they’re called onto the page. Browsers help us out in this regard, and load images in the correct order. They load all the assets in the correct order. The most important thing for the browser to understand is the HTML — that’s the first thing it needs to learn to put the content on the page. And so it quickly starts reading the HTML, then encounters the CSS file, understands the CSS file, and so as its encountering more content it can paint that immediately to the page, including any content images. Only after all the content has been loaded, do background CSS images load. And so we’re getting them in the right order we need them — we want to get the content there first, and then bring in the decoration. It does that for us for free when we use background images.

The second way they’re efficient is because they’re only used, they’re only downloaded, if they’re actually used on the page. Because it doesn’t request them until it’s processed the CSS, and the HTML, and decided when they match up, if there’s not a match, it won’t request that image. So you can have one CSS file with lots of different background images for different pages, and only get loaded when that particular page needs them. So — well supported, powerful in terms of what you can do with visual design, and really an efficient way to get visual design on to the page.

In this case, we’re bringing in an image here, and then we’re really controlling the presentation — so whichever part of the image I want to display, I can pull it out, pull it away from the node and only show the part that I care about. Background images only apply to the nodes themselves, not to anything around the node. So the background image covers the content within the node, the “padding” associated with it, and stops there. It won’t bleed on to your border, and it won’t bleed into your margins around the image. So by positioning it, we can choose which part of the image shows up associated with that node.

That’s the technique that powers the ability to do things like image sprites. This is the image that’s associated with Yahoo! Mail. We’ve got all the different icons, different gradients that we use to paint the interface, different states of the buttons of various sorts, the toolbars — all the images needed for the Yahoo! Mail application exists in this single file. So instead of having 150 HTTP requests, and all the time associated with fetching all those images, we just grab one image and then position it as a background behind the places where it belongs. So here, we’re going to black out the whole image, and we’re going to have a node here where we want to display this icon, and so we can take that, position this big image so it just shows this one. If we want to use a different image — if we want to pull out a different tile from this image, a different piece of this sprite, we just move that background image behind the node, and expose a different portion of this big image. It’s a really powerful technique for having lots of visual fidelity, almost for free in terms of performance.

A couple of other specifics about CSS. CSS suppport in the browsers is various — some browsers support it better than others, some parts support different pieces, and we of course need to be aware of that. In most cases, though, with today’s crop of A-grade browsers, CSS support is strong and consistent. There are still some cases, though, where we need to filter a CSS rule only to a particular browser. In most cases — in almost every case — this involves filtering a rule to IE 6, and IE 7; sometimes a different rule to IE 6 and IE 7. And so if I have a CSS selector, here I’m sending it to a particular node on the page, and giving it a particular width. This is the width that I want all the browsers out there to know — but I might need to give a different width to Internet Explorer. And so I can do that right here in the same part of my CSS file by using what’s called a CSS hack, or a CSS filter. In this case, we prefice the property name with this asterisk, with a star, which is invalid: there is no property called “*width”. And so every browser except IE 6 and IE 7 correctly discards that width and ignores it, and continues to use this first declaration. But IE 6 and IE 7 read this as width — they don’t see the star there, they read it as width, and so this value overwrites the previous value. In most cases, that’s all you need — you need one value for IE, and you need another value for everybody else. In rare cases, you need to distinguish between IE 6 and IE 7, and we can do that here by having an underscore instead of a star, and only IE 6 knows about this. IE 7 discards this property, and doesn’t use it. So in one little piece of CSS, we’re able to give a value to everybody, override it for IE 6 and IE 7, and then optionally override it again for IE 6.

Some people complain because this makes your CSS file invalid, because you’ve got invalid rules in your CSS file. That’s true, but we think it’s a wise tradeoff, because it keeps all the properties associated with a particular presentation in one place. These are well-known CSS filters, so we’re not confused when we encounter them in our CSS, or when they show up in our validator reports. So the tradeoff of having them right in proximity to everything else is worth, in our estimation, the downside of having an invalid CSS file. Secondarily, these are forward compatible in the sense that we’re taking advantage of errors in the CSS parser, in particular browsers, to give that particular browser a new value. So in the case of IE 8, they’ve fixed both of these parse errors, and they’ve fixed the reason for needing to use these — and so without any work on our end, they automatically get the standard value that all other browsers get.

There’s a second category of issues in CSS, related to the notion of hasLayouts. hasLayout is a hard concept to get your head around, and it only impacts IE. hasLayout is an internal property, not defined in any spec, completely proprietary to Microsoft, IE 6 and 7, that distinguishes and determines when particular nodes draw themselves differently - as you’re laying out the page, which ones have layouts, and which ones are parts of a different layout. This is really the root of a lot of common CSS bugs in IE 6 and 7; bugs like the three pixel jog, like double margins, like collapsing margins, and even things like clearing floats in some cases.

This is a great article here — if you do a search for “On Having Layout”, you’ll end up with this great article; sort of the definitive article, with all the research about what’s actually going on inside the browser. Like I said, it’s the root of many issues, and often triggering layout, the hasLayout property, on a node fixes some of the problems you’re having. There’s no way to set hasLayout itself, but there’s ways to trigger it being set by the browser. Our favorite way to do that is by setting “zoom:1” to the node we care about. Zoom is another proprietary, unsupported property in Internet Explorer, and so it doesn’t actually have any impact on your page other than triggering hasLayout. And even if it did, zoom of 1 equals 100%, equals the normal visualization anyway - so if in the future they were to support zoom, “zoom:1” is a safe value to set. So this is a nice way… there’s other ways to trigger hasLayout within IE, to fix a whole host of CSS layout problems; this is our favorite way to do it, and one you can consider.

So we’ve talked about HTML, we’ve talked about CSS - now I want to spend a few minutes talking about JavaScript, and sort of interacting with the Document Object Model. This’ll be the shortest section, because the YUI theatre and the Yahoo! Developer Network already make available quite a few videos about JavaScript, from Douglas Crockford introducing the whole world of JavaScript to you at the beginner and advanced level, up through lots of individual videos about different components within YUI, and the design patterns, the coding patterns behind those. So I’ll refer you over to those, but there are still a few things I want to talk about today.

First, is to remember that we’re trying to do all these things unobtrusively. It’s tempting to use JavaScript to fix all these CSS problems, or to bring a lot more interactivity to the page, but we want to do it in a very mindful way, remembering to always be unobtrusive. We want to follow best practices, like we do in every piece of work we do. And it’s important because JavaScript is doing so much to be really… to ensure that we’re writing really strong JavaScript. One way to do that is to validate it — we’ll talk about that in a sec.

The other thing to talk about is optimization. JavaScript sends a lot more code over the wire to the browser, and its common for lots of pages to have tens and scores of k of JavaScript — and so figuring out ways to optimize that JavaScript is important, so that these rich interactions, and these behaviors, and these animations that we’re building go as fast as they can, and are as performant as possible.

So we talked before a little bit about unobtrusive JavaScript — not putting it in your files, remembering that it’s an enhancement and it’s not secure, checking objects before you use them, and minding your manners in terms of scope and namespace pollution. I want to talk a little bit more about how to keep JavaScript out of your HTML altogether. This is sort of a common thing — here I’ve got a link pointing to a help document, and instead of navigating to the document, I want to put that document in a pop-up window; either spawn a new pop-up window, or as some sort of dialogue within the page itself. So this isn’t too bad — we’ve still got the link here, and so if a user doesn’t have JavaScript turned on, they’re still going to be able to navigate to this page. That’s key — you don’t want to either put the JavaScript protocol here, or just have some other placeholder there. We always want, like I said at the beginning, we always want our links to go somewhere. But we also want to enrich that behavior whenever we can, and so in this case we want to trigger a help pop-up instead of navigating the user away from their current context. So, step number one is to get the JavaScript out of the HTML. Anytime you see an “onclick”, “onmouseover”, “onmouseout”, “onsubmit”, those things don’t belong in your HTML — they can be attached with JavaScript later. So step number one is to take it, physically, out of the HTML. Once we’ve done that, now we can attach that event with JavaScript to that particular node. So here I’m saying: I want to add a listener - this is a little bit of shorthand, there’s lots of examples with the complete code snippets on the web, that you can easily find — here I want to add a listener to this node, and listen for whenever it fires a click event, and when it does fire that click event I want to execute this function.

So now if you look back up here, I’ve still got my link pointed right to my help page; I haven’t changed any of that, that still works. I’ve just simply said that when that node fires this event, do this thing. And then this JavaScript here can say: don’t actually navigate there, we’re using JavaScript instead. So unobtrusively I’ve added this JavaScript to the page, I’ve provided more richness without reducing availability or bloating the code that exists in the HTML.

We talked about how JavaScript is an enhancement, and here’s an example. On Fantasy Sports at Yahoo!, players often want to rearrange their line up before game day. The fastest interaction for rearranging things is generally with a drag and drop experience — so here, I’m taking one of my wide receivers, and I’m going to put him on the bench and swap him out with a different wide receiver. So as soon as I grab him, it shows up where I can possibly drop him, and I’m giving some visual feedback to the user — it’s a really slick experience. But it’s an enhancement, and you need to think about what the core experience is. The core experience is rearranging these players. And so if JavaScript’s turned off, then the underlying core functionality is exposed — in this case, I’ve got form select boxes that let me choose which position these players are going to occupy, and then offscreen there’s a submit button to submit those changes, and refresh the page with the updated lineup. So in the HTML, this is exactly how it exists — subsequently, JavaScript comes in, suppresses this node, hides it from the visualization, and brings in that DHTML behavior to let users drag and drop in an efficient way. So you’re still able to have all these really rich experiences, without sacrificing the HTML and the core experience that’s underneath them.

We talked about testing objects before assuming they’re there. In this case, I want to take an object, I want to set its background color. But what if that object’s not there? Then this function is going to fail, and maybe send an alert that’s probably going to be visible to the user. That’s not something we want, and so we always want to be in the habit of being defensive. So, instead of doing that, I can say: if this object exists, then do that. If it doesn’t exist, it’s going to fail quietly, preserving the good user experience. So just building in these defensive practices into the code that you write results in bulletproof code, which keeps all of our users happy.

Finally, validation - one great tool for validating your JavaScript is JSLint. And here I’m sort of abusing the term ‘validation’, because we’re validating it strictly to the spec, we’re validating it against a set of practices that we think result in healthy JavaScript. So this is a Douglas Crockford production: it’s a JavaScript program, written in JavaScript, for detecting errors in JavaScript. So it looks for things like missing semicolons, or commas after the last element in an array, or global variables that might not need to be global, things like this. And it alerts you to them — so it takes the ‘lint’ out of your code, and makes you have a healthier body of code.

When we first started using this regularly, it definitely has the potential to hurt your feelings a little bit, because it enforces strict patterns that he, and others, think result in better code. And they do — our code’s gotten a lot better in the years we’ve been using this — but there may be a learning curve as you adjust your personal style of writing JavaScript, to the conventions that this tool helps enforce. When you come to debugging, when you ask your colleagues for help debugging code, always have the courtesy to run it through JSLint first, to pick any common ‘gotcha’s. It will save you time, and it means that when you start debugging, you’re starting with all the common things already accounted for.

In terms of optimization, there’s two ways we recommend to think about this, in addition to all the design based ways — but when you’re actually writing the code, two ways to sort of optimize what you’re doing. The first is using YUI compressor to actually shrink the code. Here we’re taking long words and making them short, we’re removing white space, we’re removing comments. If you’ve already run it through JSLint, then this is an entirely safe process. JSLint ensures that all the semicolons are in the right place, for instance, and then when it gets compressed, you’re not going to have any white space issues. So run it through Lint, and then run it through the Compressor, to result in a… not super-human readable, but a very user-friendly, tight, bundle of code. We use YUI Compressor for JavaScript — it also works for CSS. You can pass in a CSS file and it’ll also strip out all the comments and all the white space, and give you back the leannest piece of CSS that still has the exact same impact. Often, this is useful as part of your build process, where when you check in a new piece of code to your source control, it might automatically trigger a build process that runs it through Lint; if it passes Lint, then runs it through Compressor; and then publishes it out to your site.

As we write more and more software in JavaScript, we’re starting to adopt more and more traditional computer science practices — one of those is unit testing. YUI Test is a testing framework for writing unit tests for JavaScript. It’s a simple syntax, it makes it really quick and easy to build unit tests, and it’s got a lot of nice features — it can simulate a lot of DOM events, so you can run things across different browsers, and you can script out what the interaction would be and then see the result. If you’ve got a large body of tests, you can use YUI Test to group them into whole suites of tests — so instead of just running individual tests, you can fire off a whole suite to make sure that your latest check-in to your projects are passing all the tests across the whole thing. After we built Test, we realized that success wasn’t the only metric that should determine whether or not a test passes, and so Nicholas Zakas and the YUI team built YUI Profiler, which helps you identify where in your code things are fast, and where in your code things are slow. So you can run these tests and figure out which methods are the fastest, which ones are the slowest, and then devote your engineering resources to fixing those slow areas first. It’s related to YUI Test because the speed of the profiling can determine whether or not a test passes or fails. You can structure unit tests to automatically fail even if things are working, but if they’re taking longer than you’d like.

And then finally, data transportation — how do we get stuff around? How do we do Ajax at Yahoo!? The answer is through YUI’s Connection Manager. It’s our utility for handling Ajax based communication. It’s got a lot of nice features, it’s got years of edge case learnings built into it. If a certain header is set back on a certain version of IE, this knows about it, it’ll handle that. It’s got nice features like being able to bundle up an entire form and submit that all at once, easily, without needing to serialize those things yourself. When we are doing data transportation, often we’re using JSON, which is JavaScript Optic Notation, fondly referred to as sort of the fat free alternative to XML. It’s a JavaScript native way to pass data around — it’s generally very lightweight, and platform agnostic.

And then the final thing I want to say about data transportation is that any time you’re interacting with a server, you need to start thinking about security. When frontend engineers were primarily working with HTML, and CSS, and little bits of JavaScript, security wasn’t our chief concern — we weren’t doing a lot of things that exposed a lot of security vectors to our code. Now that we’re passing data and information between many servers, all on a single page, in different security contexts, security really becomes an important thing. And in fact, a lot of the key security vulnerabilities these days, across the internet, are related to things within frontend engineering control. So if you don’t know a whole lot about security, there’s a group at Yahoo! called the paranoids, they’re set up as a consulting organization and be happy to come help you understand the security vulnerabilities of your site, and plug some of those holes, if they find any. So in general, just be aware that now that we’re talking to servers all the time, and sporadically, and continuously, security needs to become something that we care about all the time.

So now we’ve gone all the way on one end — what about the other end of the process, what about user experience and design? It’s generally our job to educate and inspire our designers. For a long time, we told them things we couldn’t do — we told them that we couldn’t easily do this particular visualization, or make this move, or do this or that. And I think they got the message right when the answers started to change. And so in some cases, designers have stopped pushing the envelope as hard as they could today — so I think it’s our job, as frontend engineers, to show them what’s possible. To prototype new interactions, to push the envelope on their behalf. Not because we necessarily have the world’s best design sense, but because we know what’s possible in the browser - and so as we determine these new capabilities, to share those with the designers, and encourage them to think about how to bring that to their design. So it’s our job to put tools in their toolbox, and their job to figure out how to use those tools.

Another way to relate to designers is to get involved early. It’s important to understand early on if design is going down a path that’s going to have performance implications, for instance, or in some other way isn’t going to result in the best possible product. Just as we’ve partnered with backend engineers to bring data to the page, we need to partner with designers to make sure that the design vision ends up on the end user’s browser also. The reason to get involved early on — I’ve been thinking of this for a long time — the reason to get involved is that if we don’t, if we don’t fight for the right thing, then today’s compromize becomes tomorrow’s constraint. We really need to make sure that we’re exposing them to the best of what we can do, and the best ways to do those things, so that we continue to have solid footing under us, and we can do more and cooler things in the future.

So now we’ve gone almost all the way around, I just want to wrap up with a few reasons why I think this is all so important. First of all, there’s a lot of work to be done. We need more frontend engineers. We need more people that can invent great interfaces, and bring them to life, and understand the browsers — both their capabilities and their constraints — and build great experiences for users. So there’s a lot of work to be done — we need more people doing it. So hopefully this tour of frontend engineering excites you about what’s possible, and informs you about the different pieces of the puzzle, so that you can start diving in.

Also, the health of the internet itself depends on it, and the health of businesses. If we make the web a better place for users, the web will continue to thrive. If we find ways to make interactions faster, people will be more happy. If we find ways to put more businesses online, and to engage users more deeply, businesses, and the internet as a whole, will thrive. And I think it’s our responsibility, as people who really bring those pieces of the puzzle together, to step up and lead this battle.

Another thing is that we must stay vigilant. There’s continually new technology, continually new browsers — the landscape that we’re working within changes, so we want to always be aware of that. It’s an exciting discipline — you get to touch so many cool pieces of technology, in so many disciplines across the company, and across projects. And so you need to stay alert to all these new developments, and also alert to some of the ‘gotcha’s that pop up here and there.

And then finally, and I think most importantly, is that for me, frontend engineering comes down to supporting users. It’s our job to make sure that they have a great user experience. If they’re using a screen reader, I want to make sure that they’re having the best possible experience with all of our websites. If they’re using a particular browser, or if they want their font bigger, or if they’re on a mobile device — it’s our job to give them that great experience. If they want to rearrange their Fantasy lineup quickly with drag and drop, that’s our job. And we want to be in there doing what’s right for the user. We want to have stubborn empathy for what they need, and what they want, and what they’re going through — what can we do to make all that better?

And then finally, remember that we’re the last line of defense, both in terms of defending the user, and giving them the best possible experience, but also — and more importantly perhaps — in terms of the life cycle of projects. Designers to their work, and product people do their work, and backend people do their work, and it all comes together at the keyboard of a frontend engineer. We’re the ones that stitch it together. We’re the last line of defence before it goes live, before it’s up there as a working site. So if you see bad decisions happen, raise your hand and make them better. If you see an opportunity that we’re not grabbing, get involved and make sure that we are. It’s our job to defend users, and it’s our job to build the next, and the best, internet we can. Thank you.