Open Bug 68416 Opened 22 years ago Updated 2 months ago
W3C CUAP: ability to select/disable both user and author style sheets
[ 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 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Hardware: PC → All
Resolution: --- → DUPLICATE
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 :-) Gerv
Status: RESOLVED → REOPENED
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...
Reassigning to glazman.
Assignee: pierre → glazman
Status: REOPENED → NEW
Target Milestone: --- → mozilla0.9.3
Severity: normal → enhancement
Priority: -- → P4
Target Milestone: mozilla0.9.3 → Future
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. Gerv
removing myself from the cc list
I think this is a dup of bug 45848.
Summary: W3C CUAP: Implement user style sheets; allow disabling. → W3C CUAP: ability to select/disable both user and author style sheets
... 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" -matt
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. Gerv
Status: NEW → RESOLVED
Closed: 22 years ago → 18 years ago
No longer depends on: altss
Resolution: --- → 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: -> WORKSFORME
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
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 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.
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.
Assignee: daniel → nobody
You need to log in before you can comment on or make changes to this bug.