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!
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.
Oof.
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.
So after receiving a keyboard-lashing from myself and others regarding some comments he made, Chris has walked a lot of it back and bravely noted where his new perspective conflicts with the old. It takes guts to do that.
My original comments were born of my frustration the internecine strife that seems to follow every discussion about OSS licensing. It's one of the reasons that I was so grateful for Dion's 100-point scale for judging community because it helps put all of this stuff into a perspective that lets you evaluate what's more likely to be good for a broad audience from what's more likely to hurt people along the way. There will always be both individual and corporate involvement in OSS, and both are good things, but neither are unalloyed forces for lightness and right. They've got down-sides. OSS communities and hackers should be honest about them and evaluate them on the merits and likely outcomes. It took me a long time to come to that perspective and it's and one that I'm happy to see Chris weighing. Kudos to him for taking it in stride.
Correction: I wrongly attributed the 100-point scale to Ben instead of Dion. Totally n00b mistake. My apologies.
Early on in discussions with the excellent folks at Zend, one of the possibilities that made everyone in the room excited was the ability to use server-side smarts about client-side work to automate performance optimizations in ZF apps. After lots of great work on getting Dojo integrated, Zend Framework is making that a reality by support automated custom builds in ZF 1.9.0's preview release.
What does this buy you? You get to use the Zend helpers for Dojo as you normally would, simplifying how you pull in code, declare components, and build your UI. What this new integration saves you is the tedium of figuring out which components you're using everywhere, building a layer file for it, kicking off a build, and remembering to re-visit the layer definition when you project adds or removes modules. Hopefully ZF 1.9 should lower the barrier to taking advantage of the full range of Dojo-based optimizations, making it easier to prototype quickly and deploy easily. Exciting stuff!