Yahoo! User Interface Blog

YUI Theater — Charles McCathieNevile: “Opera Dragonfly”

One of the first YUI Theater videos years ago was published after Joe Hewitt came to Yahoo! to talk about the 1.0 release of Firebug, and back in those days Firebug was a paradigm shift — it had a convenient interface that combined DOM inspection and debugging, and it allowed developers to finally put the venerable Venkman on the shelf.

The Firebug model has penetrated into other browser families today, and today IE8 and Safari both have capable developer tools while Firebug soldiers on in service to Firefox. None of the tools is perfect, but Firebug has served as a good proof-of-concept for what a multipurpose, extensible inspector/debugger toolkit can do.

Opera is now innnovating on this front as well, and Charles McCathieNevile, Chief Standards Officer, stopped by Yahoo! on May 26 to tell us about their latest effort: Opera Dragonfly. Dragonfly will work with Opera 9.5 and later, and it’s a novel approach — implemented as a widget using JavaScript and CSS and proposing a new “Scope API” that (if agreed upon by browser makers) could allow for a common debugging platform. Dragonfly is fully open-sourced.

Slides from Charles’s talk are available as zipped HTML files.

The embed from Yahoo Video follows; a higher-resolution version, along with a transcript, is available from the YUI Theater site.

download (m4v)

In Case You Missed…

Some other recent videos from the YUI Theater series:

• Todd Kloots: Developing an Accessible Web 2.0 Widget Framework
• Satyen Desai: YUI 3: Design Goals and Architecture
• Peter-Paul Koch (PPK): JavaScript Events
• Jenny Donnelly: Hacking with YUI

Subscribing to YUI Theater:

• YUI Theater RSS feed
• YUI Theater on iTunes

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

YUI Theater — Todd Kloots: “Developing an Accessible Web 2.0 Widget Framework”

As we continue to work on YUI 3, we’re thinking hard about accessibility. And no one here is thinking harder about that topic than Todd Kloots, who has authored a variety of blog posts on the subject as well as presenting a comprehensive tech talk on the art and sciense of accessible development.

Todd spoke to Yahoo! frontend engineers recently about the lessons learned in developing the accessibility features for YUI 3, and we’re happy to share that session with you here. For direct techniques to use in your own development, refer to Todd’s previous video; this session will take you into the higher level considerations that guide accessibility strategy in a complex system.

Slides from Todd’s talk are available as a zipped Keynote file here.

The embed from Yahoo Video follows; a higher-resolution version, along with a transcript, is available from the YUI Theater site.

download (m4v)

In Case You Missed…

Some other recent videos from the YUI Theater series:

• Satyen Desai: YUI 3: Design Goals and Architecture
• Peter-Paul Koch (PPK): JavaScript Events
• Jenny Donnelly: Hacking with YUI
• Nate Koechley: Professional Frontend Engineering

Subscribing to YUI Theater:

• YUI Theater RSS feed
• YUI Theater on iTunes

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

YUI Theater — Satyen Desai: “YUI 3: Design Goals and Architecture”

The team here remains hard at work on YUI’s next-generation codeline, YUI 3, which is available as a documented preview release today and which is already powering some of Yahoo’s next-generation projects. As we get closer to the beta release this summer, we’re spending more time talking about YUI 3’s distinguishing characteristics. Satyen Desai, a Sr. Engineer on the YUI team and one of the key YUI 3 developers, gave a talk last week here at Yahoo about the design goals for YUI 3 and the architectural decisions that were driven by those goals. We’re happy to share video from that event here on YUI Theater.

Slides from Satyen’s talk are available as a zipped PowerPoint file here.

The embed from Yahoo Video follows; a higher-resolution version, along with a transcript, is available from the YUI Theater site.

Satyen Desai: "YUI 3: Design Goals and Architecture" @ Yahoo! Video

download (m4v)

In Case You Missed…

Some other recent videos from the YUI Theater series:

• Peter-Paul Koch (PPK): JavaScript Events
• Jenny Donnelly: Hacking with YUI
• Nate Koechley: Professional Frontend Engineering
• John Resig: The DOM Is a Mess

Subscribing to YUI Theater:

• YUI Theater RSS feed
• YUI Theater on iTunes

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Tags: SatyenDesai, yui3, yui, yahoo, javascript, webdevelopment

