Dion Almaer was faster than me blogging about TouchScroll. Here is what you are waiting for – the “official” blog post about TouchScroll and the link to the repository.

Here it is: TouchScroll, our scrolling layer for WebKit Mobile. It is JavaScript/CSS 3 based and allows for fixed elements like headers and toolbars on web pages when viewed on the iPhone or on Android. It works on the iPad, too. Check out the demo (short URL: http://u.nu/8uvg8) to see it in action – it works in Desktop Safari (at least kind of) or WebKit Nightly (very good), but I recommend you have a look at it on your iPhone, iPad, or Android based device.

Motivation

While Safari Mobile features native scrolling, there are two reasons to re-implement scrolling with JavaScript: The original scrolling behavior is rather slow – we were looking for a solution that feels more fluid. And the viewport behavior of Mobile Safari and other mobile browsers using WebKit doesn’t allow for fixed positioned elements. It is optimized for document reading, not for building interfaces.

Our goal is to be able to deploy application interfaces to browsers of handheld devices that feel as familiar as possible for the user. TouchScroll enables developers to use fixed interface elements like headers and toolbars.

We also use PhoneGap a lot to deploy cross-platform applications onto smartphones, and we think that web based apps don’t need to feel like aliens for users. And we weren’t satisfied with existing solutions.

Usage

To add a scrolling capabilities to an element, that element must have a fixed size. Have a look at the demo for an elegant approach using display: -webkit-box.

HTML:

JavaScript:

At the moment, the only known option is elastic. Use {elastic: true} as second parameter to add the bouncing effect to the scroller.

Get it!

TouchScroll is available on github. Feel free to fork it and send patches back. You can also get a minimized file that includes the css-bezier library that TouchScroll depends on.

How is it done?

TouchScroll uses a combination of JavaScript and CSS 3. All animations are done with CSS transitions – no JavaScript intervals.

The elasticity effect when crossing the scroller bounds is achieved by dividing the bezier curve (used as timing function) into two sub-curves using my (yet to be finished) CSS Bezier library for JavaScript.

Customization/Configuration

TouchScroll allows you to customize many aspects of the scrolling behaviour: Have a look at the config object at the top of the source file.

Customizable properties include bouncing behaviour and deceleration animation. Feel free to experiment. I know that scrolling is not as close to <insert device of choice> as possible. If you think you’ve found better values, just let me know.

Configurable properties include:

• Scrolling threshold: The minimum pixel amount needed to begin scrolling
• Flicking behavior: flicking threshold, friction, and deceleration animation.
• The elasticity/bouncing effect: factor and maximum bounce length.
• Snap back behavior: timing function and default duration.

Goodies

After instanciation, each TouchScroll scroller re-adapts to its contents after orientationchange and resize events on window as well as after DOMSubtreeModified events on the scroller itself. That means, the scroller adapts to content additions and deletions.

Limitations

TouchScroll is meant to be used with touch-based devices and also works well with a stylus (tested with a Wacom tablet). Don’t use it for desktop browsers and the like. Simply add overflow: auto to the scroller element for these cases. Zero-cost compatibility.

Hiding and Showing

If a scroller is instanciated with an layer that is not beeing displayed, it needs to be refreshed manually after making it visible. Simply use the setupScroller method.

Styling

TouchScroll inserts two more <div> elements to the outer scroller container, that wrao the prior contents. That means, that the outer scroller element must not have padding. The CSS child selector (a > b) won’t work any more after instancing TouchScroll on an element for the same reason.

Android

Android has several problems that need to be solved. If you have solutions, please keep in mind that TouchScroll should remain compatible with WebKit as found on Android 1.5 and send us a patch.

• When not preventing the default action of the initial touchstart event on Android, the following touchmove events queue up and fire just before the eventual touchend event. That makes scrolling impossible.Cancelling the touchstart event results in other problems: It prevents tapped elements from beeing focused or clicked. The current workaround – dispatching a synthesized click event – hides the focus rectangle and makes the focussing of form elements nearly impossible, which is even worse.That means: at the moment it is not possible to use TouchScroll in conjunction with forms on Android.I’d like to know whether there is a solution that eliminates the need to prevent the default action of touchstart.
• Due to the lack of hardware acceleration, the rendering performance on Android isn’t nearly as good as on the Apple’s devices. We already invested a lot of work to achieve good performance. If you can do better, send us a patch!
• Support for -webkit-transform: matrix(…) is broken in Android < v2.0. That affects reading the computed style of elements. We already worked around that issue using a regex-based parsing function for those devices.

Other Devices

The browser of S60 devices is based on WebKit, too. However, apart from the fact that TouchScroll does not work on those devices, you should simply set the overflow style of the scroll container to overflow: auto for these devices and benefit from native scrolling. The same goes for Nokia WRT apps.

I’ve done a quick test on the Palm Pre. Unfortunately, TouchScroll does not work in the browser of webOS. Moreover, I’m not sure whether it actually makes sense in this particular browser, as its overlays would lie directly on top of fixed elements at the bottom. In webOS apps you should probably use the native scroller anyway. Maybe I’ll do a short tutorial on how to instanciate TouchScroll on iPhone/Android and the webOS scroller when deploying a cross platform app to all of those devices.

What other devices are relevant? Let us know!

To Do

The official to-do-list:

• Keep the scrollbars round while bouncing – I already know how to do this, so you can expect the solution in the next days.
• Add an option to completely switch off scrollbars.
• Find a solution to the event problems on Android – help greatly appreciated!

On mobile devices it is important to keep things simple, for instance to keep the number of DOM nodes low. That rules out using additional elements for the corners. On the other hand, many mobile devices are featuring recent versions of web rendering engines. Dive into CSS 3.

Modern web development techniques offer a lot of possibilities to render boxes with rounded corners: e.g. border-radius, border-image, or SVG used as background. In this post I’m going to explore the support for them across different devices and runtime environments. You can skip to the results table if all you want is a quick overview.

As stated above, I want to achieve a box with rounded corners and a gradient that reaches from top to bottom, scaling to the height of the box. The example might be simple, but it is representing a common design goal.

State of affairs

As of today, several possibilities exist to develop applications for mobile devices using web technologies. Besides Palms webOS, PhoneGap permits to develop cross-platform applications with JavaScript, HTML, and CSS for the iPhone, Android, Blackberry, Windows Mobile, and Nokia WRT (support for webOS is upcoming). On Nokia devices there are two frameworks to create applications with web technologies: the built-in Nokia Web Runtime Widgets (Nokia WRT) and Opera-based Vodafone Apps Manager, which provides a runtime for W3C Widgets (heads up! Vodafone Apps Manager is WebKit-based on the Vodafone 360 H1/M1 devices, to complicate development a little bit).

While these runtimes provide the means to build applications using well-known technology to web developers, they also bring well-known problems to the mobile sphere: inconsistencies between rendering engines. Even though most of those runtimes are WebKit-based (with the exception of Vodafone Apps Manager), there is no [single] Webkit on Mobile, as PPK has pointed out. His comparison table shows the results of testing for various JavaScript and CSS features.

Freed from the burden of “making things work in IE” we can start using advanced CSS features to build interfaces for mobile applications – but hold on, it’s not as easy as desired. Due to the differences in capabilities of rendering engines and their versions, using CSS 3 features needs a lot of testing.

Test Setup

To keep things simple in the beginning, I’ve tested on two devices: a Nokia 5800 XpressMusic and a Nokia N97 (it might have played a role that I had those two at hand when writing the article ;-)

Both devices support Nokia WRT apps natively and W3C Widgets via Vodafone Apps Manager. The HTML file consists of boxes with different set of CSS properties. I’ve uploaded the packaged Nokia WRT Widget and the W3C Widget, too. You can test them for yourself on your Nokia, if you like.

On the 5800, Nokia WRT is based on WebKit build 413 (which correlates roughly to Safari 2.0), the installed Vodafone Apps Manager uses Opera Mobile build 1265. The N97 uses Webkit build 525 (introduced with Safari 3) and Opera Mobile build 1360.

Because the two devices show no differences in rendering (with one exception), all screenshots have been taken on the N97 with the exception of one rendering bug found on the 5800. All other rendering differences are existing between runtimes only.

Test Results

Result table

The result table provides a quick overview about the tested features and platforms. Detailed descriptions of the single tests can be found below.

* background overlaps border, blurry border on the N97, circular artifacts on the 5800
** SVG backgrounds stop being rendered after the corresponding element is scrolled out of the viewport

Cases 1/2: Simple Box

Boxes 1 and 2 on Nokia WRT/Vodafone Apps Manager

Case 1 simply uses a border and a background-image:

This renders equally well on both platforms, but is not very similar to what I want to achieve: The background gradient is barely visible, because the image used is fairly high and does not scale with the height of the box.

Case 2 is a little bonus, as it does not relate to box styling: it tests for support of CSS transitions. By clicking the box, the class “clicked” is added or removed. In rendering engines supporting CSS transition the width of the box will be changed smoothly. Neither Nokia WRT nor Vodafone Apps Manager support them, though.

Cases 3/4: border-radius and border-image

Boxes 3 and 4 on Nokia WRT/Vodafone Apps Manager,border-radius on the Nokia 5800 XpressMusic

The third test adds border-radius to the CSS declaration. This comes closer to the styling goal, but is not usable on both platforms: While it’s not rendered at all in the Opera-based Vodafone Apps Manager, the older WebKit engines of the 5800’s Nokia WRT adds circular artifacts to the corner, and the background overlaps the border on the N97. In addition, the border drawing is blurry on the N97 as soon as border-radius is added to the declarations.

Case 4 uses the same background image, but as border-image. Again, Opera doesn’t support the property, but the WebKit-based Nokia WRT displays the box as intended: Sharp border, rounded corners, gradient from top to bottom. (Note: in contrast to the label on the box, the background property is set to white in this example).

Interestingly, the WRT application crashes, when the combined offset/border-width syntax (e.g. -webkit-border-image: url(box.png) 15/15px stretch).

Cases 5/6: Gradients and SVG

Boxes 5 and 6 on Nokia WRT/Vodafone Apps Manager

The fifth box uses a different approach for styling the box: It uses a browser-rendered gradient (<a href="http://webkit.org/blog/175/introducing-css-gradients/">-webkit-gradient</a>) for the background:

Support for gradients in WebKit was introduced in april 2008, but is not supported on the Nokias. As expected, it doesn’t work in opera, either.

Case 6 uses a SVG as background-image which always scales to the available width and height. This technique has been described more than two years ago for Opera, and works well in Opera based environments. Even though this example doesn’t make use of CSS 3 , only Opera seems to be able to use SVG graphics as background images as of today. This holds true for browsers with built-in SVG rendering capabilities, too.

Cases 7/8/9: Cross-Platform Solution and Advanced Features

Boxes 7 and 8 on Nokia WRT/Vodafone Apps Manager

Examples 7 and 8 represent the attempt to combine the approaches from boxes #4 and #6: They use an SVG background-image and a pixel graphic as border-image:

Because both WebKit and Presto (Opera’s rendering engine) only support one of the approaches, the box renders fine in both engines (also, border images always lay on top background images).

This would be a perfect cross-platform solution, if Vodafone Apps Manager wouldn’t show a nasty bug: The first time boxes with an SVG background are scrolled into the viewport, they are rendered properly. As soon as all boxes using the same SVG are scrolled out of the viewport, and then scrolled in again, the SVG won’t display any longer. I’ve added a video showing this behavior.

Case 8 just adds opacity to the boxes, which is only supported in Opera, but slows down scrolling noticeable. Case 9 tests for support of box-shadow, which is not supported by any of the runtimes used in this test.

Conclusion

In our small test, we actually found a solution that runs in both WebKit and Presto. Sadly, this solution is only viable if the box isn’t ever scrolled out of the viewport. The rendering problems affecting the solution can only be found in mobile versions of the rendering engines tested.

That means, support of a certain feature in the desktop version of a browser does not imply bug-free support in mobile versions. Drawing can be fuzzy or faulty. Examples are border-radius in older Nokia WRT releases or the SVG rendering bug in Vodafone Apps Manager.

Despite the fact we don’t have to deal with “legacy rendering engines” on mobile devices, it is not possible to rely on modern features like SVG graphics or CSS 3 yet. Due to many forks of WebKit, and Operas restraint in implementing CSS 3 features, each usage of such features should be thoroughly tested across all different target platforms. Write code your device can handle, don’t try to bend the browser.

Another problem are slow rendering speeds on mobile devices. It might be impossible  to use certain features, just because animations and scrolling get choppy, thus killing the snappiness of the user interface.

The Future

The newest version of Operas rendering engine, Presto 2.4 is already in beta state for mobile devices with Opera Mobile 10 (while the newest desktop version still uses Presto 2.2), and adds support for many CSS 3 features like border-radius, border-image, background-size, and CSS transitions. This will enable us to use all of the techniques that have been shown for WebKit in this post (border images, border radius, and box shadow). Using a combination of background-image, background-size, and border-image could provide a solution that degrades gracefully on older devices.

Also, CPU and rendering power of mobile devices will increase in the next years, providing faster rendering of HTML/CSS with smooth animations.

Thanks to the fact that developers don’t have to account for the market leader, the mobile browser/rendering engine market evolves way faster than the desktop browser market does. I am excited about the possibilities we have today and looking forward to the possibilities we’re going to have after the next releases of browsers an built-in rendering engines.

To Do

The plan is to make the tests more complete. One the one hand that means adding tests (e.g. the current test series lacks a test for -webkit-/-o-background-size, which would allow to scale the background image with the size of the box). Another interesting topic is support for CSS transitions.

On the other hand I would like to deploy the tests on as many platforms as possible. The next steps could cover packaging for platforms supported through PhoneGap and webOS.

If you would like to see a certain feature tested, I would appreciate a comment very much. Follow me on Twitter (void_0) to be kept up-to-date about my random findings in the mobile web dev sphere.

Taking this as an opportunity we want to announce the next dojo.beer() in Barcelona on June 17th.
You can get all info about the event on the DojoCampus event site.

The day after, we are speaking at the Mobile2.0 developer day and will give a detailed introduction in how to write mobile applications using the Dojo Toolkit and making sure they are running on different platforms such as PhoneGap and the W3C widgets being supported by Vodafone.

If you are in Barcelona that week, feel free to get in touch and if you have time to join for drinks during the dojo.beer or the mobile 2.0 conference let us know. Please sign up using the poll below.

Para los españoles :-)

