If no one releases a popular web browsing platform that lacks Flash support, then web sites that already publish Flash content are never going to move away from it. I think the web would be a far better place without Flash, or, at least, with Flash relegated to a position like that of Java applets: there if you want it, but not a major foundation.

Flash is never going to decrease in popularity so long as all web browsers support it. Flash might decrease in popularity because of iOS. If you believe that Flash’s current position as a de facto standard technology is harmful to the web, then users — not just iOS users but everyone using the web — would benefit if that happens.

I don’t think Flash is quite as evil as some commentators make out – it can be a powerful tool. But I agree that it needs to be repositioned: less as a standard web technology, and more as a bespoke application platform. So much of the stuff people use Flash for can now be achieved almost effortlessly with modern Javascript frameworks and clever use of CSS. I’ve yet to see a practical example of where Flash could be applied to applications on a mobile device.

Mobile browsing is growing like Godzilla on atomic-steroids. Instead of being relegated to the jet-setting Blackberry addicts from 5 years ago, today everyone is using their phone to surf the web.

Assistive technology -screen readers for the blind and alternate interface devices for the handicapped- is common, and you don’t want to lose a sale or alienate traffic just because you didn’t take that into account.

Your site is likely to be translated into a half-dozen languages as readers from around the world find your content. Thanks to the Internet Archive, Google’s cache and others, pages you publish today will be around for a long, long time even after they’ve been removed from your live site.

Clean markup and standards-compliance will go a long way to ensure your sites work in each of these scenarios.

Even if you’re a hardened web developer who knows your craft well, I think it’s always good to refresh your basic knowledge with articles like this: sometimes to reinforce your assertions and assumptions; and sometimes to pick up useful tidbits which have passed you by, or which you haven’t given much thought to.

A lot of designers think progressive enhancement only benefits those users who are using outdated browsers, but other users benefit, too. Mobile browsers are the most likely to take full advantage of progressive enhancement. The reasons for this are two-fold. First, mobile browsers that don’t support CSS or JavaScript can still display the content of your site. While most modern smart phone browsers support at least one of those, not all browsers for basic cell phones do.

It’s worth reading the whole article, which includes some very clearly explained advice, including how to sell the benefits of progressive enhancement to clients:

When working on your own, personal website projects, progressive enhancement is something you can implement without a problem. When dealing with clients, however, it can get a bit trickier. A lot of clients are still stuck on the idea that their website needs to appear exactly the same in every browser they’ve ever used. Ever.

Explain the benefits of progressive enhancement to your clients. Tell them that it’s faster and less expensive for them to have you design the site with progressive enhancement in mind, and that their visitors likely won’t care either way, as long as the content is available.

It’s worth noting that progressive enhancement is not the same thing as graceful degradation. This article from A List Apart explains it best:

Progressive enhancement focuses on the content. Note the difference: I didn’t even mention browsers.

Content is the reason we create websites to begin with. Some sites disseminate it, some collect it, some request it, some manipulate it, and some even do all of the above, but they all require it. That’s what makes progressive enhancement a more appropriate paradigm. It’s why Yahoo! swiftly adopted it and used it to create their Graded Browser Support strategy.

Techcrunch report that 280 North has been acquired by Motorola for a whopping $20 million, quoting a Motorola spokesperson:

“I can confirm that Motorola acquired 280 North earlier this summer. The transaction provides Motorola with specialized web-app engineering talent and technology that will help facilitate the continued expansion of Motorola’s application ecosystem. We believe 280 North will be instrumental in helping us continue to foster the Android ecosystem with innovative web-based technologies and applications.”

I really don’t understand the logic behind this acquisition, and suspect it could mean the end of the great open-source work that 280 North have done.

1. Motorola are committed to developing for the Android platform, so why acquire technology which is so intrinsically tied to the Mac platform? Objective-J is essentially a webified version of Objective-C; the look-and-feel of Cappuccino’s UI elements are based on the Mac UI, and the development tools feel just like Mac apps.
2. Cappuccino’s aim was to bring the ease of developing desktop applications to the web: it’s about creating web applications which feel like desktop applications. Motorola have very firmly positioned themselves in the mobile market, so why the interest in web applications which feel like desktop applications? Even if they are branching out into the development of tablet devices for the home, surely it makes sense to develop technology for a touch UI? Touch is not what Cappuccino is about – Sproutcore is way ahead of the game in this area.

