I Dream of Uni

HTML, CSS, and JavaScript from the Ground Up

noreply@blogger.com (elsigh) — Tue, 31 Aug 2010 20:59:00 +0000

One of the efforts I've had the most fun working on at Google was a class that Greg Veen, Ryan Carver, Sean McBride, and Dustin Diaz put together for Googlers to learn more about HTML, CSS, and JavaScript from the UX perspective. That class has, at long last, had its contents made public (at least the screencasts anyhow). I'll be having a Manhattan tonight in celebration of all our hard work paying off =)

Check it out here: http://code.google.com/edu/submissions/html-css-javascript/

Detecting IE Platform Preview (and User Agent detection) on Browserscope

noreply@blogger.com (elsigh) — Mon, 09 Aug 2010 02:17:00 +0000

On Browserscope we've recently encountered the conundrum of wanting to detect the IE Platform Preview branches and the fact that that information is not in the UA string. Right now, just using the new and improved IE 9 UA string offers no way to detect that someone is using a Platform Preview and also no way to tell which of the 4 previews they are using. Fortunately one can detect this stuff using Javascript, but this forced a rewrite of how we handle UA parsing in Browserscope such that we now can send in overrides for each of the fields we care about for a browser at present - the family, v1, v2, and v3 bits. The code is checked in here in case you have a better way of doing it to share. Thankfully, the IE team is doing such a great job documenting the improvements from release to release that it isn't too painful to get this detection right..

You can also check out this code in action on our UA parser test page too and if for some reason your browser isn't being correctly detected, let us know and we should be able to figure out how to get that right.

All of this though brings me back to the fact that there's really not a great, bleeding-edge accurate, user agent parsing library available today that I'm aware of. The best ones out there at present that I know of are browscap.ini and useragentstring.com, but neither of these offer the detection library itself nor are they community maintained and bleeding-edge up to date. There's also WURFL, though it's more about offering a database of capabilities than a universal browser detection tool. Is there something else out there that you know of that's good?

I still have this fantasy of a client library, written to use and cache an ordered list of regexes and patterns for detecting browsers - it would be so cool if this list could be distributed by pubsubhubbub and then any one could host their own, augment the format, or just contribute their changes back to an open source project. Do you know of anyone looking for a fun, meaningful 20% project?

Velocity 2010 Browserscope Talk Slides

noreply@blogger.com (elsigh) — Thu, 24 Jun 2010 17:10:00 +0000

It's a great time for web performance folks here at O'Reilly's Velocity conference in Santa Clara, CA. With talks that correlate performance to dollars and efficiency, it's easier that ever to value website performance.

The slides I'll be presenting for Browserscope are here below.

XmlHttpRequest.getAllResponseHeaders and Content-Encoding in IE7 & IE8

noreply@blogger.com (elsigh) — Fri, 21 May 2010 06:04:00 +0000

A couple of weeks ago we tried to change how our Browserscope Network test for GZIP works and the other night we ran into something peculiar and unexpected - IE7 and IE8 strip the Content-Encoding header for GZIP responses if/when the browser has decoded the response (which it should have). Reading the spec for getAllResponseHeaders, it looks like the only headers which ought to potentially be stripped are Set-Cookie and Set-Cookie2.

The reason this was interesting/annoying is that we were trying to do something other than simply test whether the browser says it can handle GZIP responses (via the Accept-Encoding header) - we wanted to see if Google App Engine was actually returning a GZIP compressed response, in this case for a static CSS file. Looking at the headers from a packet sniffer it was clear that the Content-Encoding header was coming down the wire, but then in JavaScript - it had disappeared. Amusingly, IE6 showed the Content-Encoding header as being present.

When a user-agent decodes a GZIP response do you think it should strip Content-Encoding header from getAllResponseHeaders()?

Ubuntu Lucid Lynx w/ Gnome on the Lenovo T410

noreply@blogger.com (elsigh) — Wed, 19 May 2010 06:50:00 +0000

