W3C CUAP: ability to select/disable both user and author style sheets

Assigned to



CSS Parsing and Computation
17 years ago
5 years ago


(Reporter: gerv, Assigned: glazou)


(Depends on: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)





17 years ago
[ This bug is one of the recommendations in the W3C's "Common User Agent 
Problems" document, URL above. One bug has been filed on each recommendation, 
for deciding whether we do it and, if not, whether we should. ]

2.1 Implement user style sheets. Allow the user to select from author and
user style sheets or to ignore them.

     A style sheet is a set of rules that specifies how to render a
     document on a graphical desktop computer monitor, on paper, as
     synthesized speech, etc. A document may have more than one style sheet
     associated with it, and users should be able to select from
     alternative style sheets.


17 years ago
Blocks: 68427

Comment 1

17 years ago

*** This bug has been marked as a duplicate of 6782 ***
Last Resolved: 17 years ago
Hardware: PC → All
Resolution: --- → DUPLICATE

Comment 2

17 years ago
The bug, which is about compliance with the guidelines, is blocked by bug 6782.
Marking as such, and reopening. We should only close this bug when we comply :-)

Depends on: 6782
Resolution: DUPLICATE → ---
Um, user stylesheets are not the same as alternate (author) stylesheets. Are you
sure you meant bug 6782?
My apologies, I misread the scope of 6782. Ignore my last comment...
Keywords: mozilla0.9.1

Comment 5

16 years ago
Reassigning to glazman.
Assignee: pierre → glazman
Target Milestone: --- → mozilla0.9.3


16 years ago
Severity: normal → enhancement
Priority: -- → P4
Target Milestone: mozilla0.9.3 → Future

Comment 6

16 years ago
beppe: although discussions are continuing in 
netscape.public.mozilla.seamonkey, I'm pretty certain that, if we take our claim 
to support HTML4 for Mozilla 1.0 at all seriously, this will need to be done 
before 1.0 is declared. Bug 6782, which is the sharp end of this issue, will 
need to be given at minimum a 1.0 milestone.



16 years ago
Depends on: 107023

Comment 7

16 years ago
removing myself from the cc list

Comment 8

16 years ago
related: bug 41975, bug 46848 ...

Comment 9

15 years ago
I think this is a dup of bug 45848.


15 years ago
Summary: W3C CUAP: Implement user style sheets; allow disabling. → W3C CUAP: ability to select/disable both user and author style sheets

Comment 10

15 years ago
... or maybe not.  This is more similar to bug 107023, a metabug tracking
"Alternate Style UI".


15 years ago
Depends on: 179006

Comment 11

15 years ago
nominating bug 83663 as a blocker
"Alternate style sheet setting not stored [AltSS]"
aka: "when I select an alt css, my selection doesn't stick as I browse the site"


Comment 12

14 years ago
Beyond "compliance", the capability to disable style sheets is needed when
developing Web pages for general use, especially for viewing by other browsers.
 I need to see how my pages might be viewed by someone who has disabled style
sheets in a non-Mozilla browser or whose browser does not support style sheets
(e.g., an audio browser for the visually handicapped).  

Yes, linked style sheets can be easily suppressed by commenting out the LINK
element.  This is not possible for imbedded and imported style sheets that
themselves are contained within HTML comments (as is recommended).  Those would
have to be removed for testing and then reinserted (carefully to avoid
introducing new errors).  Trying to suppress inline STYLE attributes scattered
throughout a page and then restore them would be a nightmare.  In any case,
altering a completed page for testing is a very bad idea since the alterations
might change the test results and hide defects in the page or (much more
frustrating) show defects that do not really exist; further, the page would then
have to be retested when the alterations are reversed.  


14 years ago
Depends on: 32372

Comment 13

