45848 - [AltSS] alternate user stylesheets

Status: NEW

(Core :: CSS Parsing and Computation, enhancement, P5)

Description

[fantasai]

<BLOCKQUOTE cite="news:[e-mail]">
 <!-- fantasai. "Re: user stylesheet". June 26, 2000. n.p.m.style -->
  Request for Enhancement:
    I would like to see Mozilla able to apply user stylesheets from more
    than one file and from anywhere on the user's disk. IMO, the same
    freedoms and capabilities available to the page author should also
    be available to the user. A file of <link>s can allow the user to
    design their own sets of persistent, preferred, and alternate user
    stylesheets. As for the UI, something similar to mail filters might
    work.
 </BLOCKQUOTE>

Just dreaming, I guess...
The menu options for selecting the user stylesheet set would go under a 
horizontal rule in the Use Stylesheet submenu. UI for creating the file is not 
required.

Comment 1

[Pierre Saslawsky]

I'm closing this as dup of bug 6782 and moving your comments there. Bug 6782 will 
be probably be marked LATER or Future after we checkin Tim's patch. The only 
improvement that may still make it for FCS is the persistence of the selected 
author stylesheet for any given page.


*** This bug has been marked as a duplicate of 6782 ***

Comment 2

[Christine Hoffman]

Adding keyword 'verifyme' to bug.

Comment 3

[Christine Hoffman]

Verified dup of #6782

Comment 4

[fantasai]

Splitting up bug 6782 ("UI for alternate and user stylesheets").

"One bug report == one issue is one of the golden rules of Bugzilla because it
enables independent tracking and prioritization of each issue."
                                              -- [e-mail], bug 4510

Comments from bug 6782:


------- Gervase Markham <[e-mail]> 2001-03-28 05:03 -------

Alternate Style Sheet UI is not on enough radars :-) This shouldn't be _too_ 
tricky, should it? I suppose it depends how complex we want to get with the UI.

Perhaps a simple "enter the path to your user stylesheet here" in the prefs to 
begin with? And a menu on/off toggle? At least it's a start - as no-one seems to 
have resources to spend on this bug.

Gerv


------- Gervase Markham <[e-mail]> 2001-03-28 05:52 -------

An additional point: changing user stylesheets on the fly is going to be tricky, 
because (according to my reading of 
http://lxr.mozilla.org/seamonkey/source/rdf/chrome/src/nsChromeRegistry.cpp#2713
) the user and chrome style sheets are loaded once at profile init time... Can 
someone check this and say if that's right?

Gerv


------- Gervase Markham <[e-mail]> 2001-04-03 09:36 -------

ccarlen: Can you answer the question I posed in this bug? LXR claims the code 
I'm talking about is yours :-)

Gerv


------- Gervase Markham <[e-mail]> 2001-05-24 13:54 -------

Again, I make the point that we are in danger of having _no_ user stylesheet UI 
because people have planned a really slick one and don't have time to implement 
it.

The current architecture, according to my reading, allows for a single user 
stylesheet to be loaded at start time. We should provide a filepicker in prefs 
for people to say which one they want, if any. This would be an attainable 
start.

Getting something better is going to involve a lot more work - it's not just UI.

Gerv


------- Gervase Markham <[e-mail]> 2001-06-27 11:01 -------

If any bug is a 1.0-stopper, this is. Can someone please answer the technical 
query I posed _three_months_ ago?

"An additional point: changing user stylesheets on the fly is going to be 
tricky, because (according to my reading of 
http://lxr.mozilla.org/seamonkey/source/rdf/chrome/src/nsChromeRegistry.cpp#2713
) the user and chrome style sheets are loaded once at profile init time... Can 
someone check this and say if that's right?"

Gerv



------- Boris Zbarsky <[e-mail]> 2001-06-27 11:56 -------

OK.  Looks like the code has moved in the file.  The function to look at
(LoadProfileDataSource) is at
http://lxr.mozilla.org/seamonkey/source/rdf/chrome/src/nsChromeRegistry.cpp#2853

This does load the user/chrome sheets at startup, yes.  It stores them in
mUserContentSheet/mUserChromeSheet.

