I abbreviated the title here a bit because the talk was really just about CSS3. Nicole Sullivan provided some useful tips about dealing with CSS in general, especially some of the features of CSS3.

As usual, the overall name of the game is graceful degradation with good performance. While IE6 (which we will seemingly never be rid of) does not support any of these features, that may not be a big issue. Rounded corners, drop shadows, and transparency can just become square corners, no shadow, and opacity. Is that really a huge issue? Will the IE6 users be saddened by not having rounded corners? How will they know unless they have a newer browser somewhere?

There are other features that won't degrade as well. The provided example was the carat in a breadcrumb. There's a unicode character that you can use in the CSS to provide this, but it won't work in IE6. You need to provide some sort of explicit fallback here.

In the end, it's about balance. You need to find a good compromise in the middle.

Then, we got into the tips. There were a few really notable tips. First, we'll talk about CSS selectors. I didn't know before this that they are evaluated right to left. The browser will use the right-most constraint to find all the elements that match and then traverse up the tree until the matches are weeded out. At first, this seems absolutely terrible. If you think about the actual way the DOM and selectors are implemented, it starts to make sense why this happens. Traversing from the root up the tree is painful because a child selector may not be immediately beneath the parent. It could be several levels deep. Starting from the deepes part makes the most sense, algorithmically. This also means that selectors ending in a * begin with ALL elements in the DOM and filter from there. That's a very bad idea.

Additionally, regex and attribute selector patterns are considerably slower (for fairly obvious reasons), so they are also discouraged. The real shock (which also makes sense when you really sit down to think about how the browser has to work) is that specifying something like "div.foo" is slower than saying ".foo". This is because the class is found first, then they make sure that it's a div tag that was found. I don't believe that there is a drastic difference, but you shouldn't really have classes that are shared among different tag types if you want them to behave differently on the tag types in question.

Finally, Nick Zakas and Nicole announced at the end that they had written a new CSS Lint tool that covers all of this and more. It's written in JavaScript, and they open sourced it right in front of us on github. If you have ideas, you should go and look at it. They are happy to take more rules.

Max Firtman started off by saying that we are guilty and that users hate us. In fact, he hates us. Then, he gets down to business.

Most of the things we take for granted in desktop usage are worse in mobile applications (network, latency, hardware). The experience and context are also very different. The browsers will behave differently than their desktop counterparts. He put up the headers from a feature phone. The accepts header was absolutely obscene. It enumerated exactly everything that the device can handle. You'll never see that large a header on a desktop.

Mobile browser issues abound. There are tons of them, most of them limited. Some are proxied while others directly access the sites. Most of them have no documentation, name, or debugging tools. His suggestion for dealing with the lack of debugging tools (whether on the device or in an emulator) is proxies. His recommendations are Charles Proxy or Fiddler. The proxy can help you understand the network traffic that you would usually see in a waterfall chart. For real devices, he also provided some other options, but I think the proxy is probably the best option. He did provide an option for doing some on-device JavaScript debugging, but I am very suspect about the impact of the performance of the site's JavaScript.

For some statistics, not surprisingly smartphones are the smallest part of the market and the largest part of the usage. The inverse is true for feature phones.

"We need to forget about pixels." I cannot be happier with this statement.

He also mentioned (for the 2nd time I've heard it) not always being connected. The idea of having enough data loaded onto the device to continue using the device in a degraded way until the connection comes back is very interesting. When he expended on this, he talked about an application cache that can be built in so that you can load the page with no connection. It's cool, but the way to have a robust (and updatable) cache is to basically use your own. The base page has to be very small with a bit of JS to determine if the cache is dead. I don't really like that hack, but it may be the only way with how things have been implemented.

He makes a very interesting point about mobile versions of sites. First, you should not redirect. His United.com example shows that over 1 second was spent on the iPhone redirecting twice (once to www.united.com, and then to mobile.united.com). Second, the search engines don't care if you are providing different content on the mobile version of the site. We are always talking about these things on the desktop platform, but it applies even more to the mobile platforms.

There is also the problem of complexity. We can occasionally see difficulties in processing the DOM on desktop platforms. It's even worse on mobile. That processing time is precious. The same applies to CSS and JS parsing. Those are worried on desktop platforms. Imagine how much time they probably take on an older mobile phone. I can hear the batteries screaming.

It's kind of worrying (and comforting, perhaps) that the same issues come up in poor implementations on both desktop and mobile platforms. One example provided is a hyperlink with no href. This is just poor behavior in general.

He has some really interesting ideas about how to trim sites down. A lot of designers ask us to provide background images, icons, etc. that make the site look nice. It really hurts to get those complex designs on mobile devices, though. The design is often lost on the user. Since CSS3 supports gradients, you can still get a lot of the effects that people love to put in designs. Interestingly, the support of sprites and inline images are also heavily supported on mobile platforms. The difficulty here is that you need to figure out if the device requesting actually supports these features. Since this can change the CSS (and/or images) you provide to the user, you have to do this or risk breaking your user experience.

The cool thing idea he also provided was a way to use canvas to draw the arrow (sideways carat) that was used on the original design. Canvas can create a data URL so that you can use that in the same way you might use an inline image. Unfortunatley, this is only available on the latest versions of browsers for mobile platforms. I wish I could force people to upgrade their browsers (both desktop and mobile) so that I can use some of these newer features without all the pain of browser detection, which is traditionally so error-prone. That said, he makes a big point out of providing the experience but not being too concerned about the support level. This is easier said than done, but a well-created design will degrade gracefully without certain capabilities.