All posts tagged ‘Webkit’

File Under: CSS, Web Standards

Web Developers Sound Off on WebKit Prefixes

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.

File Under: CSS, Web Standards

WebKit Isn’t Breaking the Web. You Are

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.

Adobe Shows Off Fancy WebKit-Based Typography

Typography on the web has improved by leaps and bounds since the dark days of the blink tag, but it’s still a long way from ideal.

Sure there are great ways to serve custom fonts, and you can even use JavaScript libraries like Lettering.js for even more control over your layout. But when it comes to the flow of text around images, pull quotes and other block level elements, well, web typography falls apart.

The demo movie above from Adobe shows off some WebKit-based experiments that seek to change that. Adobe Engineering VP Paul Gubbay narrates and the demo, and he shows how his team is extending the WebKit browser to do some new typographic tricks. WebKit is the open source engine behind Safari and Google Chrome, and it powers the most popular mobile browsers like the ones on the iPhone, iPad, iPod and all the Android phones. The demo certainly shows some impressive results.

However, we’re a bit suspicious of the methodology behind the results. Gubbay talks about extending WebKit’s CSS support via vendor prefixes, but neglects to mention what those prefixes are built against — in other words, there’s no mention of submitting a standard that other browsers could work from.

In fact, while the demo is pretty cool, the whole overview is too vague to say much about other than, “that would be nice.”

Also, note to Adobe, you don’t need to work with Google to work on WebKit. It’s an open source project. You can just submit your patches (instructions are here).

[via John Nack]

Update: The original post got Paul Gubbay’s name wrong. We have updated it. (Sorry, Paul!) Also, be sure to read his response in the comments.

See Also:

File Under: HTML5, Web Standards

Chrome Shows Off Some Fancy HTML5 Tricks

Google’s Chrome browser has a well-established reputation for being not only extremely fast at rendering executing JavaScript, but also robust in its support of cutting-edge HTML5 technologies.

Both of these capabilities are on display at Chrome Experiments, a site that Google set up to showcase some of the coolest demos on the web for JavaScript apps, intricate CSS layouts and animations done with Canvas.

Chrome Experiments now has over 100 demos on offer, and we picked out some of our favorites for this little gallery.

Interest is exploding in HTML5 and its companion technologies. The hope is that these emerging standards will be widely used to power new web apps, as well as for playing animations, songs and videos in the browser without any plug-ins. Developers and content providers continue to rely on plug-ins like Flash or Silverlight for such multimedia playback tasks for now, but they are increasingly turning to HTML5, JavaScript and other web standards as browser makers continue to build the new capabilities into their latest releases.

We tested all of these experiments in multiple browsers, and almost all of them worked in Safari and Firefox, though they performed much better in the latest beta of Firefox 4 than in the current stable Firefox 3.x builds. Some of them also work splendidly in the latest Microsoft pre-release, Internet Explorer 9 preview 3.

Of course, a few of the Chrome demos on the Experiments site use Webkit-specific technologies and CSS prefixes, so those only work in Chrome and Safari. Some have poo-poohed vendor-specific prefixes, and others see them as a necessary step to force browser makers to adopt the latest behaviors being used in the wild. Regardless of that debate, it’s encouraging to see the different browsers all improving their JavaScript capabilities, which all of these demos exploit.

In short, you don’t need Chrome to view these, but they will all be more impressive in Chrome than in other browsers.

Continue Reading “Chrome Shows Off Some Fancy HTML5 Tricks” »

File Under: Software & Tools

Stainless Browser: Google Chrome For the Mac

Another day, another browser. Stainless was released by Mesa Dynamics as a proof of concept. The concept? A working, less ambitious version of Google’s Chrome browser.

According to the Stainless website, it is available (for free) now simply because the project is less ambitious than the eventual version of Chrome on the Mac. Besides the fact that it doesn’t have all the robust backend features Chrome will eventually have on its Mac version, from an end-user’s perspective it’s Google’s Chrome browser in all its speed and simplicity.

Stainless runs on Mac OS X Leopard — but only Leopard. Tiger enthusiasts may have to hang tight for Google’s eventual Mac release or use the variety of other browsers (Firefox, Safari) available.

Chrome and Stainless have a lot in common. At first glance, both browsers have almost identical streamlined interfaces. There is little to no clutter on the screen. The tabs line up at the top of the screen without menus maximizing web space. New tab windows are created by a little plus sign on the browser menu.

Stainless is a very stripped down browser. For evidence of this, look no further than the preferences panel. There are literally two options: A pulldown menu to designate what will open on startup — a welcome page or a home page of your choosing. The other option allows you to choose a default search from the address bar.

