Flickr: now with bigger images and a (mostly) responsive design.

The larger images in Flickr’s revamped photo pages put the emphasis where it belongs — on your photos. Peripheral information, like comments, maps, tags, set info and so on are still there, they’re just now (rightly) dwarfed by the actual image.

The result is a much more photo-centric site that does a nice job of differentiating itself from the current trend of low-res, filter-heavy photo0sharing services.

Web developers, take note: Flickr’s new layout isn’t just eye-catching, it’s also somewhat responsively designed — adjusting to the myriad screens on the web today and displaying the best photo possible without clogging your tubes with huge photo downloads. Flickr does stop short of scaling pages down to phone-size screens — for which there is a separate mobile website — but it resizes nicely to handle tablets.

That’s right, Flickr is the latest (and perhaps the largest) website to embrace not just a mostly responsive design with a liquid layout and media queries, but also a responsive approach to images.

We’ve looked at dozens of ways to handle images in a responsive design, but Flickr has opted for a custom setup that uses a bit of server-side PHP and some JavaScript to serve images based on screen size. Flickr is also using a custom algorithm that takes the width and height of the screen into account and “will display content at a width that will best showcase the most common photo ratio, the 4:3.”

For more details on how Flickr is handling the responsive aspects of the new design, check out the Flickr code blog.

Developers working with the Flickr API should note that the new photo sizes are now available through the Flickr API if your app or website would also like to display larger images.

Flash Player running in Firefox for Mobile. Photo: Scott Gilbertson/Wired

Mozilla has released an update for its Firefox for Android beta mobile web browser. The latest beta sports a redesigned interface that looks a little less like Firefox and a little more like a native Android application.

If you’d like to help Mozilla test this beta, head on over to the Android marketplace and download a copy today. Unlike the recently updated Chrome for Android, which requires the latest and greatest Android Ice Cream Sandwich, Firefox for Android will run on Android Froyo 2.2 and better (it is, for the moment, only available in English, though).

The newest Firefox for Android beta is — despite looking a bit different from the early mobile releases — still pretty much the Firefox you know and love, with support for mobile add-ons, tabbed browsing and Firefox Sync, as well as the mobile-friendly “Awesome Screen.”

The Awesome Screen is similar feature-wise to the Awesome Bar in desktop Firefox, but tweaked to make mobile browsing and searching easier. To use it, just tap the location bar and you’ll see a list of your favorite bookmarks, history items and search engines.

Mozilla says the latest Firefox for Android beta starts up faster and some improvements to the underlying code should make for faster response times, better graphics performance and smoother panning and zooming. And while it’s not the only Android browser to do so, Flash fans will be happy to know that Firefox for Android continues to ship with Flash despite Adobe’s decision to stop developing the mobile Flash plugin.

The major focus for this beta release is getting the new native interface in Firefox for Android ready for prime time, so if you do decide to test it, be sure to let Mozilla know if you encounter any bugs.

4... 3... 2... 1...

To install HTML9 Responsive Boilerstrap JS just “attackclone the grit repo pushmerge, then rubygem the lymphnode js shawarma module — and presto!”

If you’re wondering what H9RBS.js actually is, well, you can abandon any hopes of one day being hip. But if you must know, H9RBS.js is a “flexible, dependency-free, lightweight, device-agnostic, modular, baked-in, component framework MVC library shoelacestrap to help you kickstart your responsive CSS-based app architecture backbone kitchensink tweetybirds.”

The hilarity continues on the official HTML9 Responsive Boilerstrap JS website, and there’s a GitHub repo of course. Check out the issues page (“Need unrealistic micro-benchmarks”).

You can read a bit about what inspired developer Louis Lazaris’ pitch-perfect web development parody over at his site, Impressive Webs.

Sisyphus, by Max Klinger. The four ladies up top are named Gecko, WebKit, Trident and Presto. Image: Max Klinger via Wikimedia

CSS expert Eric Meyer thinks that a new proposal, CSS Vendor Tokens, might offer a way out of the CSS vendor prefixes mess.

CSS vendor prefixes were designed to help web developers by providing a way to target CSS rules to specific browsers and use proposed standards before they were finalized. Alas, while they have helped, they’ve also hurt the web.

The W3C’s CSS Working Group is currently in the process of trying to fix some of the problems. We’ve covered one proposed solution from Florian Rivoal, which would make vendor prefixes into aliases and ensure that when a browser implements a new CSS feature, it will work both prefixed and unprefixed.

Another proposal that Meyer wrote to tell us about comes from François Remy, who proposes what he calls Vendor Tokens. “I propose we use unprefixed properties from start,” writes Remy in a message to the www-style mailing list, “but with a token explaining which version of the property we built our CSS for.”

Essentially what Remy proposes is to use a flag much like !important, but to signal which version of the CSS property the rule is aimed at. The advantage is that instead of targeting browsers directly, you’re targeting a draft version of the spec.

Here’s Remy’s example of the syntax:

selector {
    border-radius: 1em !webkit-draft;
}

