CSS: writing efficient user style sheets

One of the most neglected and underused features of CSS are user style sheets. This feature allows our visitors to customize the rendering of our documents without worrying too much about the styles already specified by an author. Here are some peculiarities of user style sheets.

  1. Cascade

    CSS styles provided in a user style sheets always win when there are conflicting rules. In other words, when an author specifies a CSS rule and a user tries to override it, then the user will win. I recommend you to always use the !important declaration to make sure that your styles will have the highest priority.

  2. Semantics

    User style sheets work at their best when their target pages are structured properly. For example, to help users with customizing our pages, we can provide different IDs on the various body elements of different pages. This helps a lot, for example by writing a rule like this:

    body#home {
      background: #fff !important;
      color: #000 !important;

    However, the overwhelming majority of web documents are basically tag soup, because they're full of markup errors, deprecated HTML elements and nested tables. But user style sheets can actually deal with this worst-case scenario, like so:

    font {
        color: #000 !important;
        font-size: 1em !important;
        font-family: sans-serif !important;

    Another typical case is when a document contains non-standard elements, like marquee or blink:

    marquee {
        -moz-binding: none !important;
        overflow: hidden !important;
        display: inline !important;
    blink {text-decoration: none !important;}

    Anyway, not all of these elements can be actually prevented from showing their default behavior. This is particularly true in Internet Explorer.

Almost all browsers allow for the use of user style sheets. I think that the later adoption of this kind of feature is mainly due to the fact that most users don't have a basic knowledge of CSS required for this task.

This entry was posted in by Gabriele Romanato. Bookmark the permalink.

6 thoughts on “CSS: writing efficient user style sheets”

  1. Web authors' extensive use of custom classes & ids makes creation of user stylesheets a tedious process. There needs to be a better way. This is the one I needed to create only yesterday:
    @-moz-document domain(forum.azbox.com) {
    {background-color: #FFF !important; color: #000 !important;}
    select.qaction, input.qaction,
    table.table_list tbody.content td.lastpost,
    .table_list tbody.content td.children,
    .topic_table td.subject p, .topic_table td.stats,
    .topic_table td.lastpost,
    {font: small/1.2 sans-serif !important;}
    blockquote blockquote blockquote,
    #helpmain h3.section,
    #searcharea .inputbox,
    {font: medium/1.2 sans-serif !important;}
    #helpmain h2.section
    {font: large/1.2 sans-serif !important;}
    {font: small/1.1 monospace !important;}
    blockquote blockquote blockquote,
    .buttonlist ul li a,
    .buttonlist ul li a:hover,
    .buttonlist ul li a span,
    .buttonlist ul li a:hover span,
    .buttonlist ul li a.active,
    .buttonlist ul li a.active span,
    .buttonlist ul li a.active,
    .buttonlist ul li a.active:hover,
    #content_section div.frame,
    .dropmenu li ul,
    .dropmenu li a.active,
    .dropmenu li a.active span.firstlevel,
    .dropmenu li a.firstlevel:hover,
    .dropmenu li:hover a.firstlevel,
    .dropmenu li a.firstlevel:hover span.firstlevel,
    .dropmenu li:hover a.firstlevel span.firstlevel,
    #footer_section span.smalltext,
    #footer_section div.frame,
    h4.catbg span.left,
    h4.catbg2 span.left,
    h4.titlebg span.left,
    h4.titlebg, h3.titlebg,
    h4.titlebg img.icon,
    h3.catbg span.left,
    h3.catbg2 span.left,
    h3.titlebg span.left,
    #header div.frame,
    span.upperframe span,
    span.lowerframe span,
    .statsbar div.bar,
    .statsbar div.bar div,
    .table_list tbody.header td span.left,
    .table_list tbody.header td.catbg,
    .table_grid thead th,
    .table_grid th.first_th,
    .table_grid th.last_th
    #upshrinkHeaderIC h3.catbg span.left,
    #upshrinkHeaderIC h3.catbg2 span.left,
    #upshrinkHeaderIC h3.catbg,
    #upshrinkHeaderIC h3.catbg2,
    #upshrinkHeaderIC h4.titlebg span.left,
    #upshrinkHeaderIC h4.titlebg,
    tr.catbg td,
    tr.catbg2 td,
    tr.catbg th,
    tr.catbg2 th,
    thead tr.titlebg th,
    tr.titlebg td,
    tr.titlebg2 td,
    .windowbg span.botslice,
    .windowbg2 span.botslice,
    .windowbg span.topslice,
    .windowbg span.topslice span,
    .windowbg span.botslice,
    .windowbg span.botslice span,
    .windowbg2 span.topslice,
    .windowbg2 span.topslice span,
    .windowbg2 span.botslice,
    .windowbg2 span.botslice span,
    .approvebg span.topslice,
    .approvebg span.topslice span,
    .approvebg span.botslice,
    .approvebg span.botslice span,
    .dropmenu li a.active
    {background-image: none !important;}

  2. BTW, if I was planning recurring returns to this site, I'd have to create a similarly tedious user stylesheet for it too:

    1-Gray text at less than 100% of default is simply too painful to tolerate. The readable bookmarklet is OK for occasional use, but no more.
    2-Greater than normal line-height serves no purpose unless lines are excessively long (not too long here) or font-size is smaller than default (very rude here).
    3-This input box is only wide enough for about 6-7 average words, and tall enough for 8 lines, much too small for competent composition.

  3. Another big impediment I forgot to mention is compaction of CSS files. Without newlines, Domi shows every rule in a CSS file as being on one line. The only practical way to deal with such files is to download, sed s/}/}\n/g the downloaded CSS, then jump back and forth among Domi, WebDev or Firebug, the downloaded CSS, & the draft user stylesheet. Maybe someone else can suggest a better way?

  4. Felix, you might have proven how smart you are, but you've done that at the expense of another persons feelings! Gabriele, you are too polite. Me, I would have stuffed it in the bin. But that's Mazda drivers for you.

    The question (as I remember it) was about writing style. As a beginner in the CSS arena, I've read a number of your posts over the last year or so and have found them to be well informed, intelligent and simply constructed, concise and to the point (which is the essence of a good blog).

    If I do have a gripe it would be that there is not enough detail on the subject and I get a feeling that you are preaching to the choir. As a "beginner" CSS coder I often have heated discussions with friends about the advantages and disadvantages of various browsers. I use firefox as my browser of choice as I find it is faster than opera (which has better security) and has a well-integrated dev add-on family. (Their help forums regarding thunderbird are pathetic at best, but that's my personal thing).

    As I can only really speak for firefox, I find that I do not have a clear enough understanding of the user defined function. It merely allows me to tick a single box that allows the authors styles through. I leave the user-defined areas blank and just hope for the best!

    Building websites according to Web Standard specs is most challenging. Maybe you could post another blog giving more detail on this very !important aspect of the web.

    I'm now going off to google the !important function. ;)

    Oh, and the not quite 100% thing is just fine with me.

  5. I don't understand why you would want to overwrite user style sheets. If someone has gone to the trouble of putting one of these together it probably means that it's something they really need.

    For example, if a user has a sensitivity to light, a style that makes them unable to reduce the glare on a page by setting up light text on a dark background instead of the reverse is going to make the page unusable for them.

    this is an approach that will lock people out of a page you want them to visit.

    # body#home {
    # background: #fff !important;
    # color: #000 !important;
    # }

Leave a Reply

Note: Only a member of this blog may post a comment.