It does combine the address book with search, a feature now typical in all new browsers. Whether you call it the awesome bar (Firefox) or Quick Find (Opera) or whatever, the search and address fields are becoming more and more the same thing in all browsers.

There are plenty of proof of concept (read: alpha) issues too. Flash 9 is installed and video runs smoothly, but support for other plug-ins and add-ons are out. The major stopping block to making Stainless your default browser is it has no download manager, and therefore, no way to download anything.

It takes a bit more memory per tab than, say, Firefox, but it makes those tabs a fortress onto their own. If one tab breaks, it doesn’t take the browser down with it. When a tab is closed, the memory for the tab is freed.

The company and its multi-process design was inspired not only by Chrome, but also on a web-wrapper application called Hypercube. Hypercube is able to take widgets, gadgets and Flash movies from the web to your desktop. The way Hypercube is structured, running each widget on a different process, inspired the company to try out a browser.

The browser is based on Webkit — the same HTML rendering technology as Apple’s Safari and Google’s Chrome. There’s no word on what kind of JavaScript engine it’s running — Safari runs JavaScriptCore (soon Squirrelfish Extreme) and Google runs V8.

Stainless joins another Chrome look-alike on the Mac scene, Codeweaver’s Crossover Chromium. Unlike Stainless, Crossover Chromium actually runs the Windows version of Chrome on a Mac desktop, albeit very slowly.

Taking a step back, the benefits of a streamlined browser like Stainless, or even Chrome, is it doesn’t make any promises. It won’t email or clutter things with buttons or programs you’re not sure of. It is stable as an application can be. Stainless adheres to this idea, ensuring all tabs run its own processes.

What this browser is, even if you consider it was not made to be taken seriously, is a bare bones window to the internet. A browser and a search bar and not much else. Perhaps this is what everyone really needs to allow the features of web applications speak for themselves. Speed and stability is important, but in this case, I doubt it. If Stainless is an indication of the future of open-source browsers, expect many more third-party browsers running off of existing rendering technology.

Luckily, because most of these new browsers will be working off of existing open-source rendering code, web developers will only have to work for the underlying rendering engines, and not the browsers themselves. For example, even if there are 100 Webkit-based browsers, I only need one Webkit-enabled webpage for them all.

Besides, it’s not likely these alternative browsers are going to get much traction. The jury isn’t out yet, but in spite of a first month spike in browser usage across the web, Chrome hasn’t taken much market share from its Windows competitor Internet Explorer or its runner-up Firefox. It is not like Chrome rip-offs like Stainless will do the same for Mac users either.

File Under: Software & Tools

WebKit Sails Smoothly Through ACID 3 Tests

ACID 3 testWebKit, the rendering engine that powers browsers Safari and Chrome, among others, says it has passed all three stages of the ACID 3 test. The test checks how well a browser supports JavaScript and the Document Object Model (DOM), as well as a few other treats, like SVG graphics. You can check your browser here.

Opera and WebKit passed the first two stages of the ACID 3 test shortly after its release in March. These measure the actual tests themselves (100/100), plus the pixel-perfect appearance of the page. The final stage, “smooth animation,” has been a more difficult task. The passing version of WebKit does render for me without hiccups, but there appears to be no solid definition of “smooth.”

On the official release browsers I have access to, the highest score was a 75, for Safari 3.1.2. Firefox 3.0.2 was close with a 71.

Shortly after WebKit and Opera passed the test, Mozilla’s Mike Shaver said Firefox would not scramble to pass the tests and that ACID 3 was a missed opportunity:

“Acid 3 could have had a tremendous positive effect on the web, representing the next target for the web platform, and helping developers prioritize work in such a way as to maximize the aggregate capabilities of the web. Instead, it feels like a puzzle game, and I can easily imagine the developers of the web’s proprietary competitors chuckling about the hundreds of developer-hours that have gone into adding another way to iterate over nodes, or twiddling internal APIs to special case a testing font.”

Regardless, some within the Firefox community appear to be working on it, reporting scores in the mid-90s earlier this month.

See also:

How Chrome Changed the Web Overnight

Nobody at Webmonkey expected to wake up and experience an internet game change today, but with Google’s semi-accidental launch of the Chrome browser Sunday, that’s exactly what we got. We barely had enough time to clean up the coffee spittle on our monitors.

It started with a very candid and thoughtful comic. It used drawn characters of Chrome designers to eloquently describe the browser’s inner workings. If it wasn’t in comic form, it would read like a computer science lecture, and you’d be asleep in the time it takes to say “garbage collection.” However, in comic form, the technical document gently exposes you us to just what we’re getting into.