It gets the URLs using GetUserSheetURL
(http://lxr.mozilla.org/seamonkey/source/rdf/chrome/src/nsChromeRegistry.cpp#283
6).

The actual code that fetches the sheets uses the values stored in
mUserChromeSheet and mUserContentSheet (GetUserSheets at 
http://lxr.mozilla.org/seamonkey/source/rdf/chrome/src/nsChromeRegistry.cpp#2788
).

GetUserSheets is called in the document viewer
(http://lxr.mozilla.org/seamonkey/source/content/base/src/nsDocumentViewer.cpp#3
737).

So it's possible that updating mUserChromeSheet/mUserContentSheet dynamically
will just work (since it looks like DocumentViewerImpl::CreateStyleSet should be
called anew for every document).

A possible approach would be:

1)  Make GetUserSheetUrl use a preference for the url instead of hardcoding the
    filename
2)  Make the default preference values correspond to the current names
3)  Make sure the values of mUserChromeSheet/mUserContentSheet are updated when
    the preference is changed.
Does that sound reasonable or am I on crack? 



------- Gervase Markham <[e-mail]> 2001-06-27 12:37 -------

userChrome.css is not relevant to this bug, right? If we can do stuff with it 
while we are there, cool, but it's not an issue. (We can probably do all this 
stuff with userChrome in parallel anyway.)

We need to support multiple simultaneous user stylesheets. So 
mUserContentSheet needs to be an array which gets appended to the 
nsISupportsArray in GetUserSheets().

I suggest that the "installed" style sheets (as displayed in the menus) are all 
the ones in the to-be-created directory and so the pref could store a 
comma-separated list of the bare filenames of the sheets which are currently 
switched on in the UI. 

GetUserSheetURL() needs to be plural, and create URLs from each of the names in 
the pref, and return the list as an array. 

LoadProfileDataSource() needs to loop over, and put in mUserContentSheets, all 
the sheets that GetUserSheetURLs() returns.

We can register the pref as some sort of callback thingie that will update the 
member variables if and when the pref gets changed in the UI. However, unless we 
do something particularly cunning (dynamically insert/remove style? force a 
reload?) then the changes won't be immediately visible, because I doubt 
GetUserSheets gets called more than once. That would suck.

How do we manage that for author stylesheets, I wonder...

Gerv



------- Boris Zbarsky <[e-mail]> 2001-06-27 13:12 -------

Data point.  I just did some testing and looks like GetUserSheets gets called on 
every document load.  So any updates we make to the stylesheet list would take
place on reload....  In any case, it seems to me that this would only be
necessary when we create new user sheets or delete old ones

1) We have some set of user sheets in the chrome dir.
2) We have a preference listing all the user sheet names.
3) For each name we have a preference of whether it's enabled (a boolean pref).
4) At startup, we put all the sheets in the mUserContentSheets array (as Gerv
   said).  Then we set the enabled attribute of each based on the corresponding
   pref.
5) In the UI we have a list of the existing sheets with a check next to the
   enabled ones.  Selecting a sheet toggles the enabled attribute in the current 
   doc and in mUserContentSheets (this part could be hard) and also flips the
   corresponding pref.

How does that sound?



------- Gervase Markham <[e-mail]> 2001-06-27 13:31 -------

> In any case, it seems to me that this would only be
> necessary when we create new user sheets or delete old ones

It's been decided that the user should do this by manipulating files in the 
styles directory (or whatever we call it.) So, we'd have to check (perhaps on 
opening the menu?) that the files in that directory, _and_ their modification 
dates, corresponded with those we had stored in the pref system (so currently we 
have three data items: sheet name, last changed date, and enabled boolean.) 

If the sheets had changed, we'd load the new sheets and unload the old 
ones, updating mUserContentSheets, before opening the menu, and display the new 
version of the styles directory. After any modifications or none, we'd call 
Reload().

[ Alternatively, we can just make the user restart Mozilla if they want to add 
or remove style sheets from their user set. But I think the above might avoid 
that, at the cost of doing file I/O operations every time the style menu is 
opened. ]