It’s a bit less typing than the current method, which would require four lines to convey the same information and, as Meyer suggests, dropping the -draft would simplify things even more. But more important than a simpler syntax is that, as Remy explains it: “any browser which is not webkit but implemented border-radius in a way that is compatible with the ‘webkit draft’ can support the declaration.” That’s a little different than vendor prefixes. With Remy’s proposal other browsers wouldn’t need to impersonate webkit, “they just acknowledge they support one specific property the way the webkit draft defines it.”

So a more full-featured declaration might look like this:

selector {
    border-radius: 1em !webkit-draft !moz-draft !o-draft;
}

Remy also includes a way to handle scenarios where Apple’s version of WebKit might differ from Google’s or even account for differences in versions of the spec.

As Remy admits, there are some drawbacks to this approach, and the syntax isn’t the cleanest we’ve seen, but as Meyer writes, “it feels cleaner than trying to do the same thing with prefixes.”

It will likely be some time before the CSS Working Group makes a decision on what, if anything, to do about vendor prefixes. If you’re interested in keeping up with the discussion on this and other proposals keep an eye on the www-style mailing list.

Windows RT makes Firefox sad. Photo Neil McIntosh/Flickr.

In a post on the Mozilla blog, Harvey Anderson, Mozilla’s General Counsel, says that Windows RT’s restrictions signal “an unwelcome return to the digital dark ages.”

While Mozilla is already hard at work on a version of Firefox for Windows 8 on traditional PCs, Microsoft’s restrictions mean that there will be no similar version of Firefox for the new Windows RT.

The crux of Mozilla’s gripe is that in Windows RT Microsoft gives its own Internet Explorer access to special APIs other web browsers can’t use. The result, according to Mozilla’s Asa Dotzler, is that “there’s no way another browser can possibly compete with IE in terms of features or performance.”

Mozilla believes this represents the same abuse of monopoly power Microsoft used to sideline Netscape in the early days of the web. The special API access for Internet Explorer in Windows RT “restricts user choice, reduces competition and chills innovation,” writes Anderson.

Dotzler points out that at least part of what makes this different than Apple’s iOS — which imposes similar restrictions on software and prevents Firefox from running on iOS — is that Microsoft still has binding agreements with the EU about browser choice on Windows, and Windows RT is still Windows.

The new restrictions, writes Dotzler, “are in direct violation of the promises [Microsoft] made to developers, users, and OEMs about browser choice.” So, while Microsoft may be aping Apple with these new application limitations, Apple has the advantage of not needing to worry about past anti-trust agreements.

Furthermore, argues Dotzler, while Windows RT may be aimed at tablets at the moment (an area where Microsoft is currently nowhere near having monopoly power), Microsoft’s long-term goal is for Windows RT and ARM devices to include servers and laptops as well. That would mean that if Microsoft succeeds and ARM chips are running Windows RT on laptops, tablets, phones and toasters near you, there would be only one browser available on any of them — Internet Explorer.

It’s unclear what Mozilla and other potential competitors plan to do about the restrictions in Windows RT. Anderson concludes his post writing simply, “we encourage Microsoft to remain firm on its user choice principles and reject the temptation to pursue a closed path.” Since Windows RT hasn’t yet been released there’s still time for Microsoft to change its mind and lift the current restrictions. For now at least Mozilla seems willing to wait on Microsoft’s next move. If Microsoft doesn’t change course the fact that Mozilla’s complaint was penned by its top lawyer may give some hint of where this fight is headed.

Wired's Gitspective on life.

Moazeni’s code uses the GitHub API to pull in pushes, forks, gists, branches, tags, follows and comments, displaying them in a vertical timeline reminiscent of Facebook. If you’d like to try it out, just head over to Gitspective’s GitHub page and plug in your GitHub user name.

The Gitspective code is still a work in progress and Moazeni has already listed a few wish-list items over on the Hacker News thread. If you’d like to contribute, grab the code on GitHub.

The WebKit project, creators of the rendering engine that powers web browsers like Safari and Chrome, has added support for the new Intent tag, part of the proposed Web Intents standard.

Originally developed by Google’s Paul Kinlan, Web Intents are a kind of meta-website API that would allows sites to easily pass data between each other — for example, to edit a photograph or share a URL with friends.

Since Kinlan initially proposed Web Intents — which are based on a similar system used in Google’s Android operating system — Mozilla and several other companies have joined forces to work on standardizing Web Intents.

Web Intents offer a way to connect your favorite sites to each other and pass data between them. The canonical example is a photo-sharing website that wants to let you edit your uploaded images. To do that, the site simply adds a button, Edit This Photo, and behind the scenes the new <intent> tag tells the browser that the button wants to connect to a photo-editing service. The browser would then either connect to your favorite online photo editor or offer a list of options.

In practice Web Intents work a bit like mailto: links, defining an action and then passing it along to the browser, which allows the user to choose how to handle the action. The difference is that instead of opening a desktop app, Web Intents connect to web services. Here’s a barebones example of what the tag looks like (taken from webintents.org):

<intent
  action="http://webintents.org/share"
  type="image/*"
  href="image.html"
  title="Kinlan's Image Share" />

