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 forth
andtd
- 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 bothth
andtd
). - 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.
Further reading
- Appendix D (the Default style sheet for HTML 4)
- WebKit-based apps
- Detecting WebKit with JavaScript
You might also want to read another article of mine that recently gained popularity because of @smashingmag and @zomigi.