Como Wolfram ha escrito en su último artículo de blog, nosotros estamos muy involucrados en el mundo de los móviles y estamos especialmente investigando como desarollar de la mejor manera para dispositivos móviles con Dojo.

Aprovechamos esta oportunidad para anunciar el próximo dojo.beer() en Barcelona el 17 de junio de 2009.
Puedes encontrar toda la información en inglés sobre el evento en la página de eventos de DojoCampus.

Al día siguiente vamos a dar una ponencia en el Mobile2.0 developer day y vamos a explicar como escribir aplicaciones moviles usando el Dojo Toolit y como asegurarse de que funcionan en múltiples plataformas como PhoneGap y como W3C Widget apoyado por Vodafone entre otros.

Si estás en Barcelona durante esa semana y te apetece contactar con nosotros no dudes en venir a tomar una copa al dojo.beer o a la conferencia mobile2.0. Por favor participa en el poll abajo si quieres ir.

Fast forwarding … what came out of it is the API docs viewer which, we here at uxebu, built over the christmas holidays. It is completely client-based, for creating the documentation and retreiving all the information, no server-side code is needed anymore, it’s all done in dojo.

If you want to see a detailed introductional video, sit back, relax and enjoy the following screencast:

Inline doc styles

There are a couple of JavaScript inline documentation tools and styles out there, but no real standard has evolved yet. Maybe because of JavaScript’s dynamic nature it’s hard to fix it to just one style. Though this just makes the task more interesting, actually.