In this example the browser would then give the user a list of registered image sharing apps — services like Twitter, Facebook, Google+ and so on — which the user can choose from.

Part of what makes Web Intents appealing is that it decouples services. Instead of waiting for Flickr to support the latest and greatest online photo editor, Flickr could simply add an intent tag and let you choose any editor you like, including that cool new one that’s still a private beta. Flickr would simply pass the image to the editor of your choice and when you’re done tweaking your photo the editor would then pass the final image back to Flickr.

Other use cases for Web Intents include choosing a preferred search engine, cloud printing, logging into websites and, of course, sharing something on your preferred social networks.

For some more background on Web Intents, check out Paul Kinlan’s blog, particularly his overview post on the brief history of Web Intents and his follow-up on using the Web Intents JavaScript APIs in Chrome. Tantek Çelik, the creator of microformats, also wrote a nice post last year on what he calls Web Actions (same thing, better name). Çelik breaks down the idea behind Web Intents and how they benefit not just developers, but users as well.

As Çelik writes, “web actions have the potential to change our very notions of what a web application is from a single site to loosely coupled interactions across multiple, distributed sites…. In that regard, web actions have the potential to become a building block for distributed web applications.”

Web Intents are a long way from a finalized standard and while many things may change before other browsers add support, if you’d like to get a sense of what you can do with Web Intents and how they work in practice grab the latest WebKit nightly build and point it at the examples page on webintents.org.

Image: Aidan Jones/CC/Flickr

Photo: Ariel Zambelich/Wired.com

The W3C continues to wrestle with the problems CSS vendor prefixes are causing the web. While they’re useful for web developers, prefixed CSS rules as they are currently known may be causing more problems than they solve. Now W3C member Florian Rivoal has proposed a new solution to the prefixing problem.

CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. The idea was to move the web forward without rushing the CSS standards process. Unfortunately, it hasn’t always worked out that way.

Rivoal blames the prefix policy itself, writing, “I believe the current prefixing policy is hurting more than it helps, and that the problems are fundamental to the policy itself, rather than something that can be blamed on various parties for not following it correctly.”

The result is that the web is now in a situation where browsers are planning to start supporting other browser’s prefixes, which just might defeat the entire point of having web standards.

Rivoal’s proposal would change the way prefixes currently work and would solve some, though probably not all of the problems. Here’s Rivoal’s full proposal:

When a browser vendor implements a new CSS feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.

Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.

If a large amount of content accumulates using a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.

The biggest win for web developers — should Rivoal’s proposal be implemented — is that it greatly simplifies the process of trying new features. It would give developers the tools they need to work around individual browser quirks with new features, but is less likely to lead to a situation like today, where WebKit-only CSS rules litter the web.

Another nice benefit of Rivoal’s approach is that it solves the Opera dilemma — that no one is using prefixes for less well-known browsers. “No browser, however new or obscure, would have the problem of being excluded,” writes Rivoal, “authors might not test in it, but if the browser does a good enough job of implementing the property, sites will render as intended.”

Obviously this proposal is just that, but there’s already an extensive dialog on The W3C’s www-style mailing list and it appears that most members are supportive, though some have expressed reservations and possible problems. Mozilla’s Henri Sivonen does a nice job of addressing many potential issues and shortcomings in a very long, thorough post to the mailing list.

It will likely be some time before any changes are made to the way vendor prefixes are handled, and of course none of this solves the problem that’s already on the web today. But, hopefully, with a few changes to the way prefixes work, the web can avoid the WebKit-only problem in the future.

Photo: Jim Merithew/Wired

Last year Mozilla launched MemShrink, an aggressive campaign to trim Firefox’s memory footprint. Since then not only has the browser’s overall memory use dropped considerably, but the effort has been expanded to tackle add-ons, a common source of Firefox memory woes.

Now Mozilla programmer Nicholas Nethercote, head of the MemShrink effort, reports that a new patch to prevent Chrome-to-Content leaks in Firefox add-ons results in “a 4x reduction in memory consumption.”

The new code is currently in Firefox’s Nightly channel for those that would like to help test it against a wide variety of add-ons.

Firefox contributor Kyle Huey, who wrote the new patch, has more details on how it works and where the memory leaks in add-ons come from. Huey writes that “it’s a little early to be sure what effects this will have, but the amount of leaks we see on our test suite dropped by 80 percent. I expect that this change will also fix a majority of the add-on leaks we see, without any effort on the part of the add-on authors.”

Unfortunately the hope that add-on developers wouldn’t need to do anything to reduce their memory use hasn’t panned out. Mozilla has since discovered that “there is an unfortunate side-effect of all this amazing, memory saving goodness which directly affects add-ons that have been packed with older versions of the SDK.” Mozilla is now asking add-on developers using older versions of the Firefox add-on SDK to repack their add-ons before the MemShrink efforts arrive in a final version of Firefox.

Luckily for Firefox fans there’s plenty of time for affected add-ons to be updated since the latest MemShrink efforts won’t make it to the final release of Firefox for at least another 12 weeks. When they do Firefox users will hopefully see a considerable drop in Firefox’s memory use making for a faster, less RAM-hungry web browser.