In celebration of the iPad retail launch, Apple has created a gallery of iPad-ready websites that are said to embrace “the latest web standards—including HTML5, CSS3, and JavaScript”. That is, no Flash. You can even add your site to the gallery (scroll to the bottom).
Is Apple really opening up?
Let’s get the snark out of the way: a gallery, really? How novel. Right now there’s a vertical list (no Cover Flow?) of 20 top-tier websites. Will Apple really painstakingly update this list and add every possible HTML5/CSS3/JS-ready site submitted?
It’s a rare thing for Apple to lead a user-generated campaign like this but its best intentions are a thin veil over their real agenda—eliminating the competition and expanding further in the multimedia business. Does it really care about anything other than the big fish? What are the odds that the most humble of websites will even get into the gallery? Apple markets its products by partnering with the largest corporations that fit into its plans; I can’t imagine caring for the little guy in all of this.
This isn’t even in the same league as the iTunes app store—whose contents number in the hundreds of thousands—but could easily apply the profit-based and biased policies anyway. Not what I would call open or little guy friendly.
Is Apple a true web standards crusader?
Speaking of the app store: you can also develop specifically for the iPhone/iPod/iPad family using the SDK, but those apps don’t work in other devices. The mobile web is booming because of both the “web standards way” and the “mobile app” way, but how are device-specific apps any better than Flash apps (which happen to be cross-platform outside of Apple’s products)? Flipping off Flash when HTML5 and CSS3 aren’t ready isn’t a very responsible thing to do.
If Apple really wants to promote web standards, it should be doing a lot more with its resources to convert and educate people. The gallery is one thing, this documentation is another good step, but where are the resources for developing in HTML5, CSS3, and JavaScript? Partnerships with web standards groups like WaSP? Zeldman or one of the Super Friends speaking at the keynote?
If Apple really wants to promote web standards, see how it practically equates HTML5 with Flash-free media and nothing more. No oohs and ahs over CSS3′s text shadows and rounded corners or HTML5′s geolocation and <canvas>. This is the perfect opportunity to introduce the mainstream crowd to the wonders of these new technologies, yet all it’s pushing is anti-Flash propaganda.
One more thing…
Dear Apple, you’ve done a lot of groundbreaking things, but if you’re going to use web standards as a selling point for your most adjective-ridden product ever, you can do a hell of a lot better than an an anti-Flash gallery.
So Mark Boulton decided to release his book, A Practical Guide to Designing for the Web, online and without cost. It’s not the only web design book available for free on the web, which this list and a previous encounter with two other online books prove, but all of them make me wonder, again, about the electronic book format.
In the examples above, said “books” don’t adapt official e-book formats, but stick with plain old semantic HTML and PDFs. Joe Clark, in an A List Apart article, explains that both standard and proprietary e-book formats are just more specialized versions of HTML/XHTML, so is there anything gravely wrong with creating webpages instead of actual e-book files?
As one who knows her way around HTML, taking an extra step into e-books (e.g. ePub) feels clunky and unnecessary. However, that is hasty judgment without first considering factors like audience. For web design books, perhaps it makes more sense to not bother with anything else and keep them as webpages because web designers work on sites all day long. That’s not to say they wouldn’t enjoy reading web design books in their e-book readers, but they may mind less having a book in one tab alongside other web design resources in other tabs.
Using proper formats also seems like a natural extension of web standards philosophy. If one were to publish a book online, why not go for the suitable format? There are scripts, extensions, and converters available. And with the ePub Zen Garden following in the steps of the CSS one, it may become the next worthy cause to root for.
I’ve sung praises over the Flash-based multimedia suite Aviary, but what’s more disruptive than an company using Adobe’s own technology to compete with them? Perhaps something that erases Flash from the equation altogether, which is what you get with Sketchpad. If enough effort is poured into this project down the road, taking desktop tools to the web browser may no longer need plugins like Flash and Air.
That still seems like a far away future, though. Even this ReadWriteWeb report, where HTML5 has been found to be sometimes more CPU-intensive than Flash, indicates it doesn’t even have that advantage in the bag.
Then there are others who can’t see how HTML5 and Flash can even be comparable, but here’s a compelling point for that argument: where are the tools for creating in HTML5? John Nack from Adobe has a few answers. Though as an Adobe guy, he advocates for Flash too.
Finally, there’s browser adoption as the biggest and most obvious issue of all. And sadly, that one might not even be resolved.
All of these beg the question: “Is it irresponsible to advocate using HTML5 before it is ready?” But when, pray tell, will it be ready?
Remember my complaint about all the CSS3 syntaxes differing from one browser to another? It’s now addressed with CSS3 Please, a jQuery-based, in-browser editor that replaces multiple attribute values of the more complicated CSS3 syntaxes (from border-radius to rgba to @font-face) all at the same time, so you don’t have to.
In addition to syncing and normalizing changes across the necessary properties, it also sneaks in IE support for a few features via IE filters. Right now it helps you write the rules for: border-radius, box-shadow, linear-gradients, rotation and @font-face. A few more transforms like skew and scale are on their way, stay tuned.
You can preview your code on the box at the right side by toggling it on and off. When you’re done, click on the clipboard icon to copy the code.
This is a smart solution to a growing problem. However, even though I’m thoroughly grateful for this tool, I still want to axe the real problem, which is the inconsistent browser syntax. It’s unreasonable for a programming language to have redundant code, and while CSS isn’t really one, it’s still code. We’re still supposed to pride ourselves with efficiency, conciseness, and standards with any kind of code. We like to kick IE for constantly breaking standards; should we tolerate the same thing for other browsers just because they’re implementing cutting edge features?
It’s a disappointing day when you find a single serving site that generates the comprehensive syntax for the border-radius property, aptly named border-radius.com. Because not all browsers (and browser versions) support the latest and greatest things CSS3 can do, one has to resort to browser targeting yet again. Only this time, one browser’s syntax is different from another browser’s, and becomes a chore to write CSS for each.
There’s a pretty obvious explanation for the existence of browser-specific properties from SitePoint:
Vendors—browser makers—are free to implement extensions to the CSS specifications that, in most cases, are proprietary to their browser. They may do this for a number of reasons, such as adding new features for users, or for experiments and debugging. Most often, though, the extensions are used to release and test browser features that have been developed in the preparation of W3C drafts that have not yet reached Candidate Recommendation status—the extensions allow these new properties to be widely tested before they become available as standard CSS properties.
So for starters, the browser-specific CSS has prefixes like:
-moz: Gecko-based browsers like Firefox-webkit: WebKit-based browsers like Safari and Chrome-ms: Internet Explorer-o: Opera-khtml: Konqueror
(The complete table is listed at the W3C.) That’s fine, but what I don’t get is why the syntax following the prefix isn’t always the same as the standard CSS syntax. The border-radius property is just one example, which is peanuts compared to the gradients syntax. Compare:
-webkit-gradient(
linear,
left bottom,
left top,
color-stop(0, rgb(0,10,148)),
color-stop(1, rgb(45,58,246))
)
-moz-linear-gradient(
center bottom,
rgb(0,10,148) 0%,
rgb(45,58,246) 100%
)
Sure, we can turn to generators like WestCiv’s and Damien Galarza’s—and we’ll probably be increasingly dependent on them in the future as CSS capabilities and their corresponding syntaxes grow more complex. But why must browser vendors insist on that when it only multiplies the code and maintenance necessary? Does it have to do with the way their engines parse the code, or something less significant?
The Apple stories just don’t stop coming, do they? Here’s yet another provocative issue concerning the company, but this time with web development: the iPhone is the new Internet Explorer 6, according to Peter Paul Koch.
The iPhone has become an obsession. If we don’t pay attention, we’ll have a mobile web that only works on the iPhone. And then we’ll have the real mobile web that wasn’t made by us and doesn’t give a shit about web standards and best practices.
Worse, it seems web developers are happy with this state of affairs. It seems web developers are congratulating themselves on excluding 85% of the smartphone users. They certainly never bother to check their sites in S60 WebKit, the largest smartphone browser in the world.
Fucking dimwits.
We’re doing exactly the same as ten years ago. We now say “iPhone” instead of “IE6,” but otherwise nothing’s changed.
No, wait, there’s one more change: the iPhone has far less mobile market share now than IE6 had desktop share back then.
The once most advanced browser is now the most hated, and the same fate could happen with the iPhone and its mobile web browser. However, given that they were made by two very different companies—the oft-hated Microsoft and the much-adored Apple—it’s hard to imagine the revolutionary smartphone gaining a stigma someday. An interesting achievement if that does somehow happen, but what an unfortunate future that would be.
Still, I have two points to make. First: I’m glad that a reputable voice is finally calling out this obsession with creating custom-tailored websites for the iPhone, when it’s supposed to have the most advanced browser, displaying pages as they normally would on a regular computer. Chances are you don’t have to. That’s what the multitouch zoom gesture is for, so that the screen size wouldn’t be such a hindrance.
Second: hype, here we go again. PPK draws back the curtain and tells us that there are other devices far more popular than the iPhone, yet the buzz about mobile web development is strongest with iPhone apps and iPhone app-like websites. It goes against the very idea of web standards, of making websites work in as many platforms as possible, not just what gains the most attention and is considered cool. (As an aside: what can be said about implementing CSS3 properties via browser-specific extensions? Is it the same thing?)
Finally, a minor third point: Koch isn’t addressing every mobile web developer in his article, just the ones that are so caught up in this iPhone-loving bubble that it’d be a shame when they mislead impressionable developers branching out to the mobile arena.
And a far worse shame if because of the hype we somehow get stuck in the rut that is IE6 all over again.
According to Ajaxian, the beloved tradition of learning by peeking at someone else’s source code is on the brink of extinction. Because Google is rewarding websites that load faster, people will stop at nothing to look good in the big G’s eyes, including code compression and more notably, obfuscation. This renders View Source useless.
While I feel it’s too early to call doomsday on View Source because of such speculation, like many I feel protective over it. It’s no surprise then that the Save View Source movement has been formed this early. The discussion is sparse, but Alex Russell elegantly explains why View Source matters, also reminding me why I love developing on the Web:
View-source provides a powerful catalyst to creating a culture of shared learning and learning-by-doing, which in turn helps formulate a mental model of the relationship between input and output faster. Web developers get started by taking some code, pasting it into a file, saving, loading it in a browser and hitting ctrl-r. Web developers switch between editor and browser between even the most minor changes. This is a stark contrast with technologies that impose a compilation step where the process of seeing what was done requires an intermediate step. In other words, immediacy of output helps build an understanding of how the system will behave, and ctrl-r becomes a seductive and productive way for developers to accelerate their learning in the copy-paste-tweak loop.
Even in compiling languages people learn better by looking at example code, but the culture of open learning can be felt strongest on the Web. Ajaxian posts a follow-up, in which I couldn’t agree more with this:
I personally feel like the ability to view source fit in perfectly with the culture of the Web, and was especially important early on. I am willing to bet that we have all learned from the notion of view source.
The freedom of access to tons of information on the Web is what it all boils down to. View Source is a sturdy consequence of that. It seems wrong to compare performance versus learning, but between those two, learning should prevail.
Then again, who can stand in the way of site owners desperate to turn up traffic and profit? Sounds like standards versus SEO all over again. What do you think—is the Save View Source movement an overreaction or a preemptive strike?
I started with this article about the decade that was in web design. (Note: an earlier version of this was done here.) It was not much more than a before and after look at the most popular websites out there. Of course, ten years is a long time in web design so the showcase is a satisfactory way to see how far we’ve come, but not quite enough. There was no discussion on the notable features from the different websites. We don’t redesign sites just because we want a different look, do we? We want them to improve. Answering how those sites improved over the years would be a worthy reference for all the web designers out there. This other one almost nails it, though it focuses on the business of these companies, not web design itself.
I hope the likes of Smashing Magazine or some fabulous curator of web design history would come up with an in-depth study illustrating how web design has evolved over the last ten years. Timelines like this and this could help with that, but still needs mention of developments like:
- the downfall of
<table> layouts in favor of semantic markup
- CSS sprites
- the growth of web typography, from sIFR to
@font-face
- Art Direction in web design
- mobile web design
- the HTML 5 Superfriends
- which website or company popularized which design pattern, from the glossy, candy-colored “Web 2.0 look” to the sleeker, more dramatic “Apple look” (though something tells me Apple is responsible for both)
Here‘s another approach to the timeline, and is more of a Q&A over the years, and anybody can ask and answer. It also hasn’t been updated since ’04, as it was part of the 2005 conference, A Decade of Web Design. Jakob Nielsen also did a backtrack that same year.
I’d also like to look forward. This prediction post is quite adequate (with pictures it would be perfect). I think this passage sums up what’s happened in the past decade and what will happen in the next:
While most these technological improvements tend to make the web a more and more homogenous place, at the same time, there is a tendency to create highly curated design setups that use different designs for each article.
There will always be a dichotomy between standardization and specialization on the Web but it’s only lately that we’ve been able to do so with less crap, more elegance. And I can’t wait to see how doing those two things evolve into even more exciting things in 2010 and beyond.
Need more crystal balls and time capsules? See also:
And by jQuery-esque I mean easy! The premise of Jetpack, Mozilla Labs’s latest creation, is that anybody who knows HTML, CSS and JavaScript can create Firefox add-ons.
It takes 80 lines of code to block ads on websites as shown in the demo above, and 14 lines to edit images from within Firefox. Granted, it just sends the data to Pixlr which does all the hard work, but lowering the obstacles to develop some fairly nifty scripts is a commendable effort, just as what jQuery did with JavaScript, Sass with CSS, and HAML with HTML. It’s made even more compelling with Bespin, Mozilla’s HTML5-powered web-based code editor.
Perhaps I’m still in a “standardize everything” mood, or envy this new doodad since I’m now using Chrome as my default browser, but don’t you sometimes wish all browsers could do this? Do the same set of things? We’re getting to a point where the level of HTML and CSS support is the same across every browser, so it makes me wonder what’s the next step for the idea of cross-browser compatibility.
It will probably depend on what the web browser means to its various makers. Google has unveiled the Chrome OS, which will run on a specialized version of Chrome. Opera is focused on its “web servers for everyone” feature in Opera Unite. (And Internet Explorer is playing catch-up, mostly.) Browsers are basically the gateways to the whole Internet, but they’ve become more ambitious than that and their vendors will attend to those ventures first before convening to create new cross-platform goodness.
To commemorate the closing of internet dinosaur and free web hosting service Geocities today, October 26, geeky web comic XKCD “redesigned” its site to match the horrible aesthetic (or lack thereof) rampant during the ’90s. Low-fi images (including the requisite “under construction” sign), web-safe colors, <table>s, <blink>, <marquee>, a hit counter, and a “best viewed in Netscape Navigator” disclaimer—it’s all in there. I think the only thing missing is an actual comic about Geocities itself.
Is it safe to say we are finally rid of those horrible-looking and horribly-functioning things now that Geocities is gone? We will always have that side of the spectrum. But it’s a good reminder of how far we’ve come:
- IE6 is now the most outdated browser instead of the most modern. (That doesn’t make its continued existence a good thing though.)
- If you disable images and stylesheets, webpages will make sense.
- Descriptive hyperlinks matter (mostly to curry favor with Google, but still).
- Despite Yahoo!’s terrifying propensity to run its acquisitions to the ground (worried about Flickr and Delicious yet?), it’s easier and cheaper than ever to run your own website.
Still, the timeless adage remains: back up and be prepared! You never know when life will go Geocities on you.
*/
