Photo: Ariel Zambelich/Wired.com

Yesterday we told you about a disturbance in the web standards force, a supposed rash of websites that work in one and only one web browser. Instead of writing code that will work in any browser many developers are coding exclusively for WebKit, the engine that powers Safari, Chrome, iOS and Android web browsers.

The problem is bad enough that on Monday at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t.

We aren’t the only ones who think that spells disaster not just for web standards but for the long-term viability of the open web. In fact the response from the web community has all but drowned out everything else in our RSS and Twitter feeds.

Here’s our round-up of what’s being proposed, what it might mean for the web and how we might go about solving the problem:

First and foremost read the minutes from the CSS Work Group meeting, which is where all of this started. The legend for the names is at the top of the page, though you’ll need to scroll about half way down to get to the actual meat of the discussion.

The second must-read post on vendor prefixes comes from CSS Working Group Co-Chair Daniel Glazman who calls on other browser makers to not implement the -webkit prefix and asks developers to make the extra effort to build cross-browser apps. Glazman has since followed up that piece with two more, one clarifying the original post and one defending the CSS Working Group against those who argue that the reason prefixes exist is because the standards process is too slow. If you believe that the CSS spec moves to slowly, this post is well worth a read (spoiler alert: it’s typically browser makers arguing, not the standards process, that creates the hold up on new features).

Remy Sharp of HTML5Doctor fame, weighs in with a series of rough ideas, neatly summarizing the issue and looking at it from both sides. In the end Sharp seems to conclude that just about everyone is to blame, from the browsers to the working group to developers.

Rachel Andrew of the web standards project generally agrees with Glazman writing, “once again we run the risk of having sites built only for one platform, and [will] find it very hard to get that platform to go away if things move on.”

The ever-humorous Bruce Lawson, who works as a web standards evangelist at Opera Software, writes: “Personally — PERSONALLY — I’m pretty depressed about all this. I’ve spent 10 years — pretty much since IE6 came out — evangelizing cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.”

Over at Quirksblog mobile expert Peter-Paul Koch argues that vendor prefixes are just plain wrong: “Vendor prefixes are the most developer-hostile solution imaginable. The vendor prefix idea was flawed from the start by putting the full brunt of namespace management on web developers.” He goes on to propose an interesting idea of vendor-neutral prefixes like -alpha and -beta for experimental features.

Aaron Gustafson, a member of the Web Standards Project, has started a petition to ask Mozilla, Microsoft and Opera to not implement -webkit. Gustafson also has a one-line bash script you can use to search your code for any instances of the -webkit prefix so you can double check to make sure you’re supporting other browsers as well.

Mozilla developer Christian Heilman believes that “this mess has partly been created by developers, the least we can do is help fix it.” To that end Heilmann’s Pre-fix the web project is looking for developers willing to seek out projects on Github that only work in Webkit and then fork the project, adding the missing prefixes to the CSS, extending JS code to do proper feature detection and then sending a pull request. In other words, literally fixing the web.

JavaScript developer Peter van der Zee has some other possible solutions: “Either we strongly limit the life span or availability of the prefix by making them only available in beta versions of a browser. Or we force other vendors to pick up on the slack by giving them a certain time to come up with their own implementation of a certain feature, or forfeit that possibility after a certain amount of time.”

Finally, if you read through the CSS WG notes you’ll notice that Tantek Çelik cites developer Lea Verou as an example of web developers who use just the -webkit prefix. In fact that’s completely untrue and Çelik has since corrected his statement. Verou has long advocated using all prefixes and even created prefixfree to help automate the process.

WebKit may seem like the only game in town, but it's not. Photo: Ariel Zambelich/Wired.com

It sounds like something from a galaxy far, far away, but in truth it was not that long ago that the web was littered with sites that proudly proclaimed “works best in Internet Explorer.” Thankfully those days are over. IE6 no longer dominates the web.

But, while IE6 may be a thing of the past, the root problem — websites that work in one and only one web browser — sadly, remains.

This time the culprit is WebKit, the rendering engine that powers the browsers on the iPhone, iPad and Android phones. But what’s different about this round of monoculture is that, unlike IE 6, the WebKit developers haven’t done anything wrong. It’s web developers that have created the WebKit-only web.

Instead of writing code that will work in any browser, which might mean adding an extra three lines of code to their CSS rules, some of even the largest sites on the web are coding exclusively for WebKit.

The problem is bad enough that on Monday at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t.

