New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 112 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Mar 2010
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

  • Only users with Commit permission may comment.

Sign in to add a comment

Issue 2393: Support user stylesheet

Reported by, Sep 17 2008 Project Member

Issue description

Firefox has options for ignoring the page font and color specification. 
It also has a user stylesheet (there's no UI for that, but a user can edit 
it). Opera UI gives even greater controls to users. 

This is also an A11Y feature ( 

This has two components, webkit changes and UI changes.  I'll add eseidel 
once he's added to the member list.

Comment 1 by, Sep 17 2008

Comment 2 by, Sep 17 2008

The webkit changes should be tracked as webkit bugs in  WebKit already supports 
having a user-specified stylesheet applied to all pages.

Comment 3 by, Sep 17 2008

Comment 4 by, Sep 17 2008

After a brief discussion:

We won't add a UI for this. However, we could support something like userContent.css 
that Firefox does. If present, we could load that and then obviously the style rules 
in that file have the ability to override whatever wherever. If you want to add 
support for this please go ahead (I see the bug is assigned to you).

Comment 5 by, Sep 18 2008

macdome, thanks for the info. If webkit already supports a user stylesheet, we may
get it almost free after a merge.

Ben, thank you for the direction.  
Let's see how it goes after merge. Btw, it appears that if I report a bug and am a
member, it's automatically assigned to me (unless I unassign myself explicitly) :-)

Comment 6 by, Sep 18 2008

It already supports user style sheets since *long* before the merge. :)

Comment 7 by, Sep 18 2008