I’m ready to be proven wrong, but this seems like a knee-jerk acquisition. This isn’t about acquiring 280 North as a viable company, or Cappuccino as a platform for further development – it’s about acquiring the clever brains behind this web app framework for Motorola’s bespoke purposes. It’s right there in that Motorola statement: “the transaction provides Motorola with specialized web-app engineering talent”.

Yes, I don’t think that (most of) the CSS experiments are meant to be practical. I also agree that they are have entertainment value, though I think they have even greater value as an educational resource. As long as these things are generally understood, then there’s really no issue, and if things had stayed that way, I would probably not have written the article at all.

However, when we actually start charging money for these icons – as with the Peculiar set – that places everything in an entirely new light, which I have termed the implication of cost. As long as everything remained in in the experimental stage, all this unique CSS work remained could be understood as primarily theoretical and conceptual. The moment we put a price tag on it, though, the implications change.

Charging people for the icons is essentially a means of sanctioning their use in a production environment and are stepping firmly across the line between the experimental and the implementable. When this happens, I think that there is an argument, because we are no longer just in the realm of the experimental, and the message we are sending is the wrong one.

I totally agree, and any web developer worth their salt will be wary of implementing any of these experimental techniques in a production environment. Font replacement techniques like Cufón and sIFR have their detractors, but at least these techniques degrade gracefully – even @font-face is designed to degrade so that it doesn’t interfere with the browsing experience served up by unsupported technology. But as soon as you start to use wild CSS for the design of graphical icons, or start fudging dingbats to convey visual context where it doesn’t belong, you create horrendous accessibility problems and degrade the user experience ungracefully.

During the design phase, being able to tweak the pixel look and dimensions of an icon should be as simple as possible; adjusting many lines of CSS code to do this is not it, especially if you didn’t write the CSS originally. You want that icon a little bigger? Tough luck, it was created by someone else at 32 by 32 pixels, now it’s up to you to figure out how to make it all work for 36 by 36. Similarly, implementing an icon should be as simple as writing a CSS background property or adding an <img> tag. It shouldn’t involve adding six meaningless HTML elements nor twenty lines of CSS per icon.

Each of these experiments takes a different approach. Some, like the line graph, have some practical applications in the real world, while others like the CSS fail whale are completely and entirely impractical. It’s certainly interesting to know that it can be done, but that doesn’t necessarily mean that it should be done.

This trend for the use of CSS as a design tool has been bugging me for a while now, and Matt hits on the very heart of the problem, drawing parallels with table-based layouts:

If you’ve been around the web design and devlopment industry for very long, you probably already know how much of a faux pas table-based design is considered. Well, when it comes to CSS icons, consider these thoughts:

1. Bloat – All the necessary CSS declarations will really bloat up your style sheets, making them an absolute nightmare to manage. Wait, didn’t I just write those same words? Also, depending on how the icons are achieved, you might find your HTML bloating up with extra elements too.
2. Inflexible – Again I admit that people have done some really incredible things with CSS, but compared with a real graphics program, CSS generated graphics are incredibly limited in what they can do.
3. Purpose – As we’ve already discussed at some length, CSS wasn’t designed as a tool for creating graphics, despite the fact that people are able to do some pretty amazing things with them, like the Peculiar and social media icons we’ve already looked at. Impressive? Yes. The right tool? No.

Many of these CSS experiments are very worthy exercises to show the possibilities and extremes of what the technology can do – but most aren’t practical for production use. CSS is a technology for defining rules about how content should be visually presented; it’s not a tool for generating graphics.

Instead of the traditional method of using images to display icons on web pages, Pictos uses a font, in the style of Dinbats or Webdings, which can be implemented using @font-face.