The danger is that if other browsers implement -webkit prefixes then the entire CSS standards effort will be broken. Instead of coding against a single CSS specification developers will need to code against changing vendor prefixes. As CSS Working Group co-chair, Daniel Glazman, says, “I don’t think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.”

Vendor prefixes like -webkit and -moz were designed to help web developers by allowing browser makers to implement CSS features before the official standard was published. Prefixes were intended to help speed up the process of adding new features to the web and, used properly, they have worked. Unfortunately they’ve also been widely abused.

WebKit is currently the dominant mobile browser in the mind of most web developers (that Opera is actually the single most widely used mobile browser). But even the perceived dominance of WebKit is not the real problem. The problem is — just as it was last time — that web developers are developing exclusively for WebKit.

To be clear, Firefox, IE and Opera also support these features. In most cases, the -webkit properties being used have -moz, -ms and -o prefix equivalents for use in the respective browsers. Popular CSS 3 features like border-radius, transforms, gradients and animations work in all modern browsers. Developers simply need to add those three additional lines of code to make their websites compatible with Firefox, IE and Opera. But they aren’t doing that.

That the problem lies with web developers, not the browsers, led Glazman, to put out a call for action, asking web developers to “stop designing web sites for WebKit only, in particular when adding support for other browsers is only a matter of adding a few extra prefixed CSS properties.”

Neither Glazman, nor anyone else is suggesting that Apple and Google should stop innovating or stop implementing new features as fast as they can. As Tantek Çelik, a Mozilla representative in the CSS WG, says in the minutes of Monday’s meeting, “I think it’s great that Apple wants to innovate as fast as they can…. I don’t want Apple to slow down in innovation and implementing new things. That helps the Web grow and innovate.”

At the same time both Apple and Google have set some bad examples by building a number of WebKit-only demos that might be part of what lead some developers to conclude that only WebKit supports such features. That has also spilled over into the world of tutorials where even sometimes even standards advocates showcase -webkit in their sample code while ignoring -moz-, -ms- and -o-*.

What makes the current -webkit-only epidemic all the more depressing is how easy it is to solve — just use prefixes they way they were intended. Thanks to modern toolkits you don’t even need to write any extra code. Preprocessors like SASS and LESS make it easy to output five lines of prefixed code with a single mixin. Not a fan or SASS or LESS? No problem, just use cssprefixer, which parses your CSS and adds any prefixes you need before you publish it to the web (there’s also a client-side auto-prefixing solution if you prefer).

That’s fine for your website, but what about all the rest of those top 30,000 sites you don’t control? Well, you could email the developers, let them know that their site isn’t working in the most popular mobile web browser; let them know that you can’t use their service. If you’re a programmer or web developer you can help out with Mozilla developer Christian Hellman’s effort to Pre-fix the web. Pre-fix the web is looking for developers willing to seek out projects on Github that only work in Webkit and then fork the project, adding the missing prefixes to the CSS, extending JS code to do proper feature detection and then sending a pull request. In other words, literally fixing the web.

We at Webmonkey hope it’s obvious that building WebKit-only sites is a waste of time. If you’re only interested in iOS users then take a tip from Instagram and build a native app. As Peter Linss, Hewlett-Packard’s CSS WG representative says the CSS WG minutes, “there’s no advantage to the Web to have someone write a platform-specific website.” There’s also no real advantage for the developer, especially when an automated prefixer can do all the work for you. If you want your site to embrace the web, take the time to learn the craft and embrace all of the web. Be good at what you do and do it right.

The new Chrome introduces a “preemptive rendering” feature that will automatically begin loading and rendering a page in the background while the user is typing the address in the omnibox (the combined address and search text entry field in Chrome’s navigation toolbar). The preloading will occur in cases when the top match generated by the omnibox’s autocompletion functionality is a site that the user visits frequently.

When the user hits the enter key and confirms the autocompletion result, the pre-rendered page will display almost instantly. The feature extends Chrome’s existing predictive page loading functionality to autocompletion results. Unlike Chrome’s instant search capability, however, the autocompletion preloading waits until the user hits the enter key before displaying the rendered page.

Google has also added some new security functionality to Chrome. Every time that the user downloads a file, the browser will compare it against a whitelist of known-good files and publishers. If the file isn’t in the whitelist, its URL will be transmitted to Google’s servers, which will perform an automatic analysis and attempt to guess if the file is malicious based on various factors like the trustworthiness of its source. If the file is deemed a potential risk, the user will receive a warning.