Let’s take a step back and take a look at just three of the various different inline doc styles.

The jQuery way, pretty much textual.

The YUI way, as you will see it’s very JavaDoc like, the method is documented above the actual definition and uses the @ sign for identifiers.

The dojo way, with proprietary identifiers, inside the function code!

We see that there are different levels of depth and explicitness in the inline comments. But they all have in common, that important and interesting information are contained inside the source code, that should be exposed to the users of those APIs.

The __doc__ approach

In python, a certain type of comments is available as the docstring property __doc__ of the function it is in. This was actually the initial idea, to provide the docs in this kind of way:

It’s is pretty obvious, that this is is pretty ugly source code in the first place and secondly a comment is not a comment anymore but becomes source code. Prone to errors, and not really leading to higher productivity, we realized that this approach was actually just a learning stage.
Still it is pretty handy to use the command line in FireBug and have the docs at hand via autocompletion e.g. just typing dojo.trim.__doc__ and the docs are there (this feature is currently also implemented, but the __doc__ property must be generated by a function call afterwards and it is not in the main focus for the current state of the project).

The less disruptive approach

Since the __doc__ approach has the ugly side effect that library authors would have to change all their source code it was dismissed pretty quickly. New ways had to be explored. Driven by the flexibility of JavaScript and it’s dynamic nature we found a nice mix of reflection and minimal file parsing that allows us to extract the information from the existing raw (unpacked and not minified!) source code, without the need to modify it upfront.

