Apple and Google’s use of non-standard CSS features in its mobile browsers is causing quite a bit of outrage around the World Wide Web Consortium (W3C). At this week’s meeting of the CSS Working Group, the implications of Google and Apple’s mobile browsers were compared with those of Internet Explorer 6. Gasp. Are things really bad enough to hurl the techie explicative? Unfortunately, yes they are.
Back to the Future
Standards development is never an easy process. Most people would rather not bother thinking about them until they are affected by the absence of standards -- cords that you can only obtain from the maker, software that works with one configuration or web pages that work in one browser. This is the type of chaos the W3C tries to prevent on the Internet.
Despite its best efforts, things occasionally go wrong, like the long, dark age of Internet Explorer 6 (IE6). For over a decade, Microsoft’s much-maligned browser dominated the desktop browser market. The browser was far from standards-compliant, but because it was so widely installed, the web was filled with sites that only worked on IE6. The browser was so problematic that even its creator has rejoiced at its demise.
Although Microsoft has mostly fallen in line and embraced standards; IE6-style problems are rearing their heads again in the mobile market. WebKit, which is a core technology in Safari and Chrome on iPhones, iPads and Android devices, has emerged as the dominant mobile browser platform. The platform is so dominant that many web developers have begun implementing sites that check for WebKit support and will not display if it’s not present. Many of the features in WebKit are now supported in CSS, but even when mobile browsers like Firefox, Internet Explorer or Opera support them, the sites deny access, creating a frustrating user experience, which often causes users to abandon alternative mobile browsers.
The problem exists because of the way standards typically advance. New features are introduced in the market due to innovations in specific browsers. Although the features may eventually become standards, initially they only work in one browser. Developers that wish to use these features reference them using a prefix, which indicates the feature only applies to a limited platform. Once the feature is standardized, the prefix can be removed. What has happened with WebKit is that developers use the “-webkit” prefix, which is specific to Safari and Chrome, and no prefixes for other browsers, even when they support the feature in question.
Is It Too Late?
Daniel Glazman, Co-Chairman of the W3C CSS Working Group, has issued a call to action based on the W3C discussion and his personal position. Glazman asks authors to:
- Stop designing sites for WebKit only
- Stop implementing WebKit-based browser sniffing immediately
- Stop recommending sites that require a single browser implementation. He even suggest blacklisting the sites
- Update online services to support other browsers if the other browsers offer a level of CSS support they didn’t support previously
- Complain to web authors that implement sites that only work in one rendering engine
Glazman also appealed directly to Apple and Google to submit technical proposals to the CSS Working Group for their proprietary CSS-like properties.
It may seem like Glazman is going overboard, but the issues he fears are not what-if scenarios that only exist in the minds of standards bodies and theorists. Mobile browser makers are officially stating they have no other choice but to disguise themselves as WebKit browsers. This isn’t just an issue for browser makers. Organizations that produce content must spend more time developing and testing features across multiple browsers when standards aren’t applied consistently.
Are we destined to repeat the mistakes of the past, or will site designers embrace open standards? We will definitely be watching to see if the W3C’s warnings have any impact.