(web standards advocacy)
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
Never in a million years would I have imagined myself a Mac user. But Mac OS X has changed all that, and it's now my primary desktop. For a long-time Unix/FreeBSD/Linux user it has everything I want: a mature and stable Unix operating system and the open source software I could not do without (security software; mail routers, servers, tools, and agents; languages; web platforms), with a beautiful graphical environment, multimedia viewers, and productivity software that are to be had only with great difficulty on Linux, if at all. And then there are the stunning extra goodies.
Native app vs. mobile web doesn't have to be an either-or; LinkedIn started with a 60/40 split and now their app is 95% HTML5. And Tim Bray has some great guidelines for when to do app, when to do browser.
Facebook has produced the ringmark which tests mobile browser capability, in conjunction with a W3C group "coremob" to advance mobile-web-as-platform. Facebook says Facebook-by-mobile-web users outnumber all Facebook-by-app users combined (small wonder, if you've tried the Facebook app).
Life Below 600px: Stop and consider the concept of "The Fold". A good concept from the days of the newspaper ("put eye-catching stuff above the fold, to entice readers to buy it and read the rest") has become totally perverted into "we have to put everything above the fold, because anything below the fold will be ignored". Rubbish! The goal is still the same: Catch their eyes and entice them into the rest of your quality content. Turning the top of your front page into a densely-packed "eye chart" works against that goal.
A very interesting game of "chicken" is being played out between Microsoft and Google. Google released Chrome Frame in September; it basically puts the Chrome renderer inside IE. Microsoft, of course, is not happy about this; they claim this puts IE users' security at risk (which, given IE's history, is an outlandish claim IMO). Google says they created Chrome Frame to meet the needs of Google Wave and other web-based applications that need high performance. Note also that Google didn't hack, reverse engineer, or subvert anything; they wrote Chrome Frame using Microsoft's own documented Browser Helper Object API. (Irony: ...which Microsoft created in the days of its rivalry with Netscape.)
Ars Technica has a good article about Google Wave and Chrome Frame:
The developers behind the Wave project struggled to make Wave work properly in Microsoft's browsers, but eventually determined that the effort was futile. Internet Explorer's mediocre JavaScript engine and lack of support for emerging standards simply made the browser impossible to accommodate. In order to use Wave, Internet Explorer users will need to install Chrome Frame.
Microsoft is the only major browser vendor that has failed to build a next-generation high-performance JavaScript engine. Mozilla's TraceMonkey, Chrome's V8, and Apple's Nitro all offer extremely fast JavaScript execution and are getting faster with each release. These browser vendors are competing to deliver near-native JavaScript performance in an effort to empower the development of significantly more sophisticated Web applications.
Internet Explorer apologists and Microsoft's marketing department have largely responded to this trend by denying the value and relevance of high-performance JavaScript. The performance of the scripting engine has little discernible impact on today's webpages, they say, arguing that a faster JavaScript engine would offer no practical value to end users.
So the die is cast. If Google maintains their stance, it could slow adoption of Google Wave, or it could spur adoption of Chrome Frame. If Microsoft maintains their stance, it could backfire and cut into IE's market share, or... hmm... trying to think of the plus side... Of one thing I'm convinced: Microsoft can drag its feet, but it will not be able to stop the titanic shift of applications onto the web, and the increasing irrelevance of the user's OS and browser brand.
Safari 1.3.1/2.0 bug with CSS borders.
Reactions to IE7 beta 1 (from the standards perspective) from Dave Shea (precious little improvement) and Molly Holzschlag (plea for patience). That's supposed to be a smiley-face, where IE7 beta 1 runs the Acid2 browser test. Microsoft response detailing plans for IE7 beta 2. Chris has said that MS' highest goal isn't to pass Acid2, it's to work first on what they perceive the most important CSS issues are.
The conversation between WaSP and MS continues... the issue is that web developers who care about standards have been forced over the years to use "hacks" to distinguish browsers and emit standards-compliant code that works for that browser (working around bugs, non-standard behavior, etc.). Starting with IE7, the IE team strongly recommends that instead of "hacks", developers use the MS-developed "conditional comments", which Dave Shea comments on, but note that since conditional comments aren't XML, they cause trouble with XSL/XSLT. Sigh.
Dave Shea seems much happier with the latest IE7 preview, in how far they've come in addressing CSS and rendering standards problems.
David Hammond publishes the site Web Devout which tries to put some objective "percent compliant" numbers to modern browsers. He and Chris Wilson traded comments on Chris' blog related to this site; sounds like the IE beta feedback channel hasn't produced the kind of results David and others were hoping for. (I like the idea of having the community "weight" the line items on that site for importance.)
Support for standards in IE/Firefox/Opera:
Tim Berners-Lee says New Top Level Domains Considered Harmful. Good thoughts on why .mobi is a bad idea: breaks device independence of the web and URIs specifically.
James Clark's MicroXML proposal.
An interesting article on the way to use XHTML properly. A little dismissive ("what's the point?") of people like me who validate their pages but send them as MIME type text/html so they can still be read by most UAs. Still, it gives some clarity to what the issues are. There's an XHTML 2.0 FAQ which also talks about this issue, and shows a trick to get IE to accept XHTML sent as XML, and has other good information. More about XML "encoding" vs. Content-Type "charset" in the melodramatically-titled XML on the Web Has Failed.
See The non-world non-wide non-web and State of the WHAT for a snapshot of the W3C WHAT-WG today and their answer to XAML, and see questions of W3C relevancy. An article at ZDNet gives more background on XForms (W3C, enterprise vendors, needs plugins), XAML (Microsoft, Longhorn+Avalon), and Web Forms 2.0 (browser mfg. e.g. Mozilla/Apple/Opera, works with today's JS).
This site is slowly crawling its way toward a design (cf. A List Apart) that complies with web standards and is viewable with any browser, and uses CSS (amazing site). Here is a great essay explaining why. It will probably use the "Websafe Palette" that Webmonkey alluded to (the "Reallysafe Palette" is a bit extreme). Oh, and here's a Webtechniques article on designing to accommodate color-blindness. See also Webmonkey.
My contact information, brief autobiography (such as it is), and family tree.