Google says that data collected by the browser for the malware detection feature is only used to flag malicious files and isn’t used for any other purpose. The company will retain the IP address of the user and other metadata for a period of two weeks, at which point all of the data except the URL of the file will be purged from Google’s databases.

Users who are concerned about the privacy implications of this functionality can prevent the browser from relaying this information to Google by disabling the phishing and malware protection features in the browser’s preferences. You can refer to the official Chromium blog for additional details about the malware detection feature.

Chrome 17 is available through the browser’s automatic updater and can also be downloaded from Google’s website. More information about the new release is available in the official Google Chrome blog.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Photo: Ariel Zambelich/Wired.com

One common problem when designing for multiple devices is handling the changes that happen when the user rotates the screen. It’s frustrating to see your elegant portrait-oriented designs fall apart as the device moves to landscape mode (or vice versa). Frequently the problem is that images, videos and other embedded content in your page is sized in relation to the pixel width of the viewport, but the type is not. That means that the type fails to adapt to layout changes, leaving ugly gaps, whitespace or hard-to-read, overly long lines.

There are a number of ways to solve this problem, but one of the simplest and easiest is to use fluid typography in addition to your fluid grid. BBC developer Mark Hurrell wrote up an excellent tutorial some time ago that shows how, by specifying font sizes in rems, you can “adjust every font-size on the page by using media-queries to change the font-size set on the BODY or HTML element according to viewport width.”

To find the right size type for various screen widths, Hurrell calculates a resolution-independent font scale based on target widths. That is then applied using a series of media queries and the new CSS 3 unit rem. The rem unit means ems relative to the root (the HTML) element. That means your type gets proportionally larger overall, rather than in relation to its parent element as would happen with a simple em. As Hurrell notes, support is pretty much universal on tablets and phones (browsers that don’t support it will fall back to px sizing, so all is not lost).

In the end what you get using rems and media queries is fluid typography that scales just like a fluid grid. That means that when the device rotates the type resizes to fit the new screen dimensions. For more details on how to make it work on your site be sure to check out the Responsive News blog post, which also has a few links to websites already using this trick.

Adobe has issued a statement confirming that Chrome for Android does not support Flash content. The company also indicated that it does not plan to work with Google to add Flash support to the new mobile browser. Adobe will, however, continue supporting Flash in the current default Android browser.

“Today Google introduced Chrome for Android Beta. As we announced last November, Adobe is no longer developing Flash Player for mobile browsers, and thus Chrome for Android Beta does not support Flash content,” wrote Adobe’s Flash Platform product manager Bill Howard.

Adobe struggled for years to make the Flash player plugin viable on mobile devices. Though it was able to make Flash work reasonably well on Android phones, results were mixed on other systems. Due to Apple’s unwillingness to allow the Flash plugin on iOS and the difficulty that Adobe faced bringing the Flash player to new devices, the plugin never achieved the same ubiquity on phones that it has historically enjoyed on the desktop.

These setbacks caused Adobe to abandon its mobile Flash player strategy last year. The company announced that it would phase out development of its mobile Flash player plugin and not support it on new platforms. Adobe instead focused its mobile Flash efforts on developing tools for deploying Flash content as native mobile applications. It also strengthened its commitment to native web standards and acknowledged HTML5 as the way forward for building rich mobile web experiences.

When Google eventually moves to replace the default Android browser with Chrome in future versions of the Android platform, devices that run the operating system will likely no longer be able to play Flash content in the browser.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

If you’d like to test the new Flash Player Protected Mode for Firefox on Windows 7 or Vista, head over to the Adobe Labs download page. Bear in mind that this is a beta release and may contain some bugs.

The new sandbox feature for Flash in Firefox will provide extra protection against malicious browser exploits launched through the Flash Player. Sandboxing means that even when such attacks succeed, the damage is limited and won’t spill over into the rest of the browser or even the operating system.

The design of the Flash sandbox is similar to what Adobe uses in its Adobe Reader X Protected Mode. “Since its launch in November 2010, we have not seen a single successful exploit in the wild against Adobe Reader X,” writes Peleus Uhley, senior security researcher for Adobe. Uhley goes on to say that Adobe is hoping to “see similar results with the Flash Player sandbox for Firefox once the final version is released later this year.”

