...more recent posts
I what is possibly huge typographic news for the web in general, the latest WebKit nightlies now support the CSS @font-face rules.
Attempt at a short explanation: WebKit is the open source engine that powers the Safari browser (but also Opera, Shiira, and web browser in the Nokia S60 platform.) A "nightly" means the very latest version supports this (with new versions compiled every night,) but not yet the latest stable version (so the version with @font-face support isn't shipping yet, but because it's open source you can go and download it if you're brave.) And finally the CSS @font-face rule is a CSS rule that allows web designers to embed custom fonts in a web page. If the local computer doesn't have that font-face it will go to the supplied URI and download the font so it can render the page correctly.
If that doesn't sound like a big thing to you then you're not a graphic designer.
The reality check here is that only TrueType fonts are supported (that's not so bad actually,) and, of course, only WebKit is supporting this standard so far, so you really can't count on this working when designing for the web at large. Still, you can use it, and your pages can look amazing in Safari (or incredibly bad if you're a bad designer I guess,) and then just fall back to Helvetica or some other boring font-face in other browsers.
A List Apart has a good overview of @font-face.
Obviously I've been following and thinking about Adobe and their plans for web development. At the same time I've chosen a different route, with the open web standards of HTML, CSS, and javascript. Adobe Flash and Flex and AIR are some seriously cool tools that give you access to very rich features and, comparatively, a lot of speed. These two different paths are obviously in competition (if not economic, at least for developer hearts and minds,) but they are also closely related. Adobe has clearly been moving to make javascript a first class citizen in it's environments (for instance, you can build AIR apps with all javascript and zero actionscript.)
And this makes me wonder about Tamarin, which is an open source project that is Adobe's contribution to Mozilla. The basic point is to make javascript really fast. Which is great. And great for Adobe since they are now leveraging javascript in their development world.
But I wonder if they are rethinking their decision in light of the progress that projects like EXTjs have made building a development framework on top of pure HTML, CSS and javascript. Sure it will never have all the rich features of the Adobe environments, but some constraints are not always a bad thing (especially where those constraints force you to use the native widgets people expect to see on the web, and to build regular web pages that work the way people expect.) Plus the technology is all open and free for the developer. But there is a real issue, and that's speed. EXTjs (as well as any of the others like jQuery, YUI, prototype/scriptalicious, etc...) apps are slow compared to their rich Adobe conterparts. Really slow in some cases.
In the future, no doubt, this won't matter so much. Our computers will keep getting faster. And then there is Tamarin out there on the horizon ready to supercharge javascript 2. Which brings me back to my question. Why would Adobe want to contribute Tamarin? Seems like a radical speed up of javascript is going to make EXTjs et al much more competitive with Adobe's projects.
Felix Salmon makes the economic case for full rather than partial RSS feeds. Amen. You might also just make the don't needlessly harass people trying to read what you write case, which I guess is what his economic case boils down to.
I'm still not on board, but Adobe is building some impressive web development tools. Their latest release preview (release some time next year) is Thermo, a graphical editing environment aimed at bridging the gap between old style (photoshop) designers and web coders.
You just import a photoshop mock-up of a web page (what can now be more and more thought of as a web application user interface,) and Thermo understands all the layers and provides a 'convert artwork to...' command which automatically converts, say, a dummy text input field from the mock up into a real text input field (or button, check box, combo box, date picker, color field, etc...)
Sounds good for big shops with more graphic know how than web knowledge. Not sure I want all those people being able to compete with me (and it's not clear that Thermo will actually let them and/or if it will just end up enabling a lot of half baked web apps in a Visual Basic sort of way,) but I have to admit that Adobe is cranking out a lot of cool sounding tools.