Styling for WebKit-based browsers

This article discusses the creation of a base styles sheet for WebKit-based browsers. A companion table lists all rules found in the UA’s styles sheet plus rules from a reset, a base and a fonts‘ styles sheet.

The idea is to leverage "native" rules while implementing the styling of combined styles sheets. For the purpose of this exercise, I am using YUI3 sheets, but the technique is the same regardless of which reset, base or fonts styles sheets you use. Bottom line, you want to avoid overwriting declarations or disabling styles that cater to directionality.

‘before’, ‘after’, ‘end’ and ‘start’

The WebKit styles sheet contains the following:

‘margin’ and ‘padding’ properties:: -webkit-margin-before; -webkit-margin-end; -webkit-margin-after; -webkit-margin-start; -webkit-padding-before; -webkit-padding-end; -webkit-padding-after; -webkit-padding-start
‘text-align’ values:: start; end

The above are writing-mode dependent properties and keywords. In English, start maps to left, and end to right.

The good news

WebKit-based browsers support start and end values (see 4.1 Text alignment:the ‘text-align’ property). Relying on these rather than on left and right allows Safari, Chrome and the likes to swap the direction of the flow according to context (ltr/rtl). Using start/end rather than left/right gives authors the rtl interface for free (check Direction-friendly Navigation Bar ).

The bad news

While Chrome and WebKit supports all the properties and keywords above, Safari only supports start (Mozilla does a bit better as it supports both start and end). All these properties are said to work in Safari 6 though; so when that ships, we will need to replace top, right and bottom values with the prefixed properties to make our styling "direction" agnostic.

In the meantime, when setting opposite values for margin or padding, for example when styling lists as below:

margin-right: 1em;
-webkit-margin-start: 2em;
padding: 0;

make sure to write -webkit-margin-start or -webkit-padding-start after margin-right or padding-right. If you don’t, the latter will overwrite the former and you’ll lose both stylings when the direction changes.

Styling Guidelines

Avoid redundancy

Using a single styles sheet to style HTML elements rather than two or three does not only reduce file size, but redundancy too. As an example of the latter, look at the table that includes all styles sheets and check how pre is styled:

Via the UA Styles Sheet: margin: 1em 0;
Via YUI Reset: margin: 0;; this overwrites top and bottom margins
Via YUI Base: margin-bottom: 1em;; this overwrites the bottom margin

But to achieve the same result we could simply zero out the top margin (margin-top:0) because after all, this is the only style that needs to be overwritten.

On the other hand, I think it is okay to overwrite a couple of styles if it means shaving bytes. For example, if the margin values we are dealing with are 0, 0 , 0, 0 (meaning only top and bottom values must be overwritten), then I’d say it is better to zero out all values rather than targetting only the top and bottom ones. In short, margin:0 beats margin-top:0;margin-bottom:0;.

When not to use the prefixed properties

We go with margin and padding whenever we give the same value to opposite properties (i.e. -webkit-*-start and -webkit-*-end), which means we’d use this:

margin-right:1em;
margin-left:1em;

instead of this:

-webkit-margin-end:1em;
-webkit-margin-start:1em;

The main advantage of this "shortcut" is that it is "Safari-friendly" since this browser does not support -webkit-margin-end yet.

‘padding’ versus ‘margin’

For the base styles sheet, I prefer to style lists as most UAs do – via padding instead of margin. I do this because, unlike margin, padding allows authors to style the space surrounding the content box (i.e. displaying a background image on the side of a list).

Fix

font:inherit on select elements do not work in WebKit/Mac (see test case for bug #57520). To fix this, authors need to style this form control with some other styling. In our case, we add a background:transparent declaration to the base styles sheet.

font-size

Following Jonathan Snook’s excellent article, I am using rem as the unit of measurement.

Things worth noticing in the WebKit styles sheet

The sheet contains values such as "1__qem".

I don’t really have a clue what these mean. The only reference I found about this is a post from Bill Brown on the CSS-Discuss list. It says:

I believe qem stands for "quirky em" and is a proprietary Webkit syntax used to refer to a margin which can be collapsed when the page is in quirks mode.

According to Tab Atkins, it is some "WebKit magic" 🙂

There is no text-align declarations for th and td

Even though there is no such declaration, browsers do center the content of these elements. I believe the style responsible for this is display:table-cell (a declaration common to both th and td).

z-index: 2147483647

This z-index declaration belongs to the::-webkit-validation-bubble rule. It confirms the upper limit value for this property (see 32bit signed integer). In any case, authors may send this element down the stack with a simple z-index:1. 😉

WebKit styles h1 via :-webkit-any(article,aside,nav,section) h1 {...} rules.

I do not do anything about these in the base styles sheet, but be aware that Safari seems to ignore this syntax, so selectors should be kept apart, as the following would fail:


h2,
:-webkit-any(article,aside,nav,section) h1 {...}

Unfamiliar selectors and properties

You may want to explore the UA styles sheet and look for the -webkit- prefix. There is plenty to learn there.

Before you build your own "base" styles sheet

To create our base.css file we have dropped many declarations from the YUI styles sheets, but it does not mean these styles should not be there in the first place. Remember that the base styles sheet discussed in this article targets Safari while the YUI sheets cater to many browsers out there, inlcuding IE6 in quirks mode!

So, first you should find out what rules you’re styling "against", then what "sheets" you want to include (reset, etc.) and only then optimize the styling by reducing redundancy and preserving or implementing styling that is direction-friendly.

It is a real effort to optimize declarations and rules for your target audience, but note that this is something you’d do only once. Even if later you need to edit values, there should be no reason for rules and properties to change.