Browserscope in External Bugs

Annie Sullivan, of our colleagues who wrote the Browserscope Rich Text test suite, let us know today that there are now two issues filed in Webkit and Firefox to track progress in rich text editing by using her Browserscope tests. In webkit: https://bugs.webkit.org/show_bug.cgi?id=35904, and in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=550569. Steve Souders' Network test suite is also mentioned in a few different bugs for both Firefox and Webkit. This is *exactly* the kind of effect we'd hoped to have when building Browserscope and it is a testament to the depth and value of these two test categories that they are to be found in issue trackers for the browser vendors themselves.

We'd love to see this trend continue, and we'd also love to see Browserscope integrated into the continuous builds and test systems employed by browser vendors. Conveniently, vendors can easily run their own private Browserscope instances just for this purpose, which speaks to the benefit of using App Engine for something like this. Recently I've been chatting with some folks on the W3C about porting some of their test suites over to Browserscope as well, and hope to have some interesting news in that department soon ;)

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.

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.

My Most Memorable Mushroom Hunt

I had to turn back. The already-overgrown remnant of a road I had been climbing was becoming more impassable and I was getting this sketchy feeling deep in my bones. I was already nervous. Maybe some dealer/grower was going to emerge from the side woods, shotgun in hand, demanding to know what the hell I was doing on his land. So I started walking back down when I saw one - Dr. Snow had showed me a similar pine tree only hours ago, and told me that when hunting Matsutake, what you're really hunting is this tree. I lifted one of the green, low hanging branches up and there they were - three gorgeous, white-cinnamon mushrooms in a bulge of dirt and pine needles, about two feet from the trunk. My heart was racing. No way. Is this why I had come up here in the first place?! I pulled one of the white giants to my nose - it's unmistakable.

I love hunting mushrooms, and I love the forest. I became interested in mushrooms for the same reason any curious college kid might. The dream of finding a raw, natural magic led me and my willing compadres on too many four am drives out east of Austin. We'd jump short fences off remote country roads and scamper around in the dew, staring into piles of cow manure as the sun came up. After around twenty minutes we'd start yawning with boredom and fatigue, and that was that. I never did find the famed psilocybin cubensis of Texas.

Then I got into cooking. Cooks are like car-loving gearheads when it comes to ingredients. A cook who doesn't want to taste everything the world has to offer is merely a preparer of food. When I made my first wild mushroom dish, chicken with black trumpet mushrooms in veloute sauce, I jumped into the game. I started buying all sorts of dried mushrooms, and fortunately this was about the time that bulk bins started appearing in Texas grocery stores. My selections included porcini, black trumpets, and morels. I remember the time I got ahold of a fresh, black truffle while working in Lupin's kitchen. The chef was too busy doing blow to notice one little missing nugget, so when I got home that night I made up some soft-scrambled eggs and shaved the little gem on top. I was totally underwhelmed. I had come to love the deep, rich, dark earthy flavor of wild mushrooms, and truffles are something else entirely.

Since we moved to California three years ago, I've been making frequent pit-stops down at the Ferry Building store to check on what's in season. I've purchased rare blue chantrelles, queen boletes, perfect morels, and many more thanks to Far West Fungi and Ian. Angela and I have even rented zipcars a time or two to drive out of town for some "hiking" in the forest. Honestly though, on some of our hikes I tend to become a single-minded human radar, scouring the ground for shrooms, and I'm lucky and grateful that Angela is tolerant, supportive, and now also a converted fungiphile.

After meeting local legend Eric Schramm during our last visit, I decided to call him before this trip to see if I might get some info about what the mushroom forecast was, or maybe see about finding a guide or something. He very kindly called me back, and said he could only talk for 30 seconds because things were "fucking crazy up here", but managed to get me a phone number for Dr. Ryane Snow, who we'd read about. I called him up and voila, he had a slot open and we were set for a after-breakfast trip for 10am on Dec. 27th.