Otherwise, as you say, we don't need to - we can just flip enabled bits in the 
style structure, which I assume Does The Right Thing to the page on the fly. I 
assume it'll wait a millisec to see how many changes we are making before 
relaying things out.

We can do the prefs as:
something.style.user_sheets.<name>.lastmoddate
something.style.user_sheets.<name>.enabled

If there are no prefs for that <name>, it's a new sheet. AIUI, the new Pref 
branch business allows us to ask for a branch "something.style.user_sheets" and 
just work with that.

Gerv



------- Boris Zbarsky <[e-mail]> 2001-06-27 13:43 -------

> It's been decided that the user should do this by manipulating files in the 
> styles directory (or whatever we call it.)

Wnen was this decided?  This seems like a bad idea:

1) The "styles" directory is the profile chrome dir.  It has user content 
sheets,
   user chrome sheets, and various other non-style-sheet files.
2) When a user edits a stylesheet, many editors will create a backup file in the
   same directory.  We would pick this file up in our scan.

Adding/Deleting user sheets seems like something that's used rarely enough that
it should be a preference panel and not live in the menus.  It would make more
sense to me to have a preference panel for this in which one can click an "add a
new sheet" button, go through the list of possible sheets shown (the list of
files in the directory) and add one to the list of selected available sheets. 
When OK is clicked the stylesheets will all be read/updated/removed en masse.



------- Jonas Sicking <[e-mail]> 2001-06-27 13:48 -------

I don't think that it's very friendly on page-loadtime if we scan all selected 
user-stylesheets, if they have been updated at every pageload. I think that at 
least on windows you can have the OS notify you when a file is changed.



------- Gervase Markham <[e-mail]> 2001-06-27 14:36 -------

> Wnen was this decided? 

Alternate Styles Discussion, v.2.4, attached here - although I may have 
misrepresented it slightly.
 
> I don't think that it's very friendly on page-loadtime if we scan all selected 
> user-stylesheets, if they have been updated at every pageload. 

It would be the equivalent of (probably max a dozen) stat() calls, which would 
be done every time the user opened the "Use Stylesheet" menu, not at every page 
load. I think this is probably reasonable. After all, we're not reading or 
parsing the files.

> I think that at 
> least on windows you can have the OS notify you when a file is changed.

Well, that would be good too. 

Gerv



------- Jonas Sicking <[e-mail]> 2001-06-27 14:42 -------

ok, as long as no fileoperations is done for every pageload i'm fine with it



------- [e-mail] 2001-06-27 15:19 -------

stats can be expensive. on some os's you can ask to be notified of 
changes/writes to a directory, i'd be much happier if we only called stat if we 
had a reason.  Also can we compare file lengths? if they change but the date 
doesn't then the data changed.



------- Peter of the Norse <[e-mail]> 2001-06-27 17:06 -------

> We need to support multiple simultaneous user stylesheets.

I don't see why. Do people really decide on a whim to change pages that 
don't have any style applied? Or do they have a page that says "* {color: 
black; background-color:white;}" so that they can switch to a easy to read 
page on the fly?

The W3C specs are there because because the CSS has to deal with 
user preferences. They don't say anything multiple simultaneous user 
sheets and no one else supports them.



------- [e-mail] 2001-06-27 19:37 -------

Hang on. It was decided early on in this discussion /not/ to support multiple 
simultaneous user stylesheets. The styles directory would hold a collection of 
user stylesheets from which the user picks just one. If the user wants to apply 
styles from multiple files, s/he can import them.

BTW, since we are relegating the user style UI to the prefs dialog, we don't 
need a styles directory, just the ability to specify one file. Right?



------- Gervase Markham <[e-mail]> 2001-06-27 23:35 -------

> Hang on. It was decided early on in this discussion /not/ to support multiple 
> simultaneous user stylesheets. 

What confused me was "any selected user styles" in the document; but, rereading 
it, it says "A User Style remains in effect until the user selects another 
User Style." Oops. So, ignore all that. One user stylesheet only.

> BTW, since we are relegating the user style UI to the prefs dialog, 

We are?

Gerv



------- Andrew Smith <[e-mail]> 2001-06-28 01:07 -------