While Adobe has ceased development of mobile Flash, the company continues to develop and improve Flash for the desktop. HTML5′s canvas and video elements — among others — are designed to remove the need for plugins like Flash on the web. However, HTML5 support remains incomplete even in the newest browsers, and Flash will likely remain a necessary part of the web video and animation world for the foreseeable future.

The browser will stop querying CRL, or certificate revocation lists, and databases that rely on OCSP, or online certificate status protocol, Google researcher Adam Langley said in a blog post published on Sunday. He said the services, which browsers are supposed to query before trusting a credential for an SSL-protected address, don’t make end users safer because Chrome and most other browsers establish the connection even when the services aren’t able to ensure a certificate hasn’t been tampered with.

“So soft-fail revocation checks are like a seat-belt that snaps when you crash,” Langley wrote. “Even though it works 99% of the time, it’s worthless because it only works when you don’t need it.”

SSL critics have long complained that the revocation checks are mostly useless. Attackers who have the ability to spoof the websites and certificates of Gmail and other trusted websites typically have the ability to replace warnings that the credential is no longer valid with a response that says the server is temporarily down. Indeed, Moxie Marlinspike’s SSL Strip hacking tool automatically supplies such messages, effectively bypassing the measure.

“While the benefits of online revocation checking are hard to find, the costs are clear: Online revocation checks are slow and compromise privacy,” Langley added. That’s because the checks add a median time of 300 milliseconds and a mean of almost 1 second to page loads, making many websites reluctant to use SSL. Marlinspike and others have also complained that the services allow certificate authorities to compile logs of user IP addresses and the sites they visit over time.

Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch. The time frame for the Chrome changes to go into effect are “on the order of months,” a Google spokesman said.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

The JS1K contest seeks the web’s best JavaScript creations, with one small catch — the code used must be less than 1k. It might sound insane considering that some JavaScript frameworks — just the frameworks! — are over 100k, but since it began several years ago, JS1K’s experiments have never failed to impress.

One of this year’s most jaw-dropping efforts to date is developer Román Cortés 3-D rendering of a rose. Relying on Monte Carlo methods to keep the code size down, Cortés’ code draws a very nicely shaded 3-D rose for the love-themed 2012 edition of JS1K. You can check out the live demo on the JS1K website.

One word of warning: Part of what makes Cortés’ rose so small is that much of the heavy lifting is handed off to the processor. The demo code brought my CPU use over 100 percent and kept it pegged there the entire time it was open in Safari. Firefox and Chrome both managed to keep the number down to roughly 93 percent, but suffice it to say that a procedurally generated 3-D rose will tax your CPU.

To see how Cortés created the code behind the rose, be sure to visit his blog which offers a very thorough tutorial explaining how and why the code works. There’s also a great write-up on Cortés’ previous JS1K effort, a 3-D Christmas tree. Also be sure to check out the other submissions to this year’s JS1K contest on the JS1K website.

If you’ve got some impressive but terribly small bit of JavaScript code up your sleeve, fear not; the JS1K contest will continue accepting submissions through Wednesday, March 14, 2012. Details on the rules and submission process can be found on the JS1K website.

The relevance of proprietary browser plugins is declining as standards-based web technologies mature. Native web technologies don’t yet supply complete functional equivalence with the capabilities of plugins, but the open web has the advantage of greater ubiquity.

The ubiquity of native web standards over proprietary plugins is set to get a major boost from Microsoft with the launch of Windows 8 and Internet Explorer 10. As we have previously reported, the next major version of Microsoft’s web browser will not display plugins in the Metro environment, which will be the default shell in Windows 8.

A plugin-dependent website prompting the user for permission to run on the desktop. Image courtesy of Microsoft

Microsoft has published a series of posts in its official IE development blog that discuss the implications of this change and what it means for users and web developers. In a new post published this week, IE program manager lead John Hrvatin highlighted the advantages of plugin-free browsing and emphasized the need for web developers to start supporting users who browse in environments that don’t have plugins enabled.

“The transition to a plug-in free web is happening today. Any site that uses plugins needs to understand what their customers experience when browsing plugin free. Lots of web browsing today happens on devices that simply don’t support plugins,” he wrote. “Metro style IE runs plug-in free to improve battery life as well as security, reliability, and privacy for consumers.”

A growing number of websites that rely on browser plugins already offer a standards-based fallback for users who are browsing on popular plugin-free devices such as as the iPhone or iPad. Microsoft has previously discussed some of the steps it is taking to ensure that those websites serve their plugin-free content to Metro users.