YUI Theater — PPK (Peter-Paul Koch): “JavaScript Events”

PPK (Peter-Paul Koch) of Quirksmode has been sharing his research into browser quirks for years, and this year he’s turned his attention to mobile browsers while doing a consultancy for Vodafone. That work has got him thinking about JavaScript events once again, and, as is his habit, the results of his research are freely available to the rest of us on Quirksmode (big-screen browser compatibility tables; mobile browser compatiblity tables).

PPK was in California last week and he was kind enough to visit Yahoo and deliver a tech talk outlining some of the interesting browser-event work he’s been doing. We’re happy to share that talk with you on YUI Theater. Slides from PPK’s talk are available in PDF form here.

PPK (Peter-Paul Koch): "JavaScript Events" @ Yahoo! Video

download (m4v)

In Case You Missed…

Some other recent videos from the YUI Theater series:

• Jenny Donnelly: Hacking with YUI
• Nate Koechley: Professional Frontend Engineering
• John Resig: The DOM Is a Mess
• Nicole Sullivan: Design Fast Websites (Don’t Blame the Rounded Corners

Subscribing to YUI Theater:

• YUI Theater RSS feed
• YUI Theater on iTunes

Transcript: PPK, “JavaScript Events”

Peter-Paul Koch: Thank you for inviting me, once again, to speak at Yahoo!. I’m PPK: Peter-Paul Koch, but everybody calls me PPK. It’s a long story. I run a site called http://quirksmode.org, where you can find information about browser incompatibilities. And I have a Twitter account, obviously — who doesn’t?

And today, here at Yahoo!, I’m going to talk about JavaScript events. And I sincerely hope I can teach you something. That’s always the question when I speak for a Yahoo! audience, because you guys already know so much, I have no idea what I can contribute to it. But anyway, we’re going to give it a try. I am going to talk about JavaScript events.

It was about a year ago that I started some serious research into JavaScript events, and I published some compatibility tables. What I basically was doing, was testing the compatibility of all the common events, in all the common browsers. And there’s several things surprised me in that research. Some of these things are what I’m going to talk about today.

If you don’t know where my compatibility table is, here at http://quirksmode.org/dom/events. Use it to look up some complicated events stuff that you want to know about.

Today, we’re going to talk about four things. First of all, I’m going to give a quick introduction to the key events, because there is some confusion, sometimes, about exactly how they work. Secondly, I’m going to talk about the change event. It’s one of my absolute favorite events in the whole of JavaScript – unfortunately, it hardly works, and I’m going to talk about that. Thirdly, I’m going to talk about delegating the focus event. Event delegation, you’ll probably know about that – I’m going to give a very short introduction later on. Event delegation usually only works with a mouse and key event, but I’ve found a way to have it work with focus, and other interface events too, and I’d like to share that with you. And finally, I’m going to present the first results of my test of mobile events – and the results are weird, I can tell you that already. I’ll show you that later on.

But first: the key events. It all seems so simple. There are three key events – keydown, keypress, and keyup. And people generally think they know exactly when they fire. I’m here to tell you that it isn’t always as clear as you think it is.

Let’s go through some quick definitions. The keydown event fires when a key is depressed by the user, and it keeps on firing as long as the user keeps it depressed. That’s simple. The keypress event, basically that’s the same, except that it fires only when a character key is depressed – in other words, a key that will lead to a character being inserted into, say, a textarea. Finally, the keyup event fires when the user releases the key. Well, that’s all pretty simple.

Just to make absolutely sure that everybody understands – if I press, say, an ‘o’ key, or an ‘i’ key, or one of these strange bracket keys, both a keydown and a keypress event will fire. On the other hand, if I press special keys such as the shift key, or the arrow keys, only a keydown event will fire.

This theory of the difference between keydown and keypress originated with Microsoft. All the Internet Explorer versions actually use this difference between keydown and keypress. And Safari has copied it, as from version 3.1, I think, which was released about a year ago, maybe slightly more. The point is, here, that this theory is the only theory about the difference between keydown and keypress in existence. In contrast, Opera and Firefox just fire lots of events at you all the time, because it is tradition that it is both a keydown and a keypress event, so we should fire both whenever we see an opportunity. Which is fine, but it doesn’t explain why there should be two events, instead of just one: the keydown event. So that’s why I kind of like this theory of the difference between keydown and keypress.

So, let’s repeat it once more. Keydown fires when a key – any key – is depressed. Keypress fires when a character key is depressed. And as we can see here, it works in IE, and in Safari. Oh, and I don’t have Google Chrome items here yet, but assume that anything that works in Safari also works in Google Chrome. They are really quite close, these two browsers.

OK, so let’s move on to some practical questions. Usually when you write a script that detects user keys, he wants to know which key the user pressed, and do some interesting interface stuff based on that.

Now, there are two properties that any key event carries – those are the keyCode, and the charCode properties. And there are also two bits of data you might want to know about – the key code, and the character code. And the difference is, the key code is the actual code of the physical key the user depresses, and the character code is the code of the resulting character. So, if I press an ‘a’ key, I get key code 65, because the ‘a’ key has the code 65. But the character code is 97, for a lower case ‘a’. If I press a shift key, I get key code 16, because that’s shift – but I do not get a character code, because the shift key, by itself, doesn’t result in any character. Well, that sounds simple.

So we have one property – we have, actually, two properties, and two bits of data. And having one property containing one bit of data, and the other property the other, would of course, be far, far too simple. It would mean that you don’t need a specialized content engineers, that anyone can just write a key script, which is obviously not the idea.

So, what exactly is going on? It’s pretty complicated, actually, and frankly, I do not understand entirely why it should work like this. But it does work like this. The keyCode property. With a keydown event, onkeydown, it contains the key code – the code of the physical key the user depresses. Onkeypress, on the other hand, contains the character code – basically, the ASCII code of the character that appears on the screen. And this works in all browsers – except that in Firefox, onkeypress shows zero for key code; don’t ask me why. Then, charCode. Onkeydown, charCode returns zero, and onkeypress, charCode returns the character code. And this, too, works only in Firefox and Safari, because these are the only browsers to support charCode.

Let’s move on to something really practical. If you need the actual key that the user depressed, the physical key, use the keydown event and ask for the keyCode. That will work in all browsers. On the other hand, if you needed the character the user has just entered in a text area, or whatever, you should use the keypress event, and ask for either keyCode or charCode – one of them will contain the information you’re looking for in the browser.

Finally, sometimes you want to prevent the default action of a key. I’m especially thinking of arrow keys. Suppose you have a keyboard accessible drag and drop menu, and then you want the user to be able to manipulate the drag element by the arrow keys, and you want to cancel the default of the arrow keys – namely, scrolling the page. Basically, you should do that onkeydown, because, as I said before, keydown fires when any key is depressed, and keypress only fires when character keys are being depressed. Unfortunately, this does not work in Opera – and I must admit I did not test it the latest Opera, so it might have changed there. And preventing arrow keys in Opera is something I’m not going to talk about today, because frankly I forgot the answer.

That concludes the key events. It is not really complicated, all those key events, but you have to be aware of the difference between keydown and keypress.

Now, the change event. In theory, the change event would be absolutely wonderful to have, because the change event fires when the value of the form field is changed. Often, you want to detect everything the user does in a form – for instance, onformsubmission, you of course want to go through all form fields and validate them. But there’s also ways of making a form – or form fields, checkboxes for instance – a kind of menu that the user can use to go through a complicated interface. And what you want to do, always, is see what, exactly, that the user changed in the form. And in theory, the change event would be absolutely wonderful for that.

But usually, we are forced to use the focus or blur events instead – or maybe the click event, in the case of detecting a checkbox changes – because the change event doesn’t work quite correctly. We’re to distinguish three different cases. First of all, the change event of text fields; second, on select boxes; and third, on checkboxes and radios.

We start with text fields. And I suppose the user focuses on a text field, in any way, either by the mouse or the keyboard, and then blurs again. In other words, he moves on to the next field. In that case, no change fires, because there’s nothing that has changed – the value of the text field has not been modified. But if we change it slightly – if we say the user focuses on the text field, and then enters something, then blurs the text field, then a change event fires at the moment the user blurs the text field. Because the value of the text field has been modified, and that obviously causes a change event. This is all good; this works perfectly in all browsers.

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

YUI Theater – Jenny Donnelly: “Hacking With YUI”

• Video transcript

Jenny Donnelly is the author of YUI’s DataSource, AutoComplete and DataTable components and the lead editor of YUIBlog. In this session, “Hacking with YUI,” Jenny provides an overview of the library and some strategies for leveraging its power in a rapid prototyping environment.

Jenny identifies four key problems that YUI helps to solve:

1. Bringing data into the page dynamically;
2. Providing widgets that help build out the UI;
3. Providing widgets that allow the user to interact with information;
4. Providing mechanisms for making data user-editable.

Slides and code samples from Jenny’s talk are available for download.

Our thanks to Eric Wu for organizing the Hack Day sessions and for allowing the YUI Theater crew to shoot Jenny’s talk.

Jenny Donnelly: "Hacking with YUI" @ Yahoo! Video

download (m4v)

In Case You Missed…

Some other recent videos from the YUI Theater series:

• Nate Koechley: "Professional Frontend Engineering" (Yahoo! Video | .m4v download)
• John Resig: "The DOM Is a Mess" (Yahoo! Video | .m4v download)
• Nicole Sullivan: "Design Fast Websites (Don’t Blame the Rounded Corners" (Yahoo! Video | .m4v download)
• Todd Kloots: “Developing Accessible Widgets Using ARIA” (Yahoo! Video | .m4v download)

Subscribing to YUI Theater:

• YUI Theater RSS feed
• YUI Theater on iTunes

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

YUI Theater – Nate Koechley: “Professional Frontend Engineering”

Nate Koechley, one of the first frontened engineers hired at Yahoo, has spent the last eight years studying the discipline and curating some of the best ideas and practices to emerge from it here at Yahoo. As a member of the YUI team since its early days in 2005, he also helped shape the YUI library and authored its CSS components.

This YUI Theater entry captures one of the courses Nate has taught at Yahoo, “Professional Frontend Engineering.” It covers the foundations of the discipline, some of its core ideas, and some of of its best practices. If you are looking to reset your own assumptions about “web development” or “frontend work”, I know of no better place to start. If you have friends who are new to the discipline, or backend engineers transitioning to the frontend, this is also a fantastic resource to which you can point them.

• Transcript — Nate Koechley: “Professional Frontend Engineering”

Nate Koechley: "Professional Frontend Engineering" @ Yahoo! Video

download (m4v)

In Case You Missed…

Some other recent videos from the YUI Theater series:

• John Resig: "The DOM Is a Mess" (Yahoo! Video | .m4v download)
• Nicole Sullivan: "Design Fast Websites (Don’t Blame the Rounded Corners" (Yahoo! Video | .m4v download)
• Todd Kloots: “Developing Accessible Widgets Using ARIA” (Yahoo! Video | .m4v download)
• Nicholas C. Zakas: "Test-Driven Development with YUI Test" (Yahoo! Video | .m4v download)

Subscribing to YUI Theater:

• YUI Theater RSS feed
• YUI Theater on iTunes

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

YUI Theater — John Resig: “The DOM Is a Mess”

John Resig, an engineer at Mozilla and the creator of jQuery, stopped by Yahoo last week to visit with the YUI team. While here, he gave a talk for Yahoo engineers on the current state of JavaScript and DOM programming. The session — entitled “The DOM Is a Mess” — harvests many of John’s insights from his work on jQuery and related projects, and it offers guidance about how to think about some of the most challenging aspects of in-browser software development.

Our thanks to John for the visit and for allowing us to share his talk with you here on YUI Theater.

• Slides (on SlideShare)

John Resig: "The DOM Is a Mess" @ Yahoo! Video

download (m4v)

In Case You Missed…

Some other recent videos from the YUI Theater series:

• Nicole Sullivan: "Design Fast Websites (Don’t Blame the Rounded Corners)" (Yahoo! Video | .m4v download)
• Todd Kloots: “Developing Accessible Widgets Using ARIA” (Yahoo! Video | .m4v download)
• Nicholas C. Zakas: "Test-Driven Development with YUI Test" (Yahoo! Video | .m4v download)
• Douglas Crockford: "Web Forward" (Yahoo! Video | .m4v download)

Subscribing to YUI Theater:

• YUI Theater RSS feed
• YUI Theater on iTunes

Find conversations: bloglines | technorati

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Tags: johnresig, dom, javascript, yuitheater