So what are we getting into with Chrome? Perhaps web 3.0.

The way it manages tabs, the way it treats errors, its blinding speed — when Firefox 3 was released, it made Firefox 2 seems slow. Chrome does the same thing to Firefox 3. There’s no doubt this is a game changer in the world of web development. Even the surprise announcement lent a hand to making this as big of news as web news can get.

It may sound hyperbolic, but there is some serious machinery going on under the hood. Let’s break it down.

Chrome is essentially four open source projects bundled together: Chrome is the internet operating system, V8 the JavaScript engine, Gears for web developers and Webkit used for rendering HTML.

  1. Chrome — This is the first browser that incorporates the technology used in your desktop. Chrome basically acts like an operating system by treating tabs like applications. Each tab has its own protected memory, permissions and runs as its own process. If one misbehaves, you can pull up the Chrome task manager, see the processor and memory usage of the misbehaving site and close it on the spot.

    A very simple way to stress how revolutionary this is is to consider the fact that if you have a multi-core processor (as many desktop and laptops have these days), two tabs can render HTML and JavaScript independently on each processor, just as if you were running multiple desktop applications.

    This is similar to what Windows NT, and later XP, did with its protected memory in 2001. Protected memory was a popular selling point because it stabilized applications and allowed for better multi-threading. The same benefits apply to the multiple tabs of Chrome.

  2. V8 — Like Pinocchio became a real boy, JavaScript becomes a real programming language. Before, JavaScript was just a lightweight scripting solution that provided some cool effects. However, the way browsers were designed to handle it was for very moderate usage, like menus and simple interactive elements. AJAX web applications pushed the boundaries of what JavaScript was meant for. Google saw the potential in JavaScript, and grew impatient waiting for browsers to be able to handle what it was capable of. V8 puts away any doubt JavaScript can handle what you can give it. It even questions the need for add-ons like Adobe Flash or Microsoft’s Silverlight to enable rich web applications.

    Instead of virtually interpreting JavaScript, V8 compiles the code and managed to build a class/object relationship in the process, just like a grown up programming language. It runs blazingly fast, especially with those AJAX-y web applications you leave running in your browser all day.

    It has even included benchmarks to prove it.

  3. Gears — Because Gears has been around for over a year, there isn’t much to Gears that hasn’t already been said. Gears adapts some of the cooler functions of HTML 5.0 standards and adds an offline element to web surfing. It acts as the web developer friendly section of the Chrome package, enabling web developers to design faster and more powerful web applications. It is only fitting the technology is built into the browser.
  4. Webkit — Webkit is the only non-Google open source project included in the browser package. It stems from an Linux browser named Konqueror and, most recently, used for Apple’s Safari browser. Developers claimed the memory management and speed were among its top sellers. They also claimed the last thing web developers need is another rendering engine.

    They might be right. However, it is a bit of a slap in the face to Mozilla’s Gecko rendering engine. Given the financial and collaborative relationship Google has had with Mozilla in the past, it must be a hard pill to swallow in Firefox-land.

For its heavily asynchronous web applications to run better on a browser, Google acknowledged the browser needed to be redesigned from the ground up. It could’ve asked Mozilla to comply, and most likely it would have been rejected by Mozilla. Instead, it did the heavy lifting itself.

Much of the industry is now scrambling to try and figure out the Microsoftian threat Google poses. On the surface, Google is trying to redefine your window to the internet. When you consider how it deals with memory and how it protects your processes, it is, for all intents and purposes, the first successful combination of browser and operating system.

That said, how much of a threat can Google be if I (or you, or your neighbor) can jump in and write code for it? Releasing it under the BSD license, and even encouraging Internet Explorer and Firefox to steal code directly from the source, proves that Google wants nothing other than the capability to make their online properties more powerful. Google co-founder Larry Page sees Chrome as a way to increase competition and empower innovation in the long run.

“If there was only one choice [of browser], there wouldn’t be a lot of innovation out there,” Page proclaimed at a Chrome presentation Tuesday. “The web is really our connection to you, so it’s really important to us”

Sergey Brin, Google’s other co-founder, agrees: “Our business does well if there is a lot of healthy web usage … Our business does well if [people] are using the web and the internet a lot. Any usage of the internet through Chrome is a business win for us.”

The Chrome release and the way it treats web pages as applications is so innovative, it might have jumped years ahead of iterative advances from current browser offerings. It changes the game.

To the competition’s advantage, users may be slow to flock to Chrome. However, once they take it for a test drive, the speed of AJAX applications alone will set the bar high. It puts some heavy pressure on the browser competition to catch-up overnight.

