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

Status: REOPENED

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

Description

[Gervase Markham [:gerv]]

[ 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.

Comment 1

[Matthew T (active 1999-2002)]

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

Comment 2

[Gervase Markham [:gerv]]

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

Comment 3

[Hixie (not reading bugmail)]

Um, user stylesheets are not the same as alternate (author) stylesheets. Are you
sure you meant bug 6782?

Comment 4

[Hixie (not reading bugmail)]

My apologies, I misread the scope of 6782. Ignore my last comment...

Comment 5

[karnaze (gone)]

Reassigning to glazman.

Comment 6

[Gervase Markham [:gerv]]

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

Comment 7

[rubydoo123]

removing myself from the cc list

Comment 8

[John Levon]

related: bug 41975, bug 46848 ...

Comment 9

[Jesse Ruderman]

I think this is a dup of bug 45848.

Comment 10

[Jesse Ruderman]

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

Comment 11

[m_mozilla]

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

Comment 12

[David E. Ross]

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.  

Comment 13

[Gervase Markham [:gerv]]

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

Comment 14

[Felix Miata]

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.

Comment 15

[Justin Wood (:Callek)]

adding a few of the SeaMonkey Council to this CC list to ponder comment#14.

Comment 16

[[e-mail]]

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

Comment 17

[Jason Bassford]

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

Comment 18

[Jason Bassford]

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

[Robert Kaiser]

(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

[Felix Miata]

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

[David E. Ross]

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

[David E. Ross]

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.  

Comment 23

[David E. Ross]

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

[Gervase Markham [:gerv]]

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

[Jesse Ruderman]

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

Comment 26

[Felix Miata]

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

[Jesse Ruderman]

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

[Felix Miata]

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.

Comment 29

[David E. Ross]

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:  
  javascript:
    for(i=0;i<document.styleSheets.length;i++)
      {void(document.styleSheets.item(i).disabled=true);}
      el=document.getElementsByTagName('*');
    for(i=0;i<el.length;i++)
      {void(el[i].style.cssText='');}
I use this as a bookmarklet via a PrefBar button.  In this case, restoring style requires reloading the page.  

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.