If you were going to allow selection of multiple stylesheets, putting it on the
menus would *bad*, as it would force a View > Use Stylesheet navigation per
selection change made. The View > Show/Hide is hardly a masterpiece of UI, now,
is it?

But, as only one is required, it *could* be put on the menus, in the same way
author-provided stylesheets are listed. However, this would require all the
stylesheets to be in a single known directory so they could be enumerated. It
would be much more straight foward to provide a "Choose File" option in the
prefs dialog, under Appereance > Advanced (or maybe that should be Advanced >
Appearance). This also gives you the space to provide some explanatory blurb, as
this will be (at least initially) above the heads of 99% of users.

To aid user discovery, you could add a View > Use Stylesheet > Change User
Stylesheet... menu entry. This is much like View > Apply Theme > Theme
Preferences... although this reminds me that these menus should be just
"Stylesheet" and "Theme" respectively, give what's on these sub-menus.


------- Gervase Markham <[e-mail]> 2001-06-28 03:49 -------

> If you were going to allow selection of multiple stylesheets, <snip>

Yes, but we aren't, are we? <looks embarrassed>

> But, as only one is required, it *could* be put on the menus, in the same way
> author-provided stylesheets are listed. However, this would require all the
> stylesheets to be in a single known directory so they could be enumerated. 

Having a single known directory (in the profile) was what 2.4 (attached above)
said.

> It would be much more straight foward to provide a "Choose File" option in the
> prefs dialog, under Appereance > Advanced (or maybe that should be Advanced >
> Appearance). 

And, IMO much less usable. If you have to enter the prefs and a filepicker every
time you want to choose your user stylesheet, no-one will ever bother. You
should set the user stylesheet folder in the prefs, and then choose a stylesheet
from that folder from a menu off the View menu, like you choose Author Styles. 

> on some os's you can ask to be notified of changes/writes to a directory,

If we have support for this within the XP framework, fine. But this feature
should not require platform-specific code. When you open a filepicker, it
presents you with a list of files in a given directory. We would just be doing
the same thing.


------- Boris Zbarsky <[e-mail]> 2001-06-28 07:29 -------

> And, IMO much less usable. If you have to enter the prefs and a filepicker
> every time you want to choose your user stylesheet, no-one will ever bother.

The impression I got was that you would go to prefs when you wanted to add a new
user stylesheet or delete an existing one.  Then the menu would allow you to
choose among the style sheets you had added.

This seems like a better idea to me than having a stylesheets folder...


------- [e-mail] 2001-06-28 12:01 -------

| > BTW, since we are relegating the user style UI to the prefs dialog, 
|
| We are?

Yep. When I posted to n.p.m.ui, one person (Braden) commented that the user 
styles UI should be moved to the prefs dialog to reduce complexity. I replied 
that I disagreed, but nobody else said anything. So when I later saw Matthew 
Thomas on IRC, I asked him to just pick one, and v2.4 is the result.
Not many people commented in the newsgroup.. 
(The thread's long, but most of it is about <link>.)

IMO, there should be an easy way for the user to override author styles on a 
page-by-page basis, without disabling them. Whether this is done through a user
style menu or through an override switch is not that much of an issue for me. I 
actually prefer the latter.

 (See bug 46839, RFE: user style override switch, WONTFIX)

| Yes, but we aren't, are we? <looks embarrassed>

I've made worse mistakes. Don't worry about it. :)

| And, IMO much less usable. If you have to enter the prefs and a filepicker
| every time you want to choose your user stylesheet, no-one will ever bother.

If you're already in the prefs dialog, using a filepicker is not much of a 
stretch, especially if it opens to the same directory your user stylesheet is 
in--you can make that your de facto User Style Folder.

| The impression I got was that you would go to prefs when you wanted to add a
| new user stylesheet or delete an existing one.  Then the menu would allow you
| to choose among the style sheets you had added.

'Twas decided that creating a UI and an output format for doing this was an 
unnecessary amount of work, as we could just let the OS do it for us.


------- [e-mail] 2001-06-28 13:18 -------