Summary: Support user stylesheet
Ok. I begin to feel stupid. Safari has a UI for that (Advanced - Other ... - 

In Chrome, we don't, yet, support user stylesheet because of a sandboxing issue.

ble.txt and look for 'user stylesheet'. 

Or, see 
(createWithContentsOfFile )

Comment 8 by, Sep 30 2008

Labels: -area-unknown Area-Misc

Comment 9 by, Oct 10 2008

 issue 3309  was duped to this.

Comment 10 by, Oct 22 2008

Labels: -Area-Misc Area-WebKit Mstone-X
Status: Available

Comment 11 by, May 10 2009

Will this be fixed in the foreseeable future or left to the extension apis?
BTW: I think this would also fix  issue 9149  ?!

Comment 12 by, Aug 12 2009

Just wondering about the possibility of user stylesheets--any new word?

Comment 13 by, Aug 12 2009

I am hacking on a simple extension to provide some simple functionality towards this.
Currently have a very early prototype only being tested by some of our low vision
employees. Will hopefully have something to show soon to a broader audience.

Comment 14 by, Nov 9 2009

@klink ,  Since several months has passed,I just want to know whether
your extension for this is publicly available now.Where can I find it?

Comment 15 by, Nov 9 2009

I would much welcome this, as well. I've been running Chromium for a couple of weeks 
now and it's snappy and webpages are sandboxed and everything, but text rendering is 
just horrible for my eyes.

I'm not particularly comfortable with the various tiny fonts and the hippy typefaces 
that web pages use these days so I've been living with my own user stylesheet for 
years. Lack of that capability is holding me back to Firefox for any serious 
reading/browsing for now; if I had that, I wouldn't look back.

Comment 16 by, Nov 15 2009

Labels: Accessibility

Comment 17 Deleted

Comment 18 by, Dec 9 2009

I would have to agree with this. User defined CSS is very much needed and is holding me 
back to Firefox too. It would be nice to have the equivalent of userContent.css but 
also userChrome.css to tweak the font used in the UI.

Comment 19 by, Dec 9 2009

As I initially noted in the Chromium Google Groups, the ability to force a particular
font for displaying pages is not so much about me liking it but rather an
accessibility issue because my sight is damaged and my eyes start hurting pretty
fast, I get a headache when I have to switch between different fonts and then I'm
just forced to switch to Firefox to be able to work. Anyway, I just wanted to express
my support for having some way of forcing a font regardless of whether it's achived
in the UI as in Firefox and its "Allow pages to choose their own fonts, instead of my
selection above" checkbox or it's some generic, under-the-hood custom CSS styling.

Comment 20 by, Dec 13 2009

The lack of this accessibility feature is also holding me back from using Chrome 
instead of Firefox. It seems like most other major browsers (IE, Firefox, Safari) have 
an option to force fonts.

Comment 22 by, Dec 14 2009

That one seems to do quite a bit more than this request. There is also

which I like, and I wrote

but haven't published it in the official gallery (and might not ever) because it's 
decidedly less user-friendly.

Comment 23 by, Dec 25 2009

I've been unable to get the functionality specified in the original request using the extension linked above, so it would 
seem that the request is still valid - notwithstanding the debate over whether or not this should be built-in browser 

Comment 24 by Deleted ...@, Dec 29 2009

Although the "Personalized Web" extension can accomplish this, Chrome really needs a simple style sheet or 'force fonts' option. Otherwise, most people will stick with power and flexibility that 
Firefox customizations provide. I actually like Chrome-Linux better despite its rough edges, but the little things go a LONG way in making a better browser. It doesn't take much. Without font choice, 
the web is unreadable, as are search results! Along with assigning "1" and "2" to tab navigation, this is a no-brainer.

Comment 25 by, Jan 1 2010

Ok, for the sake of... argument? I'm not really arguing with anyone, but: I have hacked 
this quick little thing up to demonstrate the simplest possible way to do a singular 
user stylesheet with an extension:

Given that this is possible to write, I don't see any overwhelming reason to make user 
stylesheets a built-in feature. (And it might actually be useful for a few people 
following this thread, I hope?)

What *would* be nice is a way to get something like @-moz-document in stylesheets (I've 
taken a look at WebKit's CSS parser and there's nothing that could trivially be turned 
into an equivalent), so that one textbox would be all I'd need. The other extension of 
mine above is basically some ugly contortions to get around this.

Comment 26 by, Jan 1 2010

The CSS standard requires support for user stylesheets, so that's probably a good 
enough reason to have it as a core browser feature (given that someone spends the time 
to implement it) unless there are strong arguments to the contrary.

"UAs must allow users to specify a file that contains the user style sheet. UAs that 
run on devices without any means of writing or specifying files are exempted from this 

Comment 27 by, Jan 1 2010

Extensions can NOT achieve what a user stylesheet can do. The reason is pretty
simple: the CSS standard define levels of priority for resolving which rules apply to
an element (

Having a user stylesheet allows to override ALL definition with the use of
'!important'. This is particularly important if one wants to change font-size of
font-family, and for all other concerns regarding accessibility.

The injection of CSS rules directly in the page, even if done correctly (ie also in
iframes) does not provide a simple way to have an 'overriding' rule that works all
the time. If it just happens that the CSS of the site as a more precise selector for
an element, their choice will override yours.
Maybe it could be done in an other way as an extension and respect priorities, in
which case this would be an acceptable solution.

Comment 28 by, Jan 1 2010

Sounds like a good reason to me.

(just out of curiosity, does Firefox even implement it that way? I've just been 
liberally applying !important since that's the same thing I assumed I had to do 

Comment 29 by, Jan 1 2010

I don't really know about the internals of Firefox :/

However, I know that the stylish extension on Firefox works in such a way that the styles defined in the 
extension are considered 'user styles' and as such can obtain the highest priority with the use of '!important'. I 
used to have a file 'userChrome.css' and now use stylish instead (easier to manage).

I hope for something similar for Chrome :)

Comment 30 by, Jan 4 2010

One way to do this right would be to add plumbing allowing extensions to inject user 

Comment 31 by, Jan 4 2010

Allowing extensions to inject user *scripts* doesn't get it right because they'd
still be injected as author sheets rather than user sheets.

Providing plumbing for extensions to inject user *styles* would get it right, but
you'd probably also want to support something similar to Firefox's -moz-doc rules
(, because most people
likely want to create site-specific styles.

Comment 32 by, Jan 6 2010


But extensions CAN inject user style sheets.

Comment 33 by, Jan 6 2010

"Can" as in currently can, or "can" as in potentially can? If the former, can you
give an example or link to some documentation?

Comment 34 by, Jan 6 2010

You can create content scripts where the only "script" injected into the page is a CSS 
file. When pages matching the content script are loaded, the CSS will be injected into 
the page, as specified in the documentation.

Comment 35 by, Jan 6 2010

The term "user style sheet" has a specific meaning and behaviour in CSS. User style
sheets are applied at a different order in the cascade than author style sheets.
Creating style sheets in the way you describe would lead Chrome to regard the sheet
as an author style sheet. This is what comment 27 is talking about.

Comment 36 by, Jan 7 2010

Hear what ciryus432 and jason.barnabe say.

You can't hack user stylesheets together as they don't live in the content domain of 
the document. The support must come natively from the browser so that they can 
reliably override rules in content stylesheet; hence this bug.

However, Firefox, IE, and Safari and other browsers do support them. Further, 
apparently WebKit already has support for them. How much more work would it be, on 
top of merely enabling them as configurable?

Comment 37 by, Jan 7 2010

>> apparently WebKit already has support for them

Yes, WebKitGTK for example has the feature and browsers like Epiphany expose it to the 
user as "[x] Use custom stylesheet   [Edit]"

Comment 38 by, Jan 10 2010

Does anybody know why is it hard to provide a simple configuration preference to force my fonts? Since I don't understand the jargon here, I would like to know why this basic feature is ignored for such a long time.

If someone has a step by step howto, I would love to have get a hold of that.

Comment 39 by, Jan 10 2010

Webkit supports user style sheets, but it's disabled in Chrome because we need to add 
some extra plumbing for it to work with the sandbox (since the renderer process can't 
read from disk, we need to pass the user style sheet via IPC).

Comment 40 by, Jan 18 2010

There are some extensions that allow you to import your own CSS. They are 
hacked together and sometimes add extra loading time to a page. I will be glad to 
see userstyles get some real support in Chrome/Chromium. Maybe then we can 
get a real extension like Firefox's "Stylish" for Chrome.

Still... kudos for disabling it until you make it work with the sandbox.

Comment 41 by, Feb 19 2010

Labels: Feature-Accessibility

Comment 42 by, Feb 24 2010

Status: Started
UI-less version in the works.

Comment 43 by, Mar 8 2010

The following revision refers to this bug: 

r40882 | | 2010-03-07 21:18:06 -0800 (Sun, 07 Mar 2010) | 17 lines
Changed paths:

First cut at custom user style sheets.

Enabled with the --enable-user-stylesheet flag which
causes chrome to read
<user-data-dir>/<profile>/User StyleSheet/Custom.css
at startup and set it as the user style sheet.

This version never reloads the user style sheet, I'll
have to bring back FileWatcher for that.  I also put the user
stylesheet in a subdir because the implementation of
FileWatcher will watch the parent dir (this is what the OS
apis give me) and watching the profile dir will cause
lots of activity.

BUG= 2393 

Review URL:

Comment 44 by, Mar 15 2010

The following revision refers to this bug: 

r41561 | | 2010-03-14 20:39:50 -0700 (Sun, 14 Mar 2010) | 7 lines
Changed paths:

Connect UserStyleSheetWatcher to FileWatcher to have changes to
Default/User StyleSheets/Custom.css instantly change layout in
all your tabs.

BUG= 2393 

Review URL:

Comment 45 by, Mar 15 2010

Status: Fixed
User style sheets should work with --enable-user-stylesheet if you're using a ToT 
build.  There's no UI (as mentioned in comment 4).  We haven't pushed a version to the 
dev channel with this feature yet.

I also filed  issue 38182  for getting rid of the command line flag and  issue 38183  for 
being able to access this from an extension.

Comment 46 by, Mar 15 2010

Thanks, this is great! I'll be happy to test this; how long will it take until it gets 
out to the dev channel?

Comment 47 by, Mar 19 2010

Yes, any approximation when it'll hit the Dev or even Beta channel?

Comment 48 by, Mar 20 2010

This is in 5.0.356.X that was just released on the dev channel.

Comment 49 by, Mar 20 2010

This is fantastic Tony!

Just to point out a typo between Comment 43 and 44, the directory name to use is:
  Default/User StyleSheets/Custom.css

ie, "User StyleSheets" with an "s" at the end.

But I notice if you start with --enable-user-stylesheet, it automatically creates the 
directory anyway.

This is working great with my testing in Chrome	5.0.356.2 (Official Build 42060) dev

Comment 50 by, Mar 28 2010

Great! thx for this patch. This thing is only reason for using firefox instead of chrome.

But I dont know how can I enable option "Allow pages to choose their own fonts,
instead of my selections above" like in firefox?

I don't know about much about css. But I'm used to terminal, vim and sort of that.
Plz give some hint : )

Thanks for this effort again.

Comment 51 by, Apr 5 2010

Here is my Custom.css for,
"Allow pages to choose their own fonts, instead of my selections above"

* {
    font-family: serif !important;  /* for proportional font

/for monospaced font
pre, pre * {
    font-family: monospace !important ;

code, code * {
    font-family: monospace !important ;

tt, tt * {
    font-family: monospace !important ;

Its not perfect. Any hints are welcome : )

Comment 52 by, May 5 2010

This doesn't seem to be working on my end... I created a Custom.css file in the "User 
StyleSheets" (with an 's') folder in the Default profile folder, then pasted in the 
code for this style:

And saved the file.  But it does not take effect even after I restart the browser 
(with or without --enable-user-stylesheet).  Installing the style as a userscript 
*does* work, so I don't think it's an issue with the style code.

I'm on the latest Beta, 5.0.375.29 (Official Build 46008) beta.

Comment 53 by, May 10 2010

@mkterra: If you properly pass --enable-user-stylesheet, when you launch chrome, it will automatically create 
"User StyleSheets\Custom.css" in your profile directory.

Comment 54 by, May 10 2010

It does generate a blank Custom.css file, but pasting code from into 
it (and saving) doesn't seem to do anything, even after restarting the browser (still 
with --enable-user-stylesheet).  I've tried a couple of styles without seeing any 

By the way, I thought your changes in  Issue 38182  removed the need for --enable-user-
stylesheet?  Was that reverted later in a different bug?

Comment 55 by, May 10 2010

Oh wait, I've got it: Chrome doesn't support @-moz-document url-prefix.  (Are there 
plans to add that?)

Comment 56 by, May 10 2010

The removal of --enable-user-stylesheet didn't make it into beta, but it is removed in the dev channel builds.

Please file a bug at about supporting @document url-prefix.

Comment 57 by, May 17 2010

If removal of --enable-user-stylesheet didn't make it into beta, does that mean this is 
not a supported feature for Chrome 5, but will be a supported feature for Chrome 6?

Comment 58 by, May 17 2010

@dhw: I'm not sure what you mean by "supported".  In Chrome 5, you will be able to enable this feature using the 
command line.

Comment 59 by, Jun 16 2010

Are there any plans involving adding per-site userContent?
Something along the lines of Mozilla's @moz-document, perhaps?

Comment 60 by, Jun 16 2010

When bug 29995 is done, you will be able to do that using an extension.

Comment 61 by, Dec 16 2010

Re: comment 56: I filed a bug for @-webkit-document over at

Comment 62 by, Jan 4 2011

Although this has been marked fixed, one of the original aims is not accomplished: that of a proper UI.
The Wrench > Options > Under the Hood > Web Content > "Change the default font and language for webpages" is thoroughly misleading to "average" (and unobservant) users coming from Firefox, for example. Misleading because the *default* is a rarity on the 'net. Users make changes there expecting these changes to be visible when they go surfing. Result: irate posts in the help forum.

It is even politically incorrect since font size and color are *accessibility* issues and Google should bend over backward to show it is friendly to the "differently abled" or whatever the phrase is now.

Comment 63 Deleted

Comment 64 by, Jul 6 2011

100% agree with comment #62

Comment 65 by Deleted ...@, Aug 22 2011

There's **still** no ability to create site-specific css in Chrome? WHAT THE F***!? Epic fail.

Comment 66 by Deleted ...@, Aug 22 2011

Implementing user css without the ability to apply custom css only to specific sites is utterly half-assed and makes the whole feature useless.

Comment 68 by, Aug 22 2011

> Implementing user css without the ability to apply custom css only to specific
> sites is utterly half-assed and makes the whole feature useless.

That’s what is all about.

Comment 69 by, Oct 13 2012

Project Member
Blocking: -chromium:15639
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 70 by, Mar 11 2013

Project Member
Labels: -Area-WebKit -Feature-Accessibility Cr-Content Cr-UI-Accessibility

Comment 71 by, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Sign in to add a comment