12 years ago
We have an implementation of user style sheets, although you need an extension
(http://cdn.mozdev.org/chromedit/) to edit them in the UI. We also allow
disabling of author style sheets from the View menu. So I think this bug is fixed.

Last Resolved: 17 years ago12 years ago
No longer depends on: 107023
Resolution: --- → FIXED

Comment 14

12 years ago
As to SeaMonkey at least, working only with some extension does not make this
fixed. With my extensionless trunk build I cannot enable/disable my single user
stylesheet via the SeaMonkey UI. The UI only permits to choose among author
provided stylesheets, or no stylesheets at all.
adding a few of the SeaMonkey Council to this CC list to ponder comment#14.

Comment 16

12 years ago
That's all the back end allows us to do...

Comment 17

12 years ago
No code in Mozilla was changed.  Whether or not this should be considered
"done", the correct resolution here (for the current decision) should still be:


Resolution: FIXED → ---


12 years ago
Last Resolved: 12 years ago12 years ago
Resolution: --- → WORKSFORME

Comment 18

12 years ago
FWIW: Technically speaking, it shouldn't be resolved as WFM either - basing WFM
on an extension (in SeaMonkey anyway) is never right.  The "right thing to do"
is to either make it WONTFIX (because somebody in authority - the SeaMonkey
Council - has decided that this backend code will never be written) or leave it
open, unassigned and futured.  But it's really up to the SC to make that
decision in this case.

Comment 19

12 years ago
(In reply to comment #18)
> FWIW: Technically speaking, it shouldn't be resolved as WFM either - basing WFM
> on an extension (in SeaMonkey anyway) is never right.  The "right thing to do"
> is to either make it WONTFIX (because somebody in authority - the SeaMonkey
> Council - has decided that this backend code will never be written) or leave it
> open, unassigned and futured.  But it's really up to the SC to make that
> decision in this case.

You're very wrong, as the SeaMonkey Council is in no possible way any authority
over the Core backend, only MoFo is.

Comment 20

12 years ago
Quoting comment 2 "We should only close this bug when we comply". <em>We</em>
have not complied, and so therefore this bug has no business being marked either
FIXED or WORKSFORME. It's also my understanding that both Opera and Konqueror
have complied, and I have to guess Safari has too. If so, why should we plan to
do any less?

The lack of this feature continuously infuriates me. Extensions, as a general
rule, are no answer to those of us using exclusively trunk builds for both
normal use and QA work, since they generally disclaim compatability except with
release builds (and justifiably so). See e.g. bug 294742 .

Comment 21

12 years ago
A further comment on resolving a bug by citing an extension --  

This establishes the following commitments:  

1.  When the browser is modified, the extension will be guaranteed to still work
correctly.  The guarantee falls on the browser developers and not on the
extension developer.  

2.  When an existing user with the extension installs a new version of the
browser, the extension does not have to be reinstalled.  

3.  When a new user first installs the browser, the extension is automatically
installed with it.  

Comment 22

12 years ago
By the way, I have Mozilla Suite 1.7.11 with PrefBar 3.1.  I created a "noCSS"
button in PrefBar that redisplays the current page without any style-sheets. 
The button uses a bookmarklet that I got from Dorward Online.  

This is NOT a fix.  This is merely a work-around.  I consider any other
extension, plug-in, bookmarklet, or other contrivance to be a work-around and
not a fix unless it is inherent in the "vanilla" product.  
Resolution: WORKSFORME → ---

Comment 23

11 years ago
Is this now FULLY implemented?  In SeaMonkey, go to the menu bar and select [View > Use Style > None].  Does Firefox have the equivalent capability?  


Comment 24

11 years ago
David: Firefox does, but that's not all this bug is asking for. It's asking for user-visible UI for user stylesheets.

Mozilla and Firefox have support for user stylesheets, however they are managed outside of the chrome (by editing a text file). I'm not sure this will ever change. The demand from end users for the ability to edit their own CSS seems minimal, and is further reduced by the existence of things like Greasemonkey.

Comment 25

11 years ago
And Stylish :)  https://addons.mozilla.org/addon.php?id=2108

Comment 26

11 years ago
Stylish is no apparent help to Suite users. This bug asks that URL's "2.1 ... Allow the user to select from author and user style sheets ..." be implemented as a basic browser function, not as an add-on limited to only one Gecko browser product.

Comment 27

11 years ago
These features have to be accessed through browser UI such as menus or preferences, so it is up to each Gecko-based browser (Firefox, Camino, Seamonkey, etc.) to decide whether and how to present them.  It only becomes a core issue if the core APIs are found to be insufficient for supporting a desired user interface (e.g. as happened in bug 179006).

Comment 28

11 years ago
It seems since extension(s?) is(are?) available to provide the UI to accomplish selection among author and user sheets that the backend must now be in place. Since UI & backend apparently needed separate bugs and this one pre-dates Firefox by some years it seems this bug should be a Suite UI bug and not a core bug (unless that's what bug 6782 -> tracking bug 107023 are supposed to amount to). 

Whether many users need/want this or not, web developers who wish to use a single Gecko browser for both development and browsing, do need what David Baron proposed many years ago at http://dbaron.org/css/ssui/, without depending on extension(s), unless parity with Konqueror and Opera don't matter.


10 years ago
Depends on: 45848

Comment 29

10 years ago
In SeaMonkey, there is a no-CSS capability.  On the menu bar, go to [View > Use Style > None].  This seems to suppress not only style sheets but also styles implied by attributes.  For example, for <hr width="50%">, the horizontal rule will appear with a width of 100%.  This feature is a toggle.  Thus, having suppressed style for a Web page, style can be restored without reloading the page by selecting [View > Use Style > Default Style].  

I also discovered a JavaScript that suppresses style sheets without affecting styles implied by attributes:  
I use this as a bookmarklet via a PrefBar button.  In this case, restoring style requires reloading the page.  
QA Contact: ian → style-system
Priority: P4 → P5
You need to log in before you can comment on or make changes to this bug.