First comes the reflection. Using the simple for-in loop over the prototype and the object itself allows us to extract all the methods and properties. Applying a little bit of logic using toString() and alikes and we know if the implementation of this object overrides, inherites or creates this method, we find out the default value of properties and a lot more. In the special case of dojo we can also easily find out the parent class(es). The reflection is actually worth a separate article, since it is quite powerful and allows deep insights into a class’s inner values.

Second step is simple file parsing. Since we know that object “foo” has the method “bar”, we know that in the source code we can find the definition by looking for the following patterns:

There are a couple of special but rare other cases, but the patterns are very simple to detect as you can see. So our FileParser doesn’t really need to understand the JavaScript syntax, it is just looking for exact patterns and is therefore quite fast (we can surely still improve on the performance!).
Using regular expressions we also find out the parameters and the actual docstring itself, which then is parsed by the DocStringParser.

Let’s summarize. We have an object’s/class’s (if you want to call it a class) methods, properties, their according docstring and the docstrings of the class itself. We know the inheritance structure, can determine the type (public, private, etc.) from the name (for now we assume it is private when it starts with an “_”) or soon we will use the docstring identifier “tags” (which was just shortly introduced into dojo as you can see it used here). And we have example code, which is contained in a lot of docstrings. So this is already quite an amount of useful data. Let’s make them useable.