Maybe it's happened. I've been using Gnome without dying to switch back to fluxbox for like 3 weeks now. The degree to which I can get Gnome out of my way, combined with the fact that some of its niceties no longer seem janky, unpredictable, or brittle... Dare I say I may be converted?
Also, Lenovo's T410 - this may be by far and away the best laptop I've ever used. The peripherals are in good locations - they moved the stereo jack over to the side (where it belongs, it was very peculiarly in front on the T400), moved the phone jack to the back (what's a modem?!), added a powered USB jack, 4+ hours of full screen battery life, and most importantly - I can actually use this thing on my lap!
Ubuntu has made some serious strides with Lucid Lynx. My typical gripes about gnu/linux (audio, suspend, wireless, etc..) are all fading and the configuration and usability of the system seems recommendable to your average consumer - I never thought I'd see it. Wow. Ok, so let's see how I feel in three weeks ;)

User Tests in Browserscope

noreply@blogger.com (elsigh) — Mon, 19 Apr 2010 04:06:00 +0000

It seems like nearly every week we read about an interesting new hosted test for people to visit and run their browsers through (recent examples include html5test.com and findmebyip.com). Developers really love to poke at the black boxes they code for - and the matrix of browsers, OS, and networks is enormous. One thing I, and I presume other developers, would love to see are the aggregated results for these tests by user agent. Considering this is exactly what we built Browser to accomplish for our test categories, and that a user-hosted test feature has been on our Roadmap, the Browserscope team is happy to announce that we're opening up an alpha of our User Tests feature.

Conveniently, this past week a User Tests use case came up for me at work and so it's been a driver for building this feature. We began working on a UI component that we wanted to test for speed of task completion. After building up a test page with a timer and some deltas it dawned on me just how cool it would be to open up this test to the world, and aggregate the results. The test is kind of strange in that the the UI component is out of its context, and you can argue about the mechanics of the test itself, but I still feel like the results may be informative. Interestingly too, this test is exactly the kind of thing we would *not* want to feature on the homepage of Browserscope (it's more of a performance test than a spec/binary test). And yet, the backend system with its median aggregation, scalability, and user-agent parsing library is a perfect fit. So check it out - and see how other people are doing on the test (courtesy of Browserscope).

This is definitely a release early/often feature, and we want to be explicit that things may change or break in the API while we're in alpha mode. We may have to take the service offline briefly to fix things. But if you write tests for browsers and want to aggregate your results, sign in to Browserscope, register your test page and then read the HOWTO to start saving your results in the system. Please send any feedback to me or to our mailing list. We really hope to make this an easy system to use for the tests you're already hosting.

Production versus local development w/ App Engine - pychecker to the rescue!

noreply@blogger.com (elsigh) — Sat, 17 Apr 2010 01:29:00 +0000

This has been a furious week of coding, staying up til 3am, and banging my head on the keyboard. I wish I could say that in the end I feel like I was extremely productive, but there is the voice of rationality in the back of my mind saying I could have done much better.

I've been working on the Browserscope code base to add a feature to make it possible for users to run browser tests on their own servers and then make use of the Browserscope to store their results, download their results, and display their results with ease. We've worked really hard to build a system that should scale and maintain runtime medians (thanks to slamm). It seems like every week I see two or three new browser tests online and yet I don't see people collecting and aggregating the results in meaningful ways. It's hard! Hopefully we'll have this live for people to bang on in the next couple of weeks.

Meanwhile, I want to braindump a few lessons learned the hard way. After four days of intense development using dev_appserver.py I decided to deploy my code to a test app_id and see how it ran in production. I was rather miffed to see that my code was not working, and/or intermittently failing. That is pain.

My debugging experience led me to cut and paste Tracebacks (when I got them!) into Google to look for errors with django's urlresolvers.py file, and a seeming inability to load my custom_filters. But that didn't make much sense to me, and I could find nothing to fix in that regard. So then I started seeing errors about importing modules. And I couldn't reproduce them locally. Pain.

My officemate slamm suggested that I try using the built-in django with App Engine instead of appengine_django. This led me to start rewriting our main.py file. Fortunately, Guido's rietveld app is online on Google Code and contains a, in his own words, battle-worn main.py file which loads Django 1.1. After a fair amount of refactoring and generally feeling like I was making progress (I stopped seeing the errors about my custom_filters not loading after moving the add_to_builtins call into my main.py file), alas, I still kept getting errors loading some module that I could not explain.