It’s an interesting concept. The main advantages appear to be improved speed and better scalability (the icons will scale just like any font). But there are some serious accessibility flaws. Since the font characters appear to be mapped to the standard alphabet (i.e. the “refresh” icon is mapped to the letter “C”), using this technique is a horrendous headache for anyone using a screen reader, and will be very bad for your SEO. One of the examples shows an example using CSS :before selector to prepend an icon to content, which kind of gets around those problems, but still feels a bit clunky to me: the whole HTML/CSS stack seems to be broken.

A good effort, but I’m not sure this technique is ready for the mainstream.

UPDATE: The guys at Filament Group have done some casual testing of the accessibility of this technique with a range of proposed solutions. Sadly, the results aren’t promising – even the “:before” technique breaks things. My gut feeling is that this still isn’t a particularly graceful technique, and the only viable fix is to map the Pictos “alphabet” to appropriate unicode characters. But, even then, the implementation would be tricky for anyone who lacks a rudimentary grasp of unicode.

UPDATE 2: Looks like the very talented Jon Tangerine has come to similar conclusions: the only way this can really work is by mapping the icons in the font to sensible Unicode code points. But identifies still more problems with the technique, even if the semantics discrepancies were dealt with: more accessibility gripes, the reliance on @font-face support and the difficulties of a graceful fallback.

Drew suggests you can kind-of wrangle the markup into something sort-of semantic. However, it starts to fall down fast. For example, a check mark (tick) is mapped to ‘3’. There’s nothing semantic about that. Clever replacement techniques just hide the evidence. It’s a hack. There’s nothing wrong with a hack here and there (as box model veterans well know) but the ends have to justify the means.

Jon explains things far more eloquently than I can, so I suggest you read his balanced and reasoned post.

Adobe and Typekit are teaming up to bring some of the world’s most popular, recognizable, and respected fonts to the web. Starting today, you’ll be able to use classics like Adobe Garamond, News Gothic, Myriad, and Minion plus many more on your website — all of them newly optimized and hinted for the screen.

Although there are only twenty-six fonts being added to the collection, they include some of the most popular and elegant fonts in use today. The fact that Adobe have taken the effort to ensure they are properly hinted for screen use is another bonus:

We’ve been using these fonts internally here at Typekit for a few weeks and the quality is simply amazing. These are the original cuts of the celebrated typefaces you’ve been waiting for, not reproductions or knockoffs of their designs. That means you can use them with the assurance that your creative work is being presented with all the accuracy and technical detail the print world has known for decades.

I’ve been watching the evolution of Typekit for a while now, but haven’t used it in any production work yet. This may just be the tipping point where many people take a second, serious look at Typekit as a viable tool for bringing elegant typography to their web designs – $49 per year is a pretty good deal, particularly when you compare the cost of the average font license.

The jQuery project is really excited to announce the work that we’ve been doing to bring jQuery to mobile devices. Not only is the core jQuery library being improved to work across all of the major mobile platforms, but we’re also working to release a complete, unified, mobile UI framework.

This looks great, and with a track record of delivering solid, well-documented code, this is going to be a welcome addition to the jQuery family. A unified approach to mobile web UI is desperately needed, and sounds like they are going to be targeting a wide range of platforms:

The critical difference with our approach is the wide variety of mobile browsers we’re targeting with jQuery Mobile. We’ve been working hard at bringing jQuery support to all mobile browsers that are sufficiently-capable and have at least a nominal amount of market share. In this way we’re treating mobile web browsers exactly how we treat desktop web browsers.

And, they’re approaching the visual design in a good way: talking in terms of “design language”:

From a design perspective, we have a unique challenge because we need a universal design system that will feel “right” on a broad range of devices instead of directly mimicking the design style of a particular platform.

To that end, we aim to synthesize a touch-friendly design language that can work well across a range of form factors from smartphone to tablet and a range of mobile platforms. A new ThemeRoller tool will be developed that will allow designers and developers to quickly design a custom theme that fits their color scheme and style to make a highly branded experience possible across all devices and browsers.

It’s worth reading the entire strategy statement.