Not only did I meet and get to walk with this living legend of American mushrooming, but Dr. Snow is a cool, humble, honest, and brazen hero. He exudes the kind of confidence that comes from knowledgable self-reliability - and he is excited and willing to share what he's discovered from information on medicinal plants, seaweed, trees, botany, to right-brain expansion and thinking visually. We hiked for about three and a half hours in gorgeous, lush, public forestland, picking loads of hedgehogs, candy caps, yellowfoot chantrelles, pig's ears, and a few others. Dr. Snow told me all their names in Latin, helped me learn how to distinguish one from another, and shared my excitement when we came into a particularly abundant patch. We even sampled a russula that was spicy. It would not no exagerration to say that I was completely in HOG HEAVEN =)

We searched low and low for some end-of-the-season matsutakes but alas, had no luck. I had mentioned before our walk that I'd never eaten a matsutake but would like to, and Dr. Snow assured me that they were delicious and special (he affectionately calls them "Matsies"). Lucky for me, Snow was kind and generous enough to give me one to take home from his personal stash, so that I might experience this culinary oddity and magnificence. When he dropped me off at the Stanford Inn, I was grinning from ear to ear.

The Stanford Inn serves an all vegetarian menu, but that does not include lunch - if it had, I would have sat down to eat in bliss. I knew Angela wouldn't be there to pick me up for at least two hours. At first I just wandered around the grounds to acquiesce my hunger - the place is amazing, with lush gardens, and beautiful buildings. But I am addicted - even Dr. Snow pointed this out to me on our walk in case I didn't know already - and within 30 minutes I was stalking the nearby hillside, but still within the cellphone coverage provided by the Stanford, in case Angela called. Initially I came across a lot of russulas and amanitas, but after twenty minutes I'd found two lovely, golden chantrelles. After an hour I had a few more chantrelles, plus a couple of huge hedgehogs. My ankles were starting to become loose and weak from clinging to the steep hillside. At the hour and a half mark I came across that pine tree and those three matsutakes on my own. I was truly fortunate to have that one in my bag from Dr. Snow, to aid in my identification, but the smell of a matsutake is truly telltale, and now I will never forget it.

Security Tests on Browserscope

[The text below is reprinted from stevesouders.org, since it's far better than what I would've written anyway. -Lindsey ;]

Today, the first new test suite for Browserscope was launched: Security.