So then I found a post in the Google Group mentioning that it can be troublesome to name your modules the same as any of the python system modules. Sure enough, I'd just created a new directory module named "users" (a pretty common directory one might have in a webapp). I got into a python console, and bingo - import users - loaded! Wow, so I then tried to import every directory and filename in my application. What a headache, but in the end, the only one I had named the same as a system module was users. Ok, so refactor and search/replace, not too big a deal. But it didn't fix my problem. Incidentally, Guido explained to me that the reason it is bad to name your modules the same as python system modules is that the sys.path in production puts your application directory at the END of the sys.path, while on dev_appserver it is on the front of the path. So that at least would explain why code that works in dev_appserver would not work in production if indeed you make this mistake. Apparently the fix is non-trivial, but at least it's in the "known-issues" list.

So I decided I had to have a circular import problem. I could come up with nothing else. And finding a circular import is pretty hard, following every import down a tree is very mind-challenging at 3 in the morning (as your app spews 500s). Searching for tools to help uncover recursive imports, I came across a mention of a tool called pychecker online (although it sounds like it has generally been deprecated by most in favor of pylint). Anyhow, I added a bunch of directories to my PYTHONPATH environment variable and ran "pychecker main.py myhandler.py" and bingo! "Error importing module foo". I could reproduce a problem! And it only took about 5 seconds for pychecker to run.. which is significant since my prior debugging path included making guesslike changes to my code, and redeploying (which takes more like 25 seconds) and praying and then banging my head. I found my recursive import, fixed the issue, and wow - no more 500s (well, except for the dynamic request limit ones).

Anyway, I just wanted to post this in case anyone starts searching and finds this post useful. Happy coding!

Browserscope in External Bugs

noreply@blogger.com (elsigh) — Wed, 10 Mar 2010 03:42:00 +0000

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

noreply@blogger.com (elsigh) — Thu, 18 Feb 2010 18:27:00 +0000

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:
The test should check for a behavior that makes the web a safer platform for developing web applications.
The test needs to be able to run without user interaction.
The behavior should not yet have universal adoption among popular browsers at the time it's added to Browserscope.
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

noreply@blogger.com (elsigh) — Fri, 05 Feb 2010 20:26:00 +0000

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

noreply@blogger.com (elsigh) — Tue, 29 Dec 2009 22:17:00 +0000

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

noreply@blogger.com (elsigh) — Wed, 11 Nov 2009 15:00:00 +0000