Plugging it all together

The pieces are there, they just need to be plugged together and hopefully a useful API docs viewer will arise. For this special dojo use case, we also had to build a mapper which enables the mapping of a namespace to the correct file(s). E.g. dojo.query() is actually a function inside the dojo object, which would naturally mean it is inside dojo.js, but in this case this method is in a separate file query.js which is “the knowledge” of the mapper.

Building the namespace tree was another challenge, loading all the files in the browser and inspecting the entire namespace via JavaScript would just be an aweful waste of resources. So currently there is a small python script which generates the JSON files which contain the contents of the tree to the left. But the high flexibility of using dynamic extending of objects (like e.g. NodeList-fx does) mixins and other things make it hard to rely purely on the generated contents of the tree, so they are partly hand-crafted too.

The UI is purely dojo, showing off some of the neat features, like the slick ExpandoPane. In my eyes it looks very nice, with a lot of attention to the detail. The UI was actually the part that needed the least time to build, thanks to Nikolai’s deep knowledge it was a piece of cake. There are of course a couple of glitches like the wrapping of the tabs, but hopefully this is just another kick in the right direction to speed up those kind of fixes. Because what is there is already much more than just the base of a GUI toolkit with some widgets, it is a full-fledged-ready-to-go-batteries-included-kick-ass set of UI components. (Ok, enough wallowing, yes I am biased :-).) So look for yourself and let us know what you think.

The future

As you know it too, working on those kind of projects always spins off a lot of new ideas. So we want to share some with you and maybe even get some help on some of them. First: we will put the source code out on google code (or alike) and it will be open for contributions, of course. We just need to do some renaming to ensure future-proof enhancements won’t just clobber this thing and make it unmaintainable.

Another idea is to configure the API docs viewer for custom namespaces and as long as the inline comments are dojo style it should be just a snap of a finger to get your own project’s API docs out. Well, actually the snap of a finger is the creation of the above mentioned JSON file, which contains the tree structure. But one day we will also have an auto-detector which builds the tree initially out of traversing through a given existing namespace (given that it is entirely loaded).

Idea No. 734 :-) was to provide the API viewer for other libraries too. The architecture is made this way, that the reflection and file parsing are separated and could be extended to work with another inline doc style syntax (we made first experiments with it). In order to do this right we think about having a common interface where to put and get the apidoc data from. A json-schema for API doc data is required. I have started on one, but this task really is huge when done right.

Of course the __doc__ property will be provided. Currently when working with libraries or function that I don’t know I mostly use toString() on it and learn from the source code. I could also very well imagine myself using __doc__ if it was there. So keep looking for that, I think it can change the way one uses the FireBug console and learns about libraries.

Since we know all the objects, methods on the one hand and the according docs on the other hand we can tell how good the doc coverage is. This heads into the direction of continuous integration and imho that is really where JavaScript still has a long way to go.