Browserscope is an open source project for measuring browser capabilities. It’s a resource for users and developers to see which features are or are not supported by any particular browser. All of the data is crowdsourced, making the results more immediate, diverse, and representative. Browserscope launched in September (see my (Steve's) blog post) with tests for network performance, CSS selectors, rich text edit controls, and Acid3.

The new security tests in Browserscope were developed by Adam Barth from UC Berkeley, and Collin Jackson and Mustafa Acer from Carnegie Mellon University. It’s exciting to have these experts become Browserscope contributors. The tests cover such areas as postMessage API, JSON.parse API, httpOnly cookie attribute, and cross-origin capability leaks. See the Security about page to read about all the tests.

This is the point at which you can contribute. We don’t want your money - all we want is a little bit of your time to run the tests. Just click on the link and sit back. All that’s needed is a web client that supports JavaScript. We especially want people to connect using their mobile devices. If you have suggestions about the tests, contact us or submit a bug.

So far we’ve collected over 30,000 test results from 580 different browsers. Want to see how your browser compares? Just click on this button to add your browser’s results to Browserscope.

If you don't like omakase, I don't like you

Or at least, I'll have a really hard time taking your opinions about "good food" seriously. Omakase, or chef's choice, is often the best way to branch out and try new things that you never knew you'd like (or possibly dislike). Last night, me and 9 other folks visited San Francisco's Jai Yun Restaurant for what was one of the greatest Chinese food feasts of my life. If you haven't been and you care about Chinese food and you're nearby, get a reservation ASAP. This morning I started thinking more about this style of dining/eating.

You don't have to go out to a sushi restaurant to experience omakase, though that is context where this word comes from. But the idea that you'd go out to eat, pay some amount of money, and have limited say in what you get is what's important. As I'm not allergic to any foods, it's certainly easier to be voiceless, but again, that's just a detail and has nothing to do with the spirit of omakase.

Do you loathe "prix fixe" meals? Don't take me out to eat. I'll admit that I'm not always in the mood for this, but more often than not, I'm game. It doesn't have to be fancy. It could be some authentic Americana chips and dip at your place, but the point is that it's exposure to something cherished.

When I was in Korea, probably one of the greatest meals I ate was this crazy package-o-ramen soup mixed with spam and hot dogs and spicy as hell. If you told me about the ingredients weeks in advance and tried to get me excited you'd have a hard time, but in the moment, my friend Kihyun knew I'd be up for it, and I'm so grateful he let me experience this meal. He could've taken me out, trying to impress me or something, to eat more crazy sea urchin sashimi, but variety is indeed the spice of life. And Koreans love spicy, oh brother. This soup dish came about as South Koreans were trading with American soldiers during the Korean war, and has become a national pasttime these days - everyone at the restaurant  was eating this spicy, hearty soup for lunch.

So if you haven't done it in awhile, tell the chef at one of your favorite places to surprise you - let him/her make something special for you that they love to cook. Don't think twice and don't waste a bite.

Browserscope & Chrome Frame

I imagine many front end developers out there like me are currently pretty thrilled about the announcement of Google Chrome Frame this week. I've always been an admirer of Alex Russell's writing and work. To be fair though, I was once also a very excited Flash developer who thought I'd end up writing code for a single engine/consumer. I've felt that burn, but I'm still really just a kid at heart - so I'm psyched.

Chrome Frame presented a pretty interesting challenge for Browserscope. I wish we'd solved it fully before this morning. The problem is in detecting the user agent. When it first came out, I thought Browserscope wouldn't need any quick changes due to Chrome Frame, because we wouldn't be serving the <meta http-equiv="X-UA-Compatible" content="chrome=1"> header. Fortunately Steve read about the "cf:" way to run Chrome Frame the next morning - though unfortunately, that meant we had a problem.

Browserscope originally did its user agent classification based on the HTTP_USER_AGENT header sent from the browser when you share your test results. Chrome Frame adds a "chromeframe" string within the IE user agent string, so at first we thought we could detect Chrome Frame based on the presence of that string. But correctly, IE has the "chromeframe" string whether Chrome Frame has been invoked on the page or not (it's still an installed plug-in). And we wanted to be able to distinguish the IE/Chrome Frame results - which someone could submit by going to cf:http://www.browserscope.org/.

So then we thought we could just detect whether the client side render engine was Webkit, which is doable - and it turns out that if you ask the browser for window.navigator.userAgent you get a typical Chrome user agent string (type cf:about:version into IE with Chrome Frame installed). It's kind of a bummer that at the client level, you cannot tell that you're in Chrome Frame versus Chrome proper, but the Chrome Frame team may tweak the Chrome Frame user agent string if enough people also encounter this as an issue. Functionally, it should be a lot more like Chrome proper; Browserscope itself should be able to report if, and if/when that isn't the case.

While we'd anticipated new user agents on Browserscope, we hadn't imagined a hybrid sort of User Agent. We had to make some changes under the hood to support this in the back end (thanks slamm!). Now you should be able to go to Browserscope and compare your test results for IE and Chrome Frame (if you have it installed). Parsing-wise, we're grouping Chrome Frame along with the browser family(IE at this point) and major version bit(6|7|8) in the UI. We'd love your feedback on that decision.

Now, not only can you run the tests on Browserscope in Chrome Frame, but once you do, you'll then experience Browserscope itself in Webkit (check out all the rounded corners and text-shadows). And, how awesome is Webkit?! Of course, you can always toggle the checkbox on the homepage to switch back and forth to IE proper.

This experience reminded us on the Browserscope team how crucial it is to parse user agent "correctly" - and in this case that requires a combination of client and server information! - so I'll make a plea for folks to check out and add comments to a design doc for a user agent string parsing project we'd love to see take shape. Want to build it?