Apparently, Mozilla developers were given an early peak at Chrome prior to the launch. How did it go? I’m sure the thoughts of threats swimmed in the minds of Firefox developers who have been working very hard on advancing browser technology for the last five years. Luckily, when you put any group of engineers together, the one common bond is on the coolness of technology. It wouldn’t be a surprise if the Firefox drawing board looks a little different today.

In fact, it wouldn’t be a surprise if it didn’t start incorporating the groundbreaking work done on the Chrome and V8 source — something Chrome developers want badly. They’re eager for this technology to hit the street, and they don’t care too much how it gets there.

What Internet Explorer will do with this information is anyone’s guess. Their closed source browser sports some definite “me too” functions and is advancing in speed, but Microsoft has real potential to incorporate the Chrome multi-processing technology in its Windows operating system. More likely, Microsoft will take the ideas and develop its own counter attack, however slowly it may take.

There is one fact with literally no doubt — the web has become a whole lot faster, more powerful and mind-numbingly fast overnight.

File Under: Mobile, Software & Tools

Torch Fires up Webkit-Powered Windows Mobile Browser

Torch Mobile’s Iris browser takes the power of the Webkit rendering engine to Windows Mobile devices. The mobile browser was released Tuesday.

The browser itself is not unlike the many iPhone Safari clones popping up around the mobile web since iPhones first hit the streets. You load up a page, the page appears as a mile-high overview, you double click in an area and it zooms in, you scroll the page with your finger. In fact, it has a lot in common with another full-fledged browser on Windows Mobile, Opera Mobile 9.5.

The significance of the Iris browser derives from how the page is rendered. In Iris’ case, the page is rendered using Webkit, the same powerful rendering engine behind Safari. Webkit is robust, fast and quick to jump on the newest and coolest web standards. It’s also an open source project, which means, thanks to Iris, Windows Mobile users won’t have to wait for Safari to be ported from the iPhone to Windows Mobile for the same web surfing experience.

Other features of the Iris browser include:

  • Multiple Windows and Tabs
  • Netscape plug-in API
  • HTML 4, JavaScript, CSS, bookmarks, cookies and cache (like we said, it’s fully powered browser)
  • Support for input devices and mobile hardware features such as touch screens, keyboards and rotatable screens

The browser playing field on Windows Mobile is a sparse one. Iris has entered the ring to compete with Opera for best Windows Mobile Browser. Opera is even more strict than Webkit when it comes to web standards, is also a fully operable browser and touts some pretty fast speeds too. Also available for Windows devices is Skyfire, which delivers image snapshots of web pages instead of rendering the page on the device itself.

Finally, there is the first generation browser packaged with Windows Mobile: Internet Explorer. It’s clumsy and manipulates pages to fit and render on it. It’s anything but the full-powered browser Safari, Opera and Torch is.

Download the Iris browser at the Torch Mobile website.

See Also:

WebKit Experiments with CSS Variables

WebKit, the code that makes up the guts of browsers such as Apple’s Safari, has gained a much-requested new feature with the addition of variables in cascading stylesheets.

The feature, which won’t be available publicly until the next major release of Safari — and then only if it survives this experiment — is available now with its latest nightly WebKit build.

The enhancement comes after ten years of pleas for the feature by web developers. It would make designing and reading website code much easier by allowing developers to reference commonly-used styles by names chosen by the site’s designer. For example, watch how variables make this little piece of code, used to make the background of the page and tables light gray, a little more readable:

Without variables:


//Sets the background of the page and tables to the hex code for the color gray.

body {

   background-color:#ECEAE1;}

table {

   background-color: #ECEAE1;}

With CSS variables:


//Defines "DefaultBGColor" to light gray

@variables {

  DefaultBGColor: #ECEAE1;}

//Sets the background and any table on the page to the default background color

body {

  background-color: var(DefaultBGColor);}

table {

  background-color: var(DefaultBGColor);}

Current implementations of CSS have some standard variables for properties like alignment or color (“left,” “dark blue” or “red,” for example). However, unless you design your site around those pre-defined colors, you’re stuck having to memorize hex codes and pixel lengths. This is especially challenging for sites with multiple designers referencing the same code. Variables would mirror other coding standards by making these references configurable and recognizable according to site design.

Webkit, the rendering engine that powers Apple’s Safari and Linux’s Konqueror, is the first browser to support CSS variables. Web designers are not likely to take advantage of it until other major browsers, like Microsoft’s Internet Explorer and Mozilla’s Firefox, hop on the bandwagon. Still, it’s a nifty advancement, and something worth noting for the future.

To get started with Cascading Style Sheets (CSS), follow Webmonkey’s tutorial.