And there are a couple more ideas, like running the inline doctests in the UI, integrating the API viewer with Bespin and allowing to throw the api viewer onto any page using a bookmarklet, which would nicely let you browse the JavaScript API of any site, no matter if you want to learn, fix something or whatever. To mention just some of the ideas …

Now if you want to get your hands dirty and play with the code, see how it can integrate with your own code or just have offline dojo api documentation, drop us an email ( labs (a t) uxebu.com ) and we will make sure a copy of the code lands in your mailbox. Also, if you find bugs, have ideas, want to contribute, contact us and we will exchange ideas to make this tool the best available javascript api viewer out there.

In this article I will show how you can use CSS variables to optimize CSS. In the second part of this series you will learn how to use CSS variables efficiently in themeing applications (using the Dijit themes of the Dojo toolkit) and in the last part we will take a look how we can deal with all the new technology and convert it into a cross-browser solution with the help of a little bit of server-side magic.

How do CSS variables work?

Using CSS variables is pretty simple, lets dive right in and look at an example:

Thats all there is to it (I admit there are a few more things but I leave those to you to find out – for now. The next blog post will cover it in more detail).

Optimizing CSS

When writing themes for toolkits, creating new visual identities, or designing complex websites you will notice that you will use the same CSS values over and over again.
CSS already provides you with a lot of granularity, you are able to separate content from visual appearance, but there are still many cases where you will find yourself repeating things over and over again.

Usually front-end developers tend to move in two directions:

1. Describing the visual appearance of a an element by trying to be as descriptive in regards to that element as possible:

The respective shopping element would then look as follows:

2. Describing an elements visual appearance by using several classes which can be used in a wider context and are combined to create a “visual event”:

The respective element would then use the classes as follows:

You already will have noticed that just taking one of the two roads will result in suboptimal CSS in regards to code beauty-ness, maintainability and performance.
Using the first route you will find yourself using the same “background: #fefefe;” all over again and taking the second road you will find yourself trying to create as much granularity as possible losing the larger overview.

Most front-end developers usually take the middle path, a mixture of both those techniques and this is good. Though many times – and especially in the cases of large cooperate themes, websites and toolkits – it is not optimal.

Are CSS variables a solution?

Lets just take a look at following implementation of above usecase, using CSS variables.

First we will create a dictionary with the visual identity (dictionary.css), containing all CSS variable definitions:

Now we will implement those variables in the master CSS file (layout.css):

The respective element would still look like following:

The benefit of this approach will clearly get visible when you are starting to deal with more than 10 classes. Envision a project with hundreds of classes, many of them describing similar things but not the same.

So what are the benefits?

1. Clearly structured CSS
   You might argue that your CSS will be less readable because you don’t see the actual value of the css property you are looking at. This is a valid concern, but we have to realize that the benefit completely outweighs that issue (if seeing the visual effect of a class in the browser is not enough, there are great debugging tools which give you all the info you need). The fact that a developer can tell you with one look that the background color of one and all active panes is “#133213″ (paneBackgroundActive: #133213;) – that is all Tab panes, Accordion panes, etc. etc. – will improve development cycles incredibly
2. Maintainability
   The visual definition is stored in one (maybe a few more) files. A front-end developer will not have to deal with a whole bunch of un-overseeable files but can focus on pure visual definitions. Changing a visual identity is a matter of adjusting one dictionary and not hundreds of CSS files.
3. Documentation
   One factor which unfortunately has not yet been covered by too many people is CSS documentation. This is as important as any other documentation – especially if you are developing large scale apps. Having dictionary files with visual definitions will enable you to write clear documentation.

The exact specification of how to document CSS best is a different discussion, there are already projects existing which are trying to push into that direction.

Why is this good if no browser supports it?

Since at the moment of writing only Webkit nightly is supporting CSS variables you might wonder why this whole thing should bother you at all.

The first step we should take is trying to abstract and generalize even more when we write CSS – not in the way as I described in the two examples at the beginning of this post but in the “CSS variable way” I described in the above example.
Once we understand this we can decide whether it is worth shifting our development process to using CSS variables (this is not an easy decision, there is no (non-nightly) browser out there supporting it).

Until CSS variables are widely supported by browsers you could write a simple parser which would do the search and replace for you on the server, you would actually be serving plain old CSS files.

We will look into those possibilities in the next article using tools which allow you to preview a visual identity in real time, using the Dijit widgets and converting the CSS variable dictionary into plain CSS files on the server in the last article.