ack. soo complicated. i probably shouldn't comment as i haven't read the 
prereqs.

view>use stylesheet>
x Site Style
  -
  no extra rules
x Preferred
  Extra Readable
  Widescreen
  -
  Browse...

I don't see any harm in allowing the user to browse for a stylesheet from the
menu.  Sure you can't delete on from the menu (well.. if we behave like
bookmarks and bookmarks ever allow right click deleting view menus then ...) but
for the time being there doesn't seem to be any harm in a browse option.



------- Gervase Markham <[e-mail]> 2001-06-29 15:00 -------

I am strongly of the opinion that the UI should be (text subject to change, 
that's not the point):

View -> Page Styles ->   None
                         Default
                       o Alternate 1
                         Alternate 2
        User Styles ->   None
                         Widescreen
                       o Big Text
                         Monochrome

Edit | Preferences | Appearance (or somewhere) -> choose a folder which contains 
e.g. Widescreen.css, Big Text.css and Big and Wide.css. Adding and removing 
files from that folder is done using the user's favourite file manager, and the 
CSS files are edited using the user's favourite editor.

(This is as 2.4 except for the method of selecting the User Style.) This seems 
to me to be the clearest and most consistent UI. It seems strange to be able to 
select author styles from a menu, but make you dive into the Prefs to change the 
page style.

I think it's reasonable to assert that Preferences should be things you set 
independently of the page you are viewing; defaults and things you want to 
change about the UI or method of presentation permanently. All of our current 
Preferences options fit into this description, and I think that's important. So, 
the "select a user style sheet for the current page" UI should be in the menus.

In a standard eveyday surfing session, the user should not need to go into the 
Prefs.

Gerv



------- Braden <[e-mail]> 2001-06-29 17:03 -------

timeless: The harm in allowing the user to change stylesheets from the menu is
that it complicates the UI for something that won't be changed very often. User
stylesheets are like themes; and you don't see themes being set from a menu.

Gervase: Multi-level menus are annoying, and should be avoided where possible.
If including the user stylesheet selection in the UI is the reason adding a menu
level, I'd suggest that is grounds for rethinking the idea of including user
stylesheet selection in the menu.

And why are page-specific user stylesheets being rolled into the inital
implementation of this feature? That is a *substantial* complication; and
considering the limitations of CSS, it is of truly questionable value anyway. No
matter how you spec it, CSS user stylesheets are a damned unwieldy way of
setting page-specific accessibility parameters.



------- [e-mail] 2001-07-01 03:27 -------

> I am strongly of the opinion that the UI should be (text subject to change,
> that's not the point):

Have you taken a look at v2.3? That includes a previously agreed-upon user style 
menu UI. If we choose to put user style selection in the menus, then I'd suggest 
reverting to that first and then make changes to it based on its shortcomings.


------- Gervase Markham <[e-mail]> 2001-07-01 08:09 -------

> User stylesheets are like themes; and you don't see themes being set from 
> a menu. 

I don't agree. I can envisage several scenarios where you might want to use a 
particular user stylesheet for just a few pages during a surfing session. For 
example, if you had a "fix too-small text" stylesheet, which boosted the size of 
certain tiny text sizes whilst leaving the rest alone, you would only want to 
apply it where it was necessary (because it may have undesireable effects on 
pages you can read anyway.)

As time goes on, more and more uses will be found for user stylesheets. Apart 
from the conceptual line that I drew in my previous posts (no per-page things in 
Preferences) if we add the UI to the Preferences, as people start using them 
more they will find it very clunky.

> Multi-level menus are annoying, and should be avoided where possible.

There are six menus of the nesting level I suggest on the View menu, two on 
Tasks, four on Debug and one on File. They are a normal part of Mozilla's UI. 
Having submenus off submenus is bad, I'll agree. But I'm not proposing that.

> Have you taken a look at v2.3? 

I hadn't. Ah. It seems the only difference between that proposal and mine is 
that I propose two top-level menus (one for User and one for Author) and it 
proposes a single one. It's true, this could be switched around easily.


------- Ian 'Hixie' Hickson <[e-mail]> 2001-07-01 14:40 -------

Braden wrote: 
> User stylesheets are like themes; and you don't see themes being set 
> from a menu.

Er. "View | Apply Theme". Before we let it regress to the point where it 
wouldn't
work it would even apply the theme on the fly, which was great. Similarly, 
WinAmp
lets you change the theme on the fly from a menu. So, "yes you do".



------- Ian 'Hixie' Hickson <[e-mail]> 2001-07-01 14:49 -------

Note: Food for thought on the user stylesheet side: bug 64945 has a suggestion 
for
an alternative user stylesheet that would be picked if the document being viewed
is an unstyled XML document. This could then be picked manually on other CSS 
documents, and would be totally configurable just like any other such 
stylesheet.


------- [e-mail] 2001-07-29 14:06 -------

Gervase said:

>I don't agree. I can envisage several scenarios where you might want to use a 
>particular user stylesheet for just a few pages during a surfing session. For 
>example, if you had a "fix too-small text" stylesheet, which boosted the size 
>of 
>certain tiny text sizes whilst leaving the rest alone, you would only want to 
>apply it where it was necessary (because it may have undesireable effects on 
>pages you can read anyway.)

I would like to go on record as being in full agreement on this point. Yes, per
page style sheets temporarily applied is just what I want. Most pages are
readable as they stand. I've always wanted a browser that had this feature to
use just on a particular page without permanently changing the settings. To make
it really easy to apply I'd like to have a section over on My Sidebar where
several stylesheets are listed. Then be able to double click or click and drag a
style sheet to change just the current window. 
   Example of the kind of site that needs style sheet overrides:
   http://www.hardocp.com/

I'd really like to have different style sheets to use to deal with different
common layout problems. I find the most common problems are:
   1) Yellow text on black background (or other similar poor contrast stuff like
blue on black).
   2) Fonts that are too small.
   3) A background that is some sort of image that has colors that are close to
