[ 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.
*** This bug has been marked as a duplicate of 6782 ***
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 :-)
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...
Reassigning to glazman.
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.
removing myself from the cc list
related: bug 41975, bug 46848 ...
I think this is a dup of bug 45848.
... or maybe not. This is more similar to bug 107023, a metabug tracking
"Alternate Style UI".
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"
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.
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.
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.
That's all the back end allows us to do...
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:
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.
(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.
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 .
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
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.
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.
Is this now FULLY implemented? In SeaMonkey, go to the menu bar and select [View > Use Style > None]. Does Firefox have the equivalent capability?
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.
And Stylish :) https://addons.mozilla.org/addon.php?id=2108
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.
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).
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.
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 use this as a bookmarklet via a PrefBar button. In this case, restoring style requires reloading the page.