Thursday, February 18, 2010

Updates to the Browserscope Security Tests

Since the launch of the security test suite on Browserscope, the team who owns those tests have been busy taking in feedback and deciding what to change and what their criteria should be for those changes. Security is a loaded term, and Browserscope aims to be a particular sort of resource - part benchmark, part feature-checker, and part-resource. Collin Jackson has written a great explanation, titled What Makes A Good Browserscope Security Test? His post provides details about all the new changes to the security tests that went live with today's Browserscope push as well as provide some context for how the team made choices about what to change. 

From his post:

Our goal for the Browserscope security suite is to encourage openness and innovation in browser security. Here are some of the essential elements of a good Browserscope security test:
  1. The test should check for a behavior that makes the web a safer platform for developing web applications.
  2. The test needs to be able to run without user interaction.
  3. The behavior should not yet have universal adoption among popular browsers at the time it's added to Browserscope.
  4. The test should be applicable and realistically attainable for all major browser vendors.

With the exception of rule #1, the last three are right in line with the conversations that the Browserscope team has had about what sort of categories we want to have tests for. I think every category owner should be able to come up with their own rule #1 as the description and justification for their category.

Big congratulations go out to Collin Jackson, Adam Barth, Mustafa Acer, and David Lin-Shung Huang for translating their thoughtfulness into code which should help inform users and developers when making choices about which browsers to use and which browsers are more secure.

Friday, February 5, 2010

Re-Recreating the Button

This post owes its inspiration to Doug Bowman's excellent post from about 1 year ago, titled Recreating the Button.

What's changed since Doug's post?

  • -webkit-gradient and -moz-gradient(>= FF3.6) support for backgrounds. (IE has had the Gradient filter since 5.5)
  • -webkit-border-radius and -moz-border-radius work pretty much flawlessly, and degrading to square corners is currently in vogue.
  • I've seen several projects implement this div/span button implementation when a native control would be much more appropriate.

So using the spec that Doug and others came up with, I wanted to see how close I could get to it using un-nested anchors, spans, and divs, but much more notably - native inputs and buttons. JavaScript buttons are fine, but native buttons can degrade. There's few things as horrible as clicking a form submit button and having nothing happen due to a JavaScript error. The implementation has not been all that easy in the end. Many times I've thought I had it only to be thwarted seeing the result in some other browser and going back to the drawing board. For now I've got a CSS file and a unit test page which represents what I'd like to achieve and how close (and sometimes how far!) I am to getting there.

I'll continue to update the test page as I hear from folks about what is and isn't breaking, but in the meantime, I'm happy to report that the test is passing on all A-grade browsers (with the exception of Safari on Mac - hopefully some nice Mac folks can clue me in on what to change to get it working I am not sure about Mac, but Safari 4.04 on Windows passes all the tests now).

The test page shows off something I've found really helpful as a UI developer: unit testing of computed styles in different browsers (in this case, making use of closure-library's goog.testing.jsunit module). Having a page like this makes it much easier to discuss and document anomalies and provides a lot more assurance when making adjustments. We all tend to test our work in one browser and then go through the process of making tweaks for others, but it's crucial to be sure that a change for one doesn't botch something in another. Specifically, this page documents a few use cases that I didn't originally set out to solve, but which now seem like big wins - namely, the icon-buttons as well as the buttons in fixed width containers. Of course there's no way to unit test for everything. Many of the browser-specific tweaks to the padding are specifically for visual consistency inside the button, so testing the padding would be a joke. To that end, I have to plug the free Adobe BrowserLab, which I used constantly while developing this code.

This is still something of a work-in-progress, but you can look forward to seeing these buttons, and some correspondingly styled select elements, in the next App Engine Admin Console release and ultimately the closure-library.