the text colors so that in some spots you can't read it.

There are probably a couple of others that I'm forgetting. But the idea here is
to have a few common override style sheets that can be quickly accessed and
applied to a particular page. 

My advice is to make style sheets accessible in a format that is more like
bookmarks. Be able to put them in particular folders and then double click on
one to apply it. There could even be clicking variations with Shift-Click or
something similar to mean "Replace current style sheet" vs "Add style sheet to
exist stylesheets for page".




------- Henri Sivonen <[e-mail]> 2001-08-01 00:25 -------

Re: multiple user style sheets

I have noticed, that I feel the need to have two:
1) A persistent extension to html.css that participates in the cascade with user
!important rules. This could contain stuff like:
html, body, p, font[size=-1], .small, .content {
  font-size: -moz-initial !important;
}

2) A style sheet that attempts to redefine and fix everything. This would be for
coping with totally broken design (liek Opera's user mode). I'd like to be able
to select this one using a keyboard shortcut.



------- Matthew Thomas (mpt) <[e-mail]> 2001-08-26 06:16 -------

It seems to me that most of what people want on-the-fly user style sheet
switching for would be more conveniently achieved by bug 38521.


------- Paul McGarry 2001-10-11 00:57 -------

[discussion on adding alt style switching to <link> toolbar]

The only complication I can see is if you factor User Style sheets into the
equation.  Should a choice of user stylesheet be at the tab, window or app
level? This is probably a hairy question as it would depend on the user. Eg a
user with particular eyesight needs may want a user stylesheet specifying a big
font with contrasting colours globally for all their tabs/windows. Another user,
say a devloper who wishes to use a stylesheet such as
http://homepages.tig.com.au/~mcgarry/user.css to get a quick idea of document
structure may wish to only have it apply to a given tab. I don't see a viable
solution to solving both these peoples needs other than having a UI at both
levels which allows choice of user stylesheets. That doesn't sound particularly
pretty but I can't think of another immediatly obvious way of solving both
people's needs.


------- Pierre Saslawsky <[e-mail]> 2001-10-11 20:09 -------

My vote goes to adding the stylesheets in a Document Toolbar (currently known as 
the Navigation Toolbar).  I propose a simple popup menu that would show the list 
of stylesheets...

A second step will be to add user stylesheets to this menu.  I think it is more 
important however to encourage authors to develop styles and offer users a 
simple 
way to select them.


------- [e-mail] 2001-10-11 22:35 -------

> A second step will be to add user stylesheets to this menu.

If the UI is for the site, let it remain for the site. There's no need to 
confuse the issue. IMO, the user style selection fits perfectly fine in the View 
menu, and there's little advantage to moving it onto the toolbar.


------- Gervase Markham <[e-mail]> 2001-10-12 10:28 -------

> IMO, the user style selection fits perfectly fine in the View 
> menu, and there's little advantage to moving it onto the toolbar.

Yes. I think user stylesheets are fine where they are. This UI needs to be
available always, and the Site Toolbar won't be. There's no correlation between
the appearance of the site bar and the possible need for the user to apply a
stylesheet.

Gerv

Comment 5

[John Levon]

Isn't this a dupe of bug 

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Assigning pierre's remaining Style System-related bugs to myself.

Comment 7

[R.K.Aa.]

*** Bug 153720 has been marked as a duplicate of this bug. ***

Comment 8

[Christopher Hoess (gone)]

*** Bug 157902 has been marked as a duplicate of this bug. ***

Comment 9

[fantasai]

Jonas -- why did you switch components?

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

UID is going away, so people are moving bugs out of it.

Comment 11

[Jonas Jørgensen]

fantasai, see bug 167289. Cc'ing mpt won't do any good -- he's now living, by
his own words, "in a post-Mozilla world".

Comment 12

[Nick Hill]

I miss a function which is available in Opera where you can click a chrome
button to cycle between view modes. The Opera button cycles between 'normal
page+images' 'normal page no images' and 'user defined colours and fonts- no images'

The last of the three options is particularly useful where you want to read the
page content where the author has put eye candy distracting from readability.
This would also be good for those visually impaired.

I have resorted to opening up the page in a text-only terminal browser such as
lynx to strip out anoying background images and give me eye-friendly yellow on
black.

Would this bug cover such functionality, is there another bug for this function
or does this function need another bug?  

Comment 13

[Shane Killian]

*** Bug 196560 has been marked as a duplicate of this bug. ***

Comment 14

[Kim Scarborough]

In the meantime, is there any hackery that might approximate this functionality?
Like, can Mozilla be tricked into thinking <link rel="alternate stylesheet"
href="file:///somelocalfile.css"> exists in the header? Or is there some magical
@import CSS tag that will import alternate sheets that could be snuck into
userContent.css? Or... something?

One final question. I wouldn't think this would be terribly hard to fix, but
what do I know. Would a pizza-and-six-pack bribe be enough to get somebody to
code this functionality, or is this bug way beyond that in complexity? If the
former, who would be the best person to send it to?

Comment 15

[phil]

just to give a workarround solution: on
http://www.squarefree.com/userstyles/
there is explanations for using bookmarklets to change the style of the current
page.

Comment 16

[Kim Scarborough]

Isn't this fixed by bug 238099?

Comment 17

[Boris Zbarsky [:bzbarsky]]

No.  Please read comment 0.

Comment 18

[Serzh]

In Firefox 0.9 there was ability to change stylesheet to alternative one using
icon in left bottom corner. In 1.0 looks like there isn't such possibility... Is
this so?

Comment 19

[fantasai]

That was for alternate *author* style sheets, and you can still switch styles
from the View > Page Style menu.

Comment 20

[Serzh]

(In reply to comment #19)
> That was for alternate *author* style sheets, 
Ups, sory for offtopic...
> and you can still switch styles from the View > Page Style menu.
Do you know why is was removed from status bar? By this i could see if there is
multiply stylesheets for this page whithout going to View > Page Style menu. Is
was very suitable.

Comment 21

[Gérard Talbot]

*** Bug 329328 has been marked as a duplicate of this bug. ***

Comment 22

[Gérard Talbot]

*** Bug 329328 has been marked as a duplicate of this bug. ***

Comment 23

[Jesse Ruderman]

This extension lets you maintain different user stylesheets for each site:
http://userstyles.org/stylish/