[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

noreply@blogger.com (elsigh) — Sat, 24 Oct 2009 18:34:00 +0000

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

noreply@blogger.com (elsigh) — Sun, 27 Sep 2009 02:18:00 +0000

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?

Announcing Browserscope

noreply@blogger.com (elsigh) — Mon, 14 Sep 2009 01:01:00 +0000

I'm excited today to announce the release of Browserscope at www.browserscope.org.

Browserscope is an open-source project for profiling web browsers and storing and aggregating crowd-sourced data about browser performance.

The goals are to foster innovation by tracking browser functionality and to be a resource for web developers.

Browserscope is based on Steve Souders' UA Profiler, and his original tests have been preserved here as the Network test category. Other test categories include Ian Hickson's Acid3 test (ported by Jacob Moon into Browserscope), Annie Sullivan's Rich Text Edit Mode tests, and John Resig's Selectors API Test Suite (ported by Lindsey Simon into Browserscope).

The Advantages of Crowdsourcing
The ability for users to contribute results is the key for Browserscope's longevity, accuracy, and currency.

No dedicated test resources are required; enabling the project to run in perpetuity
Tests are run under a wide variety of real world test conditions
Aggregating results reduces selection bias
New browsers show up immediately due to developer testing

And this is where you come in! Click the button below to run your browser through the tests on Browserscope.

Roadmap

Below are some ideas culled from the project issue tracker on Google Code. Do you have some ideas? Add them, or feel free to checkout and work on the code. We'd love to get your patches (as directory diffs) and review those for inclusion in Browserscope!

Visualize test result trends over time
Wall of fame, up-and-comers, Billboard top 50
More test categories - cookies, security, reflow
More contributors
Tagged/personalized test results
Normalize time-based results across platforms
User agent parsing library

Links

http://www.browserscope.org/
Code: http://code.google.com/p/browserscope/
Contact the team: http://groups.google.com/group/browserscope

Thanks

I want to extend my sincere and deep gratitude to everyone who's offered feedback, worked on the codebase, or otherwise helped Browserscope along. Specifically I want to thank:

Steve Souders: you've been a great mentor to work with, and your ability to think BIG and beyond is something I hope continues to rub off on us all a little ;)

Steve Lamm: I've never worked with anyone who writes code that is of such high quality and readability. Browserscope's backend would not be the same without you.

Annie Sullivan: You're quick, wise, and totally fun to work with - I also really hope that Rich Text Edit mode development will get easier thanks to your dedication.
John Skidgel: Design master, cohort, and all-around tolerater - you love problems, you has solutions.

Brett Slatkin and the App Engine team: Your insight into the overall system design was critical to our being able to deploy this on App Engine, and the Task Queue API rocks.

Jacob Moon: We sure got lucky that you provided the first outside-the-project developer experience! Thanks for bringing the Acid3 tests (and others) into Browserscope and for showing us how doable it is to port new tests into the system.

Christian Stockwell and the IE team: Your feedback was essential to uncovering issues regarding selection bias, hopefully the reflow tests will make their appearance again soon once we've done some more to address this issue.

Mike Belshe and the Chrome team: Your advice and feedback re: benchmarks versus compatibility testing was crucial. Yall run the tightest ship on the planet and it shows, i <3 Chrome.

David Baron, Dion Almaer, Ben Galbraith, John Resig and the Mozilla team: Your ideas and suggestions are present in many parts of the codebase - and additionally I couldn't have made the site look nearly as decent without using Firefox.
Robert Bowdidge: Thanks for inspiring me to work on this.

Lastly a big thanks to Google for giving me 20% time to work on this project for the last year.

Go With the Reflow

noreply@blogger.com (elsigh) — Wed, 24 Jun 2009 00:54:00 +0000

Posted my slides to SlideShare: http://www.slideshare.net/lsimon/go-with-the-reflow

Speaking at Velocity about reflow next week

noreply@blogger.com (elsigh) — Wed, 17 Jun 2009 20:01:00 +0000

Hey - if you want to talk reflow and render time, come to Velocity next week. I'll be giving a 15 minute presentation on the subject. See ya there.

Clearing floats without overflow hidden

noreply@blogger.com (elsigh) — Sat, 09 May 2009 00:58:00 +0000

Clearing floats is a topic near and dear to web developers fighting with CSS to produce grid layouts. There are a number of methods to do this, but not all work well in all situations. I wanted to mention one I'm using at work at Google that's gotten pretty good mileage so far in ways that others have not.

Our grid system is very similar to Yahoo's - it's designed to nest two units inside of a container and then further nesting takes place in one of the two units. Our system can scale to infinite nesting in browsers that support first-child selectors, and for those that don't we bake a nasty mix of descendent selectors to achieve a baseline of 4 levels of nesting (which seems pretty sufficient for most projects).

A fixed layout of 180-px on the left and fluid on the right looks like this in HTML:


<div class="g-section g-tpl-180">
  <div class="g-unit g-first">
    <div class="box-1">1</div>
  </div>
  <div class="g-unit">
    <div class="box-2">2</div>
  </div>
</div>

This grid/horizontal column layout is done in CSS by making the g-first element float:left and then have a fixed width:180px then the second g-unit float:none and margin-left:180px. So, since something is floating here, we want our g-section to contain it.

For containing floats, here's what I've found:
* Clearfix is nice, but doesn't work when nesting sections within units, so for our framework it is useless.
* Faux Absolute Positioning is pretty cool, but doesn't mix well on pages that don't adopt this approach whole hog (i.e. everything has to be inside of a div with class="line". So that's out.
* overflow:hidden - Overflow hidden for a CSS framework is like using crack - it's solves the immediate problem nicely, but as things build up and edge cases kick in, it's unsustainable and gross. Hiding parts of the UI and not providing users with a scroll bar is just plain wrong, even if it makes your design "look" good still. All sorts of things in Web Apps will get you into this situation - dynamic-width/column data tables, form input elements, images, etc.. Cutting them off and asking your user to get a bigger screen is wretched.

I'm going to paste the code and comments I'm currently using for g-section below. Hopefully it will be of use to someone stumbling across this. I have unit tests that test against float-drops and sizing of the template is all the basic cases as well as cases where the sections are nested up to 4 in depth as well as nested inside of floats. ~~This last case is one where I'm noticing some issues related to how width of the outer float container gets calculated - but that's a subject of a whole other post.~~

Update May 10: So it seems that the fix for a pure float-left container is to set width to be auto for the outer container and then display: inline for nested g-section's. If that makes sense then you'll be happy to hear it solves the problem of width aggregation for the inline-blocks!

I welcome your suggestions - thanks!


/**
 * g-section fundamentally has to clear floats. There are many ways to do this.
 * This technique is nice because it doesn't rely on overflow: hidden, which
 * has the potential to hide your content in situations where a fixed size
 * node takes up too much space (like a big table, or a text input or image.
 * Works in Webkit, IE8, and FF3.
 */
.g-section {
  width: 100%;
  vertical-align: top;
  display: inline-block;
}

/**
 * IE7-only hack. Nicely IE7 will clear floats with just block display
 * and hasLayout.
 */
*:first-child+html .g-section {
  display: block;
}

/**
 * IE6 cannot hang with overflow: visible. If we use the IE7 display block
 * trick in IE6 we get severe float drop in nested grids.
 */
* html .g-section {
  overflow: hidden;
}

/* FF2 can't actually hang with overflow: visible. */
@-moz-document url-prefix() {
  .g-section {
    overflow: hidden;
  }
}

/**
 * FF3 now needs to be reset after the previous block which affects it as well.
 * We target the tt element in this hack because no one uses it.
 */
@-moz-document url-prefix() {
  .g-section,tt:default {
    overflow: visible;
  }
}

/* Forces "hasLayout" fixing a gamut of bugs in <= IE7. */
.g-section,
.g-unit {
  zoom: 1;
}

How do you know it's NYE on your gnu/linux box?

noreply@blogger.com (elsigh) — Thu, 01 Jan 2009 00:10:00 +0000

4562.736000] Clock: inserting leap second 23:59:60 UTC

X3: Reunion for Linux Unboxing!

noreply@blogger.com (elsigh) — Tue, 30 Dec 2008 18:20:00 +0000

There aren't many times that the words linux and game end up in the same sentence with the word wow, but LinuxGamePublishing has released a special edition of X3 for linux, and not years after the original release of the game. This is quite a feat of engineering, not to mention an expression of dedication and passion. I wonder how many GNU/Linux users out there played elite? My hunch is a bunch. How I never came across the X series in my many searches for "games like elite" I'll never know, but this year I got myself the box set for Christmas and I'm proud to present the unboxing pictures to all you nerds out there ;)

So without further ado, the pics (I'll post something like a review at some point too).

Why I Hate Flash

noreply@blogger.com (elsigh) — Fri, 03 Oct 2008 21:56:00 +0000

Opera Revisited

noreply@blogger.com (elsigh) — Wed, 23 Apr 2008 02:04:00 +0000

After having played with FF3-beta5 for the last couple of days I can't believe I tolerated FF2 for normal web browsing. Granted, I use the Firebug plugin, but I had come to accept 5-10 seconds waits for opening new windows and 2-4 seconds of latency in switching tabs. Unfortunately, Firebug for FF3, and FF3 in general, is buggy/crash-prone on linux.
So here I am trying Opera again after a couple of years. I still have FF3 running with Firebug
for web development purposes but I think I refuse to use FF2 anymore.
So I'm about to try Konqueror too. All in all - not liking it. Speed dial is useless compared to the bookmark bar. The snapshot mini-page is not something I'm keen on at all - I can't actually read that stuff, and I don't need visual recognition
in grand scale to know which one is my email. The default ui widgets just look lame now too compared to FF3's nice slight rounding.
I probably would continue using Opera for awhile if it could have at least imported my bookmarks.html file from Firefox correctly. I ended up with an empty directory called "Netscape Bookmarks". =/

OTMFF - The Webapp is coming

noreply@blogger.com (elsigh) — Mon, 07 Apr 2008 06:29:00 +0000

SXSWi 2008 - Filching Design Panel

noreply@blogger.com (elsigh) — Fri, 07 Mar 2008 19:40:00 +0000

Luke Wrobleski, Skip Baney, and myself are hosting a panel at SXSW this year titled "Filching Design" - it's going to be lots of fun and hopefully contentious too. Here's the intro slides, still being edited, tweaked...

Windows Error

noreply@blogger.com (elsigh) — Wed, 14 Nov 2007 00:47:00 +0000

I had used vncviewer to test things out on a shared windows box. I came back to my desk to find this beauty on the screen.