There will still likely be many Flash-heavy websites, however, that can’t accommodate users who are browsing without plugins. In the blog post, Hrvatin explained that such websites can ask the user for permission to jump to the conventional Windows desktop and launch the windowed version of Internet Explorer, which will have full support for plugins.

Web developers can get the browser to display the prompt by including the special requiresActiveX=true property in an X-UA-Compatible meta tag or HTTP header. Hrvatin cautions that this feature is included for transitional purposes and is intended to serve as a last resort. The preferred behavior is still for web developers to display a plugin-free version of their site to users who are browsing in the Metro environment.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Firefox’s developers decided last year to transition the browser to a time-based, six-week release cycle. The new release management strategy ensures that performance improvements and support for new web standards reach users as soon as possible. The faster release cycle posed challenges, however, for enterprise adopters and other users who require a longer support period. In order to address that issue, Mozilla has decided to offer an annual extended support release with a full year of updates. Firefox 10 is the first official extended support release.

A minor adjustment to the browser’s navigation bar is the biggest user-facing change in Firefox 10. The forward arrow button is no longer persistently visible by default in the navigation toolbar. It will only appear when the user navigates back a page. That means the button only shows when it can be activated. When the user clicks the forward arrow button and returns to the front of the history stack, the button will disappear again.

The distinctive keyhole shape that is formed by the back and forward buttons in Firefox’s navigation toolbar has been characterized in the past by Mozilla designers as an important part of the browser’s visual identity. Much like the angular tabs in Chrome, it’s an aesthetic characteristic that is uniform across platforms and helps make the browser recognizable.

The user interface change in Firefox 10 will make it so that the keyhole shape is only visible when the user navigates back. The feature worked predictably in our tests and didn’t pose any problems in practice. It’s worth noting, however, that it doesn’t appear to be available when the user has toggled the preference for small toolbar icons.

The new developer tools in Firefox 10

Another major change in Firefox 10 is the introduction of new developer tools. Previous versions of the browser have included a web console, a JavaScript scratchpad, and a simple tool for inspecting the Document Object Model (DOM). Firefox 10 has a new tightly-integrated developer panel with a richer DOM inspector and a tool for viewing, toggling, and modifying CSS properties.

The DOM inspector follows your cursor as you move it over elements of the page and will lock in on an element when you click. An HTML pane at the bottom of the screen will show you the markup for the target element and allow you to modify the values of element attributes. The HTML inspector pane also has a slick breadcrumb bar that makes it easy to see the position of the target element in the page hierarchy.

The CSS inspector will show you a list of CSS properties associated with the selected element, including inherited properties. Each one has a checkbox that you can click to toggle visibility. You can also click one of the values to replace it on the fly.

These built-in development tools in Firefox are simpler and less intrusive than more sophisticated alternatives such as the Firebug add-on. There are a number of additional features under development that will be included in the inspector panels in future versions of the web browser. One of the most intriguing is a tool that uses WebGL to show the user a three-dimensional representation of the page DOM. That feature wasn’t ready for inclusion in Firefox 10 and will potentially appear in the next major release.

In addition to the new inspector, web developers can also look forward to improved support for web standards. An addition of particular significance is a new full-screen API, which makes it possible for an individual HTML element to break out of the browser window and stretch itself to cover the entire screen. This feature is going to be especially useful for videos and games. You can see it in action by visiting Mozilla’s fullscreen demo page.

We first wrote about the full-screen API in November, when the feature originally landed in nightly builds. Mozilla carefully considered potential abuse scenarios when implementing the feature. It’s designed so that an element can only switch into fullscreen mode in response to a direct user action. The browser ensures this by using a technique similar to the one used to block unwanted popup windows.

Another addition in this release is support for 3D CSS transforms. This feature, which was originally created by Apple, offers a declarative mechanism for applying animated three dimensional transformations to individual HTML page elements. It’s important to note that 3D CSS transforms are entirely distinct from WebGL, which is a low-level JavaScript API for 3D programming.

Support for 3D CSS transformations is a welcome addition to the browser. Developers are already using the feature in the wild, but most of the existing 3D CSS content was authored with WebKit-specific prefixes and consequently won’t work in Firefox yet.

Firefox 10 is a solid release that expands the browser’s capabilities. Although the lineup of new features is slim, it’s a respectable update by the standards of the rapid release model. The new version will be pushed out through the Firefox update system shortly. Firefox 10 can also be downloaded directly from the Mozilla website. For more details, you can refer to the official release notes.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.