Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

American? Voting age?

Then please do yourself and your family a favor and read this piece by T.R. Reid on how health care in the rest of the world actually works (hint: better, cheaper, faster).

It distresses me that our health-care debate has been launched from false premises and has deteriorated from there. We cannot ignore the ongoing harm being done, cannot deny that others are doing it better (across the board), and must not succumb to the false equivalencies and misdirections being vacuously peddled. Now is the time to arm yourself against the tragedy of ideology with real, observable facts.

Note To Self: Faster Chromium Builds (Updated)

I spend my days in C++ on 32-bit Windows XP in Visual Studio 2005. The build and link times for Chromium are painful on this setup, in part because there has been flakiness with the multi-process build option for VS, in part because the incremental linker which can dramatically speed up builds can run out of memory on some boxes (so is disabled by default), and because Visual Studio steadfastly refuses to give developers any options about how, when, where, and why to rebuild the IntelliSense database. The last one is probably the most intractable. On 64-bit windows, incremental linking is turned on based on the assumption that you'll have lots of RAM on that shiny 64-bit box. Similarly, Chromium builds using multi-process flags under VS'08 since it's known to be less flaky there. It seems I run with the "please hurt me more" configuration.

"Distributed builds!", I hear you scream.

That's not a bad path. For Mac builds, the office's ad-hoc distcc cluster is a godsend (particularly given that my Mac is a lowly laptop). For Visual Studio, there's IncrediBuild, but it has left me wanting a better option. Recently I've just thrown caution to the wind and started over-riding the safety valves on /MP and incremental linking via my ~/.gyp/include.gypi file:

  'variables': {
    'msvs_multi_core_compile': 1,
    'msvs_large_module_debug_link_mode': '2'

You can get these settings to take effect without updating your repo by running gclient runhooks --force from the top level directory if your Chromium checkout. VS should then prompt you to reload the project (assuming you're using the GUI).

Hopefully this recipe will help others. It has dropped small rebuilds on my system from north of 10 minutes to below 2.

Update: So the real answer, apparently, is to get dual quad-core i7's running Vista 64 under VS 2008. Holy cow, what a world of difference. All hail the Powers That Be for new, awesome hardware!

CSS 3: Progress! (Updated)

I've been in a pretty heated email conversation over the past couple of days regarding how effective (or not) the CSS Working Group has been. I've been pretty brutal in my critique in the past (and much of it still stands), but there's reason to hope.

The best bits are -- not surprisingly -- being driven by the implementers. Apple is in the driver's seat, with major contributions for Animations (including keyframes!), 2D Transforms, 3D Tranforms, and Transitions. Great stuff.

Similarly, David Baron (of Mozilla fame) is editing a long-overdue but totally awesome Flexible Box spec, aka: "hbox and vbox". Both Gecko and WebKit-derived browsers (read: everything that's not IE) supports hbox and vbox today, but using it can be a bit tedious. Should you be working on an app that can ignore IE (say, for a mobile phone), this should help make box layouts a bit easier to get started with:

/* hbox and vbox classes */

.hbox { display: -webkit-box; -webkit-box-orient: horizontal; -webkit-box-align: stretch;

display: -moz-box;
-moz-box-orient: horizontal;
-moz-box-align: stretch;

display: box;
box-orient: horizontal;
box-align: stretch;


.hbox > * { -webkit-box-flex: 0; -moz-box-flex: 0; box-flex: 0; display: block; }

.vbox { display: -webkit-box; -webkit-box-orient: vertical; -webkit-box-align: stretch;

display: -moz-box;
-moz-box-orient: vertical;
-moz-box-align: stretch;

display: box;
box-orient: vertical;
box-align: stretch;


.vbox > * { -webkit-box-flex: 0; -moz-box-flex: 0; box-flex: 0; display: block; }

.spacer { -webkit-box-flex: 1; -moz-box-flex: 1; box-flex: 1; }

.reverse { -webkit-box-direction: reverse; -moz-box-direction: reverse; box-direction: reverse; }

.boxFlex0 { -webkit-box-flex: 0; -moz-box-flex: 0; box-flex: 0; }

.boxFlex1, .boxFlex { -webkit-box-flex: 1; -moz-box-flex: 1; box-flex: 1; }

.boxFlex2 { -webkit-box-flex: 2; -moz-box-flex: 2; box-flex: 2; }

.boxGroup1 { -webkit-box-flex-group: 1; -moz-box-flex-group: 1; box-flex-group: 1; }

.boxGroup2 { -webkit-box-flex-group: 2; -moz-box-flex-group: 2; box-flex-group: 2; }

.start { -webkit-box-pack: start; -moz-box-pack: start; box-pack: start; }

.end { -webkit-box-pack: end; -moz-box-pack: end; box-pack: end; }

.center { -webkit-box-pack: center; -moz-box-pack: center; box-pack: center; }

I've been using these rules for some time to good effect. You can use them to easily visually center things (for example):


Or you can use grouping to get nicer form layouts:

It's unfortunate that this stuff is "medium priority", but at least it's moving forward in the WG.

Update: Fixed the examples and rules to use box-pack: center;, per Dave Hyatt's excellent suggestion!

Some Orthodox Heresies

Just back from a long weekend, a couple of things struck me this morning that are evident but not perhaps obvious. Reality always has multiple sides, so in true Jenny Holzer style, please accept (but not entirely) these small web-development truisms:

JS 1.8 Function Expressions: The Opposite of "Good"

JavaScript is crying out for a way to write functions more tersely. I've added my suggestion to the debate, and was vaguely aware that Mozilla had implemented "function expressions". It wasn't until I saw their use in the (excellent) ProtoVis examples that I realized how stomach-churningly bad the syntax for them is. Instead of dropping the word function from the declaration of lambdas, they kill the { } charachters, leaving the big visual turd at the front of the lambda while simultaneously omitting the symmetrical visual aid that allows programmers to more easily spot missing terminators.


It'd be one thing of the feature saved enough effort (typing) to justify the confusion, but it doesn't. Bitter syntactic sugar in a language that's already complicated by whitespace issues should be avoided.

Older Posts

Newer Posts