Closed Bug 6782 Opened 25 years ago Closed 23 years ago

[RFE] UI for alternate and user stylesheets [IMPORT] [AltSS]

Categories

(SeaMonkey :: UI Design, enhancement, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 107023
Milestone:
Future

People

(Reporter: dbaron, Assigned: fantasai.bugs)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: html4, Whiteboard: REPLACED BY BUG 107023)

Attachments

(9 files)

Patch to allow user selection of author stylesheets in View > Use Stylesheet
5.11 KB, patch
Details | Diff | Splinter Review
Alternate User Styles Discussion - Summary v1.0
3.98 KB, text/plain
Details
Alternate User Styles Discussion - Summary v1.1
3.53 KB, text/plain
Details
Alternate Style Discussion - Summary v2.0
5.69 KB, text/plain
Details
Alternate Style Discussion - Summary v2.1
6.68 KB, text/plain
Details
Alternate Style Discussion - Summary v2.2
7.31 KB, text/plain
Details
Alternate Styles Discussion - Summary v2.3
6.96 KB, text/plain
Details
Simple fix for stylesheet code broken by unrelated checkin
632 bytes, patch
Details | Diff | Splinter Review
Alternate Styles Discussion - Summary v2.4
5.44 KB, text/plain
Details 
A good user interface for alternate and user stylesheets would be a very useful
(and neat) feature.  Alternate and user stylesheets were among the original
design goals of CSS and an interface for using them has not been properly
implemented in any browser.  I've written a document describing what I think
should be part of such an interface:

http://www.fas.harvard.edu/~dbaron/css/ssui/

The functions needed to implement part of the interface are already implemented
in the style code, as I describe in the page above.

Note that requests for this feature have been featured in WSP reviews of MSIE
and Opera:
http://www.webstandards.org/css/winie/#Alternate_stylesheet_UI
http://www.webstandards.org/css/opera/#Alternate_stylesheet_UI
Can you please comment on this?
Can you please comment on this?
David:
Thanks for your proposal.
Due to the already crowded nature of the menu bar in Navigator we will not be
able to accomodate additional menus for style sheet options as described by the
authors . However the right place for them to be will be the view menu. We
should work to see whether we can get some of the options described into a
submenu (pop-out) underneath view.
underneath the view menu. I will read through
Summary: RFE: UI for alternate and user stylesheets → {css1} RFE: UI for alternate and user stylesheets
Note that in any case this is a requirement for full HTML4 compliance.
Assignee: german → don
Allowing access to alternate stylesheets is a requirement in the HTML4 spec,
however section 14.3.1 does not specify the means by which the agent gives
access to these alternate stylesheets. It simply says: "User agents should allow
users to select from alternate style sheets."
(http://www.w3.org/TR/REC-html40/present/styles.html#h-14.3.1)
Thus using a submenu in the agent's view menu as specified above and showed (but
not hooked up yet in the current build) does fully comply with the HTML 4 spec.
We do not need (or want) an extra top-level menu for that.
Having said that, I'll change the bug to 'later' as inhaling and hooking up to
author-created alternate style sheets as well as applying them to the
currently view document will require extra work on the XPFE side. Forwarded to
Don Melton, XPFE Zen Master.

The spec should be:
"Use Stylesheet >" is a top level submenu under the "View" menu. From there the
first section contains built-in style sheets, and then a second section below a
separator enumerating the alternate author stylesheets pre-fixed by "From
Author:".
Target Milestone: M14
Moving this to M14 for now 'cause I can't squeeze the work into the first beta
if we do this.  Perhaps someone from the net can lend a hand here ...
Component: UE/UI → XPApps
Two notes:

The top level menus wasn't really a serious suggestion for Mozilla's
distribution chrome, although I know a few people who would want it in
customized chrome.

I really do think it is better to have two submenus of the View menu, one for
user stylesheets and one for author stylesheets, rather than combine them into
one confusing menu.
Summary: {css1} RFE: UI for alternate and user stylesheets → [RFE] UI for alternate and user stylesheets
Two submenus would be fine as well. I suggest not showing the author style
sheets menu at all, when there are none supplied (or at least greying them out),
in order to simplify and reduce the clutter in the menu for the 90% case
initially.
Bug #11520 is related to this.
Well, considering they're both about submenus to provide good stylesheet
support, I thought anyone reading this might also be interested ...
"Remember for" facilities for author and user stylesheets can be done with bug
#7380 capabilities.  You can't do the "when present" bit as I consider it at
the moment, but you could extend it to do it.  I'm developing a discussion
document on that and will see what I can think up on this issue.
*** Bug 20040 has been marked as a duplicate of this bug. ***
Move to M20.
Just wanted to point out that the XML style sheet recommendatation
(www.w3.org/TR/xml-stylesheet/) allows for alternate style 
sheets, so that this mechanism should also work for XML data.
FYI, hyatt has implemented support for 'user.css' (see bug #34389). No UI,
and open tasks for persisting selected sheets into the chrome registry, and,
I suppose, about namespaces ... but it works now.

see news://news.mozilla.org/390DDFBE.F7A247C2%40netscape.com for akkana's short
note on using it.
Just want to point out that the CSS 1 Recommendation uses an alternate 
stylesheet ('errata') to highlight changes from the first version. Would be 
very nice if this was being made available in Mozilla ...
Move to "Future" milestone.
Target Milestone: M20 → Future
Note that the Web Standards Project have been clamouring for an out-of-the-box
Alternate Stylesheets user interface for around 2 years now. Every browser they
have reviewed has been missing it, and each time they complained loudly.

Peter Linss did 90% of the work of supporting this, and in fact Viewer already
has a quick and dirty alternate stylesheets interface. David Baron has written 
a spec for this UI (see the URL field), which includes information on how to
implement this in Mozilla. I have written some comprehensive test cases for this
too, so testing behaviour once it is written is already possible.

Here are some resources for implementing this:
   http://www.people.fas.harvard.edu/~dbaron/css/ssui/
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt
   http://www.bath.ac.uk/%7Epy8ieh/internet/importtest/
   http://lxr.mozilla.org/seamonkey/ident?i=GetActiveAlternateStyleSheet
   http://lxr.mozilla.org/seamonkey/ident?i=SelectAlternateStyleSheet
   http://lxr.mozilla.org/seamonkey/ident?i=ListAlternateStyleSheets
   http://lxr.mozilla.org/seamonkey/ident?i=DispatchStyleMenu

It would be truly great if this could be done for FCS...

(BTW, just so that no one claims unfair play: Yes, the Web Standards Project 
"they" includes me, the reporter and at least one other person on the cc list).
Keywords: helpwanted
I might be able to work on author stylesheet switching.  The stylesheet 
switching code used by viewer isn't really that helpful -- I don't think you 
can access nsPresShell from JavaScript.  It should be possible using the DOM 
Stylesheets API, though.  Do we need to support frames?

I'd like to see a Style menu button on the toolbar (or status bar) with a 
visual indicator if there are styles available.  Forcing the user to check the 
View menu on every page doesn't make much sense.  Perhaps web developers will 
know it's there, but users won't if it's buried in a menu.  There are a lot of 
ways authors could use this feature if it was easily accessible.
| I'd like to see a Style menu button on the toolbar (or status bar)
| with a visual indicator if there are styles available.  Forcing the
| user to check the View menu on every page doesn't make
| much sense.

No, especially since almost no pages use alternate style sheets.

| Perhaps web developers will
| know it's there, but users won't if it's buried in a menu.  There
| are a lot of ways authors could use this feature if it was easily
| accessible.

Yup! As I mentioned earlier, it's even used in the CSS 1 Rec.
> No, especially since almost no pages use alternate style sheets.

This may be true for author stylesheets, but why shouldn't we ship multiple user
stylesheets when support is there?

Also IIRC the spec for this has a "no styles" option that would be very useful
on the toolbar on all pages.
>> No, especially since almost no pages use alternate style sheets.
> This may be true for author stylesheets, but why shouldn't we ship
> multiple user stylesheets when support is there?

We should! I didn't mean to imply that we should remove support for multiple user stylesheets. I just think that author stylesheets should be available from a toolbar/status bar too, not just the View menu. Only then will people start to *use* alternate author style sheets. Actually, I think there should be a button on this toolbar for user stylesheets too.
The above patch supports a checkbox menu under Use Stylesheet to choose among 
alternate author stylesheets (grouped by title), or a "None" option to turn off 
all optional styles.  It doesn't currently support frames.  

I suggest that whenever a page offers preferred or alternate stylesheets, 
a "Style" menu button will appear on the main navigation toolbar or statusbar 
to allow the user to easily switch between them.  On web pages that don't use 
it, it wouldn't be visible at all.  The patch can easily be reused to display a 
menu button on the toolbar.
Stealing the bug from Don. I'll try Tim's patch and see if it can be checked in 
for beta3.
Assignee: don → pierre
Target Milestone: Future → M18
The patch works fine but I think that the usefulness of the feature is greatly 
affected by the absence of a mechanism to remember which stylesheet was selected 
the last time the page was accessed. As a cheap alternatibe to the (IMO, overly 
complex) UI proposed by DBaron in the document above, we could store the 
currently selected stylesheet in the History along with the URL of the page. Note 
that there is a small drawback to any mechanism that implements the persistence 
of the stylesheet selection in the way that it implies a synchronous load of the 
stylesheet in question (see bug 17309 for a big bag of dead snakes on that 
topic).

Anyhow, thanks again Tim. I'll try to check that in.

*** Bug 45848 has been marked as a duplicate of this bug. ***
In bug 45848, fantasai@escape.com wrote:

<BLOCKQUOTE cite="news:3957E177.993BAC60@escape.com">
 <!-- 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.

Hello, I'm (pretending to be) an ordinary user, trying to use the currently 
suggested UI for style switching (David's design with German's modifications).

* I don't understand, from looking at the `View' menu or the toolbar, why there
  are *two* submenus/buttons for applying styles to pages. There should be just
  one. The toolbar button, when clicked, should produce exactly the same submenu
  as in the `View' menu.

  When the page has some extra styles for me to use, the toolbar button can glow
  brighter than it does if I just have Mozilla's ordinary styles to choose from.

* I don't know what a `style sheet' is. Applying `styles' I understand, `style
  sheets' I do not. Maybe `style sheets' are something those clever Web people
  use to make the styles work, but I don't need to know that.

  Therefore, the name of the submenu should be just `Use Style', and the name of
  any toolbar button should be just `Style'. (This is actually more accurate: a
  style may be in-line rather than in a style sheet, and a style can consist of
  two or more style sheets combined with the same TITLE).

* The main reason I'm going to use the `Style' menu is to override those
  horrible pages which use styles to make 7-pixel-high text in blue on black
  which I can't read.

* I want half a dozen nice styles shipped with Mozilla, so I can choose one
  depending on my mood.

* I don't understand any of that `Remember For' and `Disable Until' stuff. If I
  choose one of the page's styles (a preferred/alternate style), it should keep
  applying until I visit another site (i.e. go to a page where that style is not
  an option). If I choose one of Mozilla's own styles (a user style), it should
  keep applying until I turn it off or choose another style.

  Of course, for as long as Mozilla remembers that I've been to a page (as
  long as that page is in the history), if I used an author style for that page
  (not a user style) then Mozilla should remember which one.

* I can specify my own fonts and colors in that 'orrible Prefs dialog. But they
  should be overridden by a style, whether or not it's one of my own or one from
  the site -- *unless* I check the boxes saying `Always use my fonts' or `Always
  use my colors' or whatever.

So ...

View > Use Style submenu
------------------------
  _0 My Preferences              [html.css + user.css + fonts/colors from prefs]
* _0 {preferred visual style}    [name `Page Style', if page has no style sheets]
  _0 {alternate visual style}    [And yes, the fact that all these items use ...]
  _0 {alternate visual style}    [... `0' as their mnemonic is intentional.]
  ...
-------------------------------
  _1 Impressionist               [Times; Trebuchet; pale blue, purple, gray]
  _2 Junior                      [Souvenir; Maiandra, Comic Sans; yellow, orange]
  _3 Modern                      [Lucida Sans, Verdana; white, black, navy]
  _4 Nocturnal                   [Palatino; Univers, Helv.; black, white, yellow]
  _5 Oriental                    [Tahoma; Hiroshige, Times; pale pink, brown]
  _6 Renaissance                 [Georgia, Palatino, Garamond; cream, burgundy]
-------------------------------
/ Allow Pages to Adjust Styles   [turns persistent styles on/off]
  Customize Styles ...           [opens Styles panel of prefs dialog]

... Comments?

(I think Fantasai's idea is too complicated to be useful, BTW.)

That proposal seems to remove two important features:
 * the ability to turn off all preferred/alternate styles
 * the ability to turn off all author styles

It should also be possible to select user stylesheets and author stylesheets
independently -- it's possible to have both at the same time, or neither.

In other words, I think that proposal makes the interaction between the upper
half of the menu and the lower half very unclear (either that or it requires
that it be made incorrect in the style system).
I would also like Mozilla to support more than one user stylesheet. I *love* 
the user stylesheet feature in Opera,  but it's annoying to have to enter the 
preferences each time I want to change it (one user stylesheets may work good 
on a certain page, while another stylesheet will work better for a different 
page). Multiple user stylesheets would be a very nice feature (perhaps using 
check boxes?).
> * the ability to turn off all preferred/alternate styles



You could do this either by selecting `My Preferences', or by selecting any of 

Mozilla's own styles.



> * the ability to turn off all author styles



The same as above, with the addition of unchecking `Allow Pages to Adjust Styles' 

(to turn off persistent styles as well).



Karl: The items numbered 1 to 6 in the menu *are* user style sheets, accessed 

from a menu so you don't have to go into the prefs.


But how do you apply both a user stylesheet and an author preferred/alternate
stylesheet at the same time?
Matthew Thomas wrote:
>(I think Fantasai's idea is too complicated to be useful, BTW.)

Are you referring to the post I'm quoting from or to the comments pasted in 
here? I can understand if you think the post is too complicated but the comments 
don't seem that arcane.

If Mozilla is implementing multiple user stylesheets, why not do this with the 
<link> tag? The capability to parse and make sense of <link>ed stylesheets is 
already there for the author styles, right? And if the file that holds these 
styles is written to such a well-known standard as HTML (instead of hard-coded 
into the XUL), then "advanced users" can go find the file and edit it.

On the other hand, we can make this elitist and have only those familiar with 
XUL able to edit the user styles.

David Baron wrote:
> It should also be possible to select user stylesheets and author stylesheets
> independently -- it's possible to have both at the same time, or neither.

The top and bottom halves of the Use Style submenu should radio independently.
And both should have 'none' or its equivalent as an option listed at the top.

 View > Use Style
 ----------------
 . None
 / Page Defined Style       [replaced by preferred stylesheet, if available]
 . {alternate 1}
 . {alternate 2}
------------------------
 / My Preferences
 . Impressionist
 . Junior
 . Modern
-----------------------
/ Allow Page's Styles to Override Mine  [or something to that extent]
  Customize Styles...

The second to last option is pulled from that post; I haven't filed an RFE for 
it yet. You can probably ignore it.

(Define the mnemonics however you like.)


Matthew Thomas wrote:
> [... `0' as their mnemonic is intentional.]

I was under the impression that two items under the same menu can't have the 
same mnemonic...

> / Allow Pages to Adjust Styles   [turns persistent styles on/off]

Tsk. I thought the user didn't have to know what the difference between 
persistent and alternate styles were.

They should not be thought of as independent of the alternate stylesheets, 
anyway, as they're just added on to the chosen alternate set and become part of 
the page's styles.


So, where do non-CSS presentational hints fit in here? Are they turned off with 
the persistent styles or what?
> But how do you apply both a user stylesheet and an author preferred/alternate
> stylesheet at the same time?

You don't. Such a feature would be of negligible value, and if you provide it at 
the GUI level, I (the ordinary user) won't have a snowball's chance of working 
out how this `Style' thing works. Sorry.

> If Mozilla is implementing multiple user stylesheets, why not do this with the
> <link> tag?

Because there's another way which is much simpler. In prefs, allow the user to 
specify a folder which contains their selection of user styles. Then the user can 
use their favorite file manager to arrange style sheets, and/or shortcuts to 
style sheets, and/or Internet shortcuts to style sheets, in this folder. Or they 
could even specify an FTP directory instead of a local folder
(<ftp://ftp.w3.org/pub/style/core/>, anyone?).

> On the other hand, we can make this elitist and have only those familiar with 
> XUL able to edit the user styles.

Or we could make it elitist and have only those familiar with HTML able to edit 
the user styles ... Or we could just make it easy. :-)

> I was under the impression that two items under the same menu can't have the
> same mnemonic...

If it's actually impossible to do this in XPToolkit, then that's a bug. Multiple 
items with the same mnemonic should behave just the same as on Windows: pressing 
`0' cycles through `My Preferences' and the author styles, and pressing Enter 
confirms the choice. You need this to happen, in order to maintain consistent 
mnemonics for the user styles (because the selection of author styles change with 
every site, whereas the selection of user styles only change with rare user 
effort).

> > / Allow Pages to Adjust Styles   [turns persistent styles on/off]
>
> Tsk. I thought the user didn't have to know what the difference between 
> persistent and alternate styles were.

Ok, sorry, I inferred the wrong thing from David's notes. I've gone over the 
relevant sections of the HTML spec and the WAI UAAGs, and neither of them say 
that persistent styles should be independent from author/user styles. So we can 
remove that item, then.

> So, where do non-CSS presentational hints fit in here? Are they turned off with 
> the persistent styles or what?

We operate under the assumption (as implied by the deprecatedness of most non-CSS 
presentational hints in HTML 4.0x, and by the suggested complete absence of such 
hints in XML), that non-style-sheet presentational hints will eventually cease to 
be exist. So to avoid confusion, our style UI should work in the same way when 
they cease to exist, as it does while they do.

Therefore, when the user chooses `My Preferences', non-CSS presentational hints 
are still applied -- except where the user has turned custom
fonts/colors/whatever off in preferences. Later (5 years from now), we can turn 
support for custom fonts/colors/whatever off by default (thus rewarding those 
authors who are using style sheets instead); later still (10 years from now), we 
can drop support for non-style-sheet presentational formatting altogether.

> > But how do you apply both a user stylesheet and an author
> > preferred/alternate stylesheet at the same time?
>
> You don't. Such a feature would be of negligible value, and if you provide it
> at the GUI level, I (the ordinary user) won't have a snowball's chance of
> working out how this `Style' thing works. Sorry.

It's the whole foundation of CSS cascading.  The user can have preferences,
expressed in a user stylesheet, and the author can override those preferences
necessary for the presentation of the document.  If we don't allow that, we
shouldn't do anything.  See http://www.people.fas.harvard.edu/~dbaron/css/user/

How about naming the menus "Default Style" and "Page Style" (or maybe just
"Style", or maybe "Current Style")?  I think users can understand the concept of
a default that is sometimes overridden.  At least I hope so.
Matthew Thomas wrote:
>> But how do you apply both a user stylesheet and an author preferred/alternate
>> stylesheet at the same time?
>
>You don't. Such a feature would be of negligible value,

Really? Now, supposing I didn't want an XML document's choice of 
backgrounds/colors. I disable their stylesheet to get rid of them, since I 
evidently cannot have an !important rule cascade into the document. And now, I 
have a wonderfully structured document whose structure is no longer evident, 
because I disabled all text styles, all margins, indentation, and most 
importantly, the DISPLAY property.

Rather odd, IMO, for the CSS2 spec to describe the user/author stylesheet 
interaction in such detail when it's only a /feature/.

Anyway, you've neatly resolved bug 43220. All that has to be done is mark it 
WONTFIX; there's no reason to fix the user/author stylesheet interaction if 
there won't be any.

>                                                         and if you provide it 
> at the GUI level, I (the ordinary user) won't have a snowball's chance of 
> working out how this `Style' thing works. Sorry.

Didn't think the menu layout was that confusing... Well, you're the expert.


> In prefs, allow the user to specify a folder which contains their selection of 
> user styles.

Personally, I'd rather have <link>s with a GUI, but I guess there isn't time. A 
directory works well enough, though. Now, what's the convention for titling 
these stylesheets? A comment in the first line?


>Multiple items with the same mnemonic...

Thanks for the enlightenment. m(_)m I'll keep that in mind. 


>Therefore, when the user chooses `My Preferences', non-CSS presentational hints 
>are still applied -- except where the user has turned custom
>fonts/colors/whatever off in preferences. 

I didn't know there was a preference for turning off table widths.
I don't see anything complicated about this structure...
Use Style >
 . None
 . Only Required
 / Author Preferred Style
 . Author Alternate Style #1
 . Author Alternate Style #2
----------------------------
   Also Add My Style:
 . None
 / Black and White
 . No Advertisements
   Customize My Styles...

I'm not sure what the most understandable labels are for No Author Styles 
(None) vs. Just Persistent Author Styles (Only Required).

Obviously unless they know CSS, most users aren't going to understand the 
intricacies of user stylesheets.  There would need to be a fancy utility 
under "Customize My Styles..." that allows beginning users to configure a 
limited set of properties, as well as allowing advanced users to specify the 
exact CSS they want.  Since that's probably not going to happen soon, there 
would need to be some nice default styles.
Argh, I have so much egg on my face, I can't see ... :-)



Right. So the incremental assembly of a complete style goes like this, correct?

  UA basic style (e.g. html.css)

+ user style (e.g. Renaissance)

+ author non-CSS presentational formatting

+ author preferred/alternate style (e.g. Forest)

+ author !important style

+ user !important style.



Questions:

* Where does persistent author style go in that list? Before or after author

  preferred/alternate style? Somewhere else?

* Where should do font/color/etc prefs go in this list? Just after html.css? As a

  (minimal) replacement user style? Somewhere else?

* Where should `Always use my {xyz}' prefs go in this list? After everything?



> A directory works well enough, though. Now, what's the convention for titling

> these stylesheets? A comment in the first line?



A little thing called a `filename'. (I suppose now you're going to complain that 

using a filename means you can't assemble a user style from multiple style sheet 

files like you can with an author style, and then I really *am* going to say 

`tough' and tell you to go @import yourself.)


There is no distinction in the cascade between persistent and
preferred/alternate stylesheets.

I would think that maybe prefs should be at the beginning of the user-stylesheet
(same level of the cascade), and always-use-my prefs should be too, but as
!important rules.  But it wouldn't be much of a difference if they were at a
different level, and this probably needs to be verified by experiment rather
than theory.
Ok, how about this.
* Font/color/etc prefs are an easy way of making up a basic user style sheet
  known as `My Preferences'. All other user style sheets are actual files, and
  exist (or are linked to) in the style sheet directory specified in prefs.
* `Always use my {whatever}' prefs are equivalent to !important in any user
  style sheet which is applied -- whether that be `My Preferences', or any
  other.

And since user styles apply first, with author styles overriding them (or not), 
I think we should reflect that in the order of the menu items by listing the 
user styles first. (This has the added bonus of making the position of the menu 
items more stable overall.)

So ...

View > Use Style submenu
------------------------
* _0 My Preferences
  _1 Impressionist
  _2 Junior
  _3 Modern
  _4 Nocturnal
  _5 Oriental
  _6 Renaissance
------------------------------
  _Ignore Styles in Document
* {preferred author style}      [`Use Document's Style', if no title/sheets]
  {alternate author style}
  {alternate author style}
  ...
------------------------------
  C_ustomize Styles ...         [opens Styles panel of prefs dialog]

Is that better?
Keywords: nsbeta3, patch
QA Contact: mpt
I don't like the "My Preferences" thing.  IMO, preferences should apply all the
time.  If they don't apply when another user stylesheet is chosen, that's
confusing to the user.
But if font/color preferences apply no matter which user style sheet is chosen, 
then the user style sheet menu options will have almost *no* noticable effect 
(because both fonts and colors in them would be overridden by the prefs
--leaving only minor things like margins, borders, and heading alignment). And 
that would be even more confusing, wouldn't it? A bunch of menu items which 
didn't seem to do anything, even when there were no author styles specified ...

If the user wants their font/color prefs to always apply, regardless of the 
user style sheet, they tick the `Always use my {fonts|colors}' checkboxes in 
prefs.
The user stylesheet, if present, would override the preferences (unless the
preferences had "Always use my...", in which case either only !important rules
or nothing at all in the user stylesheet would override the preferences). 
However, the only things in the prefs that can be truly overridden by a user
stylesheet are the colors.  The fonts in the prefs are choosing the default
meanings of 'serif' and 'monospace'.

So I think it would be misleading to label the 'None' option as 'My Prefs'. 
That would give the impression that choosing a user stylesheet turns off
preferences.  Yes, a user stylesheet would, in many (but not all) cases,
override the colors.  In some cases it could be badly designed and set a new
font size, too (but that preference would be overridden by authors using the
prefs as the base).
The values expressed in a user style sheet *are* preferences. It seems simply
wrong-headed to have a set of font/color preferences outside the scope of the
user style system.

Isn't the right way to do this is to make the styles that can be modified
through preferences into just another user style sheet?

Is it OK if that "just another user stylesheet" is not actually written as a
user-stylesheet, but is constructed dynamically and cascaded as if it was the
first of the user stylesheets?  (This is what I was proposing, or almost,
depending on which option you took of the ones I left open.)
Why do we need more than one user stylesheet in a given cascade? Is this just to
accommodate the fact that these prefs aren't writing themselves to disc as CSS
syntax?

Do you think the solution you're proposing will scale well to a situation where
the user styles can be configured via the prefs UI? I'm not so sure, but I think
that's definitely the direction Mozilla ought to be heading. In such a
situation, we wouldn't want to have a set of stylistic preferences which worked
"a little differently".

I agree that font/color preferences should act just like any other user style 
sheet. Ideally they should be written as a CSS file too, so that I can hack at 
user.css using methods other than the prefs dialog. (Maybe one day Mozilla will 
offer a GUI for editing user style sheets other than the one known as `My 
Preferences'.)

However, where the user specifies a user style sheet in the `Use Style' menu 
which is not `My Preferences', *if* that style sheet does not specify
fonts/colors by itself, *then* the fonts/colors specified in prefs should still 
be used.

So here's the cascade:
style
= UA basic style (e.g. html.css)
+ font/color prefs (e.g. prefs.js)
+ user style from menu (e.g. Renaissance) (unless `My Preferences' is selected)
+ author non-CSS presentational formatting (unless `Ignore Styles in Document' is
  selected)
+ author preferred/alternate style (e.g. Forest) (unless `Ignore Styles in
  Document' is selected)
+ author !important style (unless `Ignore Styles in Document' is selected)
+ user !important style (e.g. !important rules in `Renaissance')
+ `Always use my {fonts|colors|...}' prefs.

Tim Hill wrote:
> I'm not sure what the most understandable labels are for No Author Styles 
> (None) vs. Just Persistent Author Styles (Only Required).

That's a non-issue; persistent styles become part of the alternate sets. (The 
preferred stylesheet would just be the default selected alternate set.) If there 
are no alternate sets defined as such, the persistent style should form its own 
set. (It joins a non-existent preferred stylesheet set.) But it needs a name.
We have:
  - Page Style
  - Page-Defined Style
  - Use Document Style
Any preferences? Any other suggestions? 

BTW, I'm not sure how well 'Use Document's Style' would sit, since it is 
possible to have alternate sets but no preferred set; the alternates are 
Document Styles, too.


Matthew-- Minor point: I think 'Ignore Styles in Document' gets the idea across 
very well, but it breaks the parallel structure. Would it be possible to use 
something like 'No Document Style', or is that unclear?


Matthew Thomas wrote:
> A little thing called a `filename'. (I suppose now you're going to complain
> that using a filename means you can't assemble a user style from multiple 
> style sheet files like you can with an author style, and then I really *am* 
> going to say `tough' and tell you to go @import yourself.)

Just wondering where you got your menu there--I don't see "junior.css" listed 
anywhere.


> And since user styles apply first, with author styles overriding them (or 
> not), I think we should reflect that in the order of the menu items by listing 
> the user styles first. (This has the added bonus of making the position of the 
> menu items more stable overall.)

They may apply first, but author styles usually come out "on top", so to speak.
Also, putting the author styles at the top of the list makes their availability 
more evident.


David Baron wrote:
> The fonts in the prefs are choosing the default meanings of 'serif' and 
'monospace'.

They also choose whether the default is "font-family: serif" or "font-family: 
sans-serif", which can be expressed as a CSS rule in a user stylesheet.

However, it is true that the prefs are choosing some defaults that are not 
equivalent to any stylesheet; they set what 'serif', 'monospace', and 
'sans-serif' are defined as; they also define the size that corresponds to 
font-size's 'medium' keyword.

So, that the visual preferences should be expressed as a CSS file is both right 
and wrong.

I think a little rearrangement of the wording in the prefs would help:

   O Allow web pages to override my (color, font, whatever) settings

/Now/ with override selected, the user stylesheets can bypass the preferences, 
because the user stylesheet is not a page stylesheet. The definition of the 
keywords will remain in the prefs file, and the default selection (:root 
{font-family: sans-serif}, :link {color: blue}) can be expressed as a stylesheet 
equivalent to all the other user stylesheets--without fussing with "always use 
my colors" overrides.

A problem: If a user stylesheet does not define the link colors, what do they 
default to? The preferences or html.css? (Note that the colors are _already_ 
defined in html.css)

I think background will "inherit" from the chrome if necessary (transparent), 
but what happens to color? Would it be better to intitialize both as 'Window' 
and 'WindowText'?


One more thing-- Are we using the word 'Document' or 'Page' here?
Ok, change `Ignore Styles in Document' to `Ignore Document's Style'. By 
`Document's Style' we mean the style which the document wants us to use -- that 
is, the preferred style. If there is persistent style specified but not a 
preferred style, the persistent style by itself is regarded as the `Document's 
Style'.

So we have
|
|   _Ignore Document's Style  [always present]
| * Use _Document's Style     [present if preferred OR persistent style supplied]
|   {alternative styles}      [present if alternative styles supplied]

If neither preferred style nor persistent style are specified, the `Use 
Document's Style' item is removed, and `Ignore Document's Style' is selected.

> Just wondering where you got your menu there--I don't see "junior.css" listed
> anywhere.

Dummy values, but representing a default collection of styles I'll cook up some 
time in the near future. On my to-do list. (And the file will be called `Junior', 
not `junior.css'.)

> author styles usually come out "on top", so to speak.

Figure of speech. I think putting them at the end makes it clearer that the 
author styles (usually) override the user styles.

> Also, putting the author styles at the top of the list makes their availability
> more evident.

Once you've opened the menu, your attention is going to be drawn more by the 
changed length of the menu than by anything else. You're naturally going to look 
at the bottom, because that's the end of the menu which has moved since last time 
the menu was opened.

> So, that the visual preferences should be expressed as a CSS file is both right
> and wrong ... I think a little rearrangement of the wording in the prefs would
> help:

See <http://critique.net.nz/project/mozilla/prefs/tardis/#std-display-fonts> and 
the highly-doomed bug 28899. (Tim?:-)

> If a user stylesheet does not define the link colors, what do they
> default to? The preferences or html.css?

Preferences. (See the cascade I posted above.) Fonts and colors specified in 
html.css are (it would seem to me) only for emergencies where prefs are 
unavailable.

> One more thing-- Are we using the word 'Document' or 'Page' here?

`Document'. It's a bit silly to refer to a locally stored XML file (for example) 
as a `page'.

Matthew Thomas wrote:
 | Ok, change `Ignore Styles in Document' to `Ignore Document's Style'. By 
 | `Document's Style' we mean the style which the document wants us to use--that 
 | is, the preferred style. If there is persistent style specified but not a 
 | preferred style, the persistent style by itself is regarded as the 
 | `Document's Style'.
 | 
 | So we have
 | |
 | |   _Ignore Document's Style  [always present]
 | | * Use _Document's Style     [present if preferred OR persistent style 
                                  supplied]
 | |   {alternative styles}      [present if alternative styles supplied]

Just a minute-- Why is "Use Document's Style" present when a preferred 
stylesheet is given? The preferred stylesheet has a title of its own.

We have this right now:

  . Ignore Document's Style
  / Use Document's Style
  . Forest
  . Plain
  . Ultramarine
  . Steely

The menu here is a bit off-balance in terms of grammatical constructs. (top two 
vs. the rest) Will 'No Document Style' and 'Document's Style' do or must we use 
a verb for those?

 | If neither preferred style nor persistent style are specified, the `Use 
 | Document's Style' item is removed, and `Ignore Document's Style' is selected.

Now /that's/ misleading. How can you ignore something that doesn't exist?

BTW, are you saying that non-CSS presentational hints can't be turned off? That 
is, IMO, unfair to the user. Why should they have to go into the *preferences 
dialog* to turn off the background for such a site? And be forced to uncheck 
that box after they're done? That also makes authors using deprecated HTML more 
powerful than those using XML and/or CSS. You also should take into account that 
you cannot turn off table widths, alignment, vspace (<img>), borders (tables & 
objects) in the Preferences while this is possible by ignoring (or overriding) a 
stylesheet. An author who doesn't want a user to accidentally turn off floats 
and alignment may continue to use presentational markup because it won't be 
disabled with his/her stylesheets.

I think that for this purpose, non-stylesheet presentational hints should be 
treated as part of the persistent styles--and turned off with the rest of the 
styles.

(Of course, the above doesn't apply for XML (besides XHTML).)


 | Dummy values, but representing a default collection of styles I'll cook up 
 | some  time in the near future. On my to-do list. (And the file will be called 
 | `Junior', not `junior.css'.)

Mozilla is able to detect what language a file is written in without an 
extension and /without a MIME-type/? I'm impressed. I also think that function 
is bloat and a waste of time, but whatever...


 | > author styles usually come out "on top", so to speak.
 | 
 | Figure of speech. I think putting them at the end makes it clearer that the 
 | author styles (usually) override the user styles.

Supposing I have a stack of transparencies on my desk consisting of various 
bulleted lists, diagrams, etc. Which diagram will be the most evident: the one 
on the top, or the one on the bottom?

It works the same for paper, for pastry sheets, for piles of junk
Quite a solid figure of speech, no?

It also works the same for /mail filters/.
Users don't care which is applied first--they care which has precedence. And in 
mail filters, the higher filters have precedence.

 | > Also, putting the author styles at the top of the list makes their 
 | > availability more evident.
 | 
 | Once you've opened the menu, your attention is going to be drawn more by the 
 | changed length of the menu than by anything else. You're naturally going to 
 | look at the bottom, because that's the end of the menu which has moved since 
 | last time the menu was opened.

And if the last time the menu opened was two weeks ago, will you remember it's 
exact length? Even an hour is more than sufficient for me to forget how many 
items there were on such and such a submenu. 
Two other things to consider: several sites may have the same number of 
alternate styles available, and a site may add only one alternate style--a 
difference of one item is hard to detect even if you go from one site straight 
to the other.

Your eye is usually drawn first to the part of the submenu that appears next to 
the >, which is the top unless there's no room left. Go open some submenus--do 
you see the hanging end first, or the item next to your cursor?

 | > If a user stylesheet does not define the link colors, what do they
 | > default to? The preferences or html.css?
 | 
 | Preferences. (See the cascade I posted above.) Fonts and colors specified in 
 | html.css are (it would seem to me) only for emergencies where prefs are 
 | unavailable.

You contradicted yourself:
	>I agree that font/color preferences should act just like any other 
	 user style sheet.
	>...*if* that style sheet does not specify fonts/colors by itself, 
	 *then* the fonts/colors specified in prefs should still be used.

So, are the preferences expressed as a sort of "persistent user stylesheet", 
with all the others as alternates? (This is why I wanted the user styles as 
<link>s--you don't have to hard-code this behavior into Mozilla.)
>Mozilla is able to detect what language a file is
> written in without an 
> extension and /without a MIME-type/?
> I'm impressed. I also think that function 
> is bloat and a waste of time, but whatever...

Yes. Having these files use the extension '.css' has one advantage. It's 
easier/faster to edit them if you have a CSS editor (or a simple text 
editor) "linked" to the '.css' file extension. I see no advantage of omitting 
the '.css' extension.
Actually, can't @font-face be used to define the meaning of the generic family
names?

Folks, it looks like you are trying to come up with a UI that will expose the
full flexibility of user style sheets. Please don't. It's more important that we
get something usable that works within the cascade model rather than something
that exploits the cascade model in every way possible. I'd like to propose some
constraints:

* A single "accessibility" user style list is used only for !important styles.
* In a given cascade, the user style sheet comprises two user style lists: the
accessiblity list and a list of non-!important styles. The latter @imports the
former.
* Some user stylesheet will always be applied (it could be empty). ("My
Preferences" is not a good name for it. Of course it's mine! How about
"Default"?)

These constraints assume that if a style is !important, it's probably !important
all the time. Importantly (ahem... sorry), they accommodate an "Accessibility"
panel in the preferences where the !important overrides can be set.

(And non-CSS presentational hints should indeed be overridable by a user
stylesheet. Remember these hints are effectively just styles prepended to the
author style sheet with zero specificity.)
> Actually, can't @font-face be used to define the meaning
> of the generic family names?

Yes, it can -- in theory. But Mozilla doesn't currently support this, so no ... :(
I'd like to apologize for various sarcastic comments in this discussion. I 
really am sorry to have written them. I do try to think before I speak--I've 
spent hours on each reply, but even that amount of time doesn't seem to 
guarantee "clarity of thought before rashness of action". (Yes, even Bugzilla 
chastises me for my lack of courtesy.) 
So I beg your pardon.

My point in posting is to request that this bug be split--that this one's 
summary be changed to "[RFE] UI for alternate author stylesheets", and bug 
45848, "RFE: alternate user stylesheets", be reopened for discussion on the 
implementation, both UI and exact storage format, of the user styles. If 
necessary, another bug might be created, marked as dependent on these two, for 
the overall 'Use Style' submenu. It might also be a good idea to cross-post a 
summary of the alternate user style discussion in here to n.p.m.style and 
n.p.m.ui (and perhaps also to n.p.m.layout) for ideas from others who might be 
interested but are currently uninvolved. I'll try to write up such a summary 
ASAP and attach it here for review before doing anything.

    
    

    
  
All comments, criticisms, suggestions, and objections about the impartiality, or 
lack thereof, and accuracy of the summary are welcome; please email them. I will 
make any changes necessary, but the deadline for notifying me is 12:00am EST, 
August 1, 2000; otherwise, you'll have to revise it yourself.

    
    

    
  
(Disclaimer: My main concern is that this goes in. The actual UI used is, from
my point of view, secondary to the goal. Having said that, here are some ideas:)

The 'none' equivalent for the user styles section could be called "Defaults" or
"Only Preferences".

If we use a stylesheet folder for holding the alternate user stylesheets (which
is a lot easier than a file with <link> elements) then we can easily have the
.css extension and hide the extension in the menu. That's no big deal.


>  o If no colors (background, text, links, etc.) or font face is
>    specified by a user stylesheet, it should default to those selected
>    in the preferences.
>      - This implies that the preferences are not equivalent to the
>        other user styles (which behave as alternate styles), but 
>        behave as persistent styles.

This is incorrect, in CSS terms. The preferences should just be equivalent to
a user stylesheet that comes before any other user stylesheet. Also, there is
no such thing as persistent or alternate stylesheets in user styles.

If the "Only use my colours" checkbox is checked, then the preferences should
be given a weight equivalent to the CSS '!important'.

And now, back to your regularly scheduled arguments. :-)

    
    

    
  


  

    
    

    
  
Adding [fix in hand] in the summary line, acknowledging that Tim's patch doesn't 
cover the whole issue.

Status: NEW → ASSIGNED
Summary: [RFE] UI for alternate and user stylesheets → [fix in hand][RFE] UI for alternate and user stylesheets
Whiteboard: [fix in hand]

    
    

    
  


  

    
    

    
  


  

    
    

    
  
I've added summary of alternate author styles discussion to version 2; let me 
know if I missed something (the .1 is for forgetting the History). Again, I can 
only fix it if I'm notified before August 1st.

I think it would be best if this was resolved soon (wordings excepted) so 
there'll be something definitive to work off of.

I want to remove the second cascading option (prefs get complete override, are 
not expressed as !important rules) from the summary on Monday night, as I don't 
see any objections to the first. If you don't agree, speak up! Otherwise you'll 
have to copy it back in yourself.

Of course, all who dissent with /anything/ in the summary should say so, 
*especially as I've added a few details not in this discussion*.

My thoughts:

  1. We should use "Document" only if the rest of the UI can be persuaded to 
     change.
  2. I think the author styles section should go on top, for reasons mentioned
     above.
  3. I'll go with 'Preferences Only' for the user styles' "none"
  4. I back 'No Document Style' or 'No Page Style' for the author styles' 
     "none", but then, I may be more sensitive than most to grammar errors.
  5. I prefer 'Page-Defined Style' over 'Document's Style' because the 
     alternates are also styles belonging to the document/page; but unlike 
     the preferred/persistent styles, they aren't defined in the document 
     as the style to be used.
  6. Prefs override should be equivalent to other user styles' !important, (and 
     that prefs dialog wording needs to be changed).

Theoretically, how would the UI for frames' styles be handled? The frameset 
doesn't really need a style, but the frames themselves might.

    
    

    
  


  

    
    

    
  
What is the state of the patch? Has it been tested by others? Please advise so 
we can determine if this bug is ready for nsbeta3 approval (like other concerned 
citizens, I'd love to see this in the product, however I am afraid to take on 
too much risk).

    
    

    
  
Tested patch with Mozilla nightly build (id:2000072808) on Windows 2000.

I tried all the pages listed here (including the spec link), and also some old 
pages of mine using alternate stylesheets to change the font. The alternate 
style work wonderfully. 

The "none" option only disables alternate & preferred styles; it doesn't affect 
persistent styles. It's equivalent to the "Minimal Page Style" described in the 
summary. I think the item name should reflect the fact that it means 'no 
alternate/preferred style', though, and not 'no style'

There is no distinguishing between media types; I was able to choose Ian 
Hickson's printer styles.

Sometimes the whole list of alternates doesn't load; this happens when you open 
the menu before the whole page has finished loading. Reloading fixes the 
problem.

But.. those alternate styles are /cool/. >:)

    
    

    
  
> There is no distinguishing between media types; I was able to choose Ian
> Hickson's printer styles.

Do we want to do anything about that right now? If printing automatically uses 
the printer style, then maybe we do. But if the print dialog doesn't allow us to 
choose which style (of multiple printer styles available) is used for printing, 
then maybe we don't.


    
    

    
  
Fantasai: Could you run through the entire Import Test with your patch?
   http://www.bath.ac.uk/%7Epy8ieh/internet/importtest/

Or alternatively (no pun intended), mail me the patched files (ianh@netscape.com)
and I'll do it after nsbeta2 ships.
Keywords: correctness
Whiteboard: [fix in hand] → [fix in hand] hit during nsbeta2 standards compliance testing

    
    

    
  
Crash-tested Mozilla at 3am. AFAICT, there's no problem with the alternate style 
UI. Just with other stuff. (Now I know why they're called Evil Tests =)
Let me know if you didn't get the comments.

BTW, Tim's patch is very easy to use. You just copy the code right into the 
files and get rid of the +s with the down arrow and [delete]. The hardest part 
is finding the files; after that, it only took three minutes to fix.

    
    

    
  


  

    
    

    
  
[nsbeta3+]. Easy fix, in hand, contributed from the net.
Whiteboard: [fix in hand] hit during nsbeta2 standards compliance testing → [nsbeta3+][fix in hand] hit during nsbeta2 standards compliance testing

    
    

    
  
> There is no distinguishing between media types; I was able to choose Ian
> Hickson's printer styles.

That's fine -- so logn as we don't _apply_ the style then we're ok.

i.e., if there is a style called "a" for screen and a style called "b" for
print, then it is fine to always offer "a" and "b", so long as "b" has no
effect when on screen and "a" has no effect on the printer.

Do we have an r= for this patch?
Keywords: review

    
    

    
  
Partial fix checked in:
navigator.dtd
navigator.js
navigatorOverlay.xul
Thanks to Tim Hill <tim@prismelite.com>

Moving to Future now...

Keywords: correctness, 
          
            nsbeta3, 
          
            patch, 
          
            review
Summary: [fix in hand][RFE] UI for alternate and user stylesheets → [RFE] UI for alternate and user stylesheets
Whiteboard: [nsbeta3+][fix in hand] hit during nsbeta2 standards compliance testing
Target Milestone: M18 → Future

    
    

    
  
I've reported two bugs related to stylesheet switching (as far as I can tell, 
they are not specifically related to my UI patch):
- Bug 47734 (DOM StyleSheets collection inaccurate if retrieved during page 
load)
- Bug 47736 (Switching stylesheets leaves some styles behind)

My patch doesn't specifically check the media types.  I briefly tested this, and 
even though it appears selected in the UI, it ignores the stylesheet if the 
media type does not apply (which is correct behavior according to the DOM 
StyleSheets API used by the patch).
Summary: [RFE] UI for alternate and user stylesheets → [RFE] UI for alternate and user stylesheets [IMPORT]

    
    

    
  
Using the nightly build 2000090308: Switching styles doesn't work any more. I 
think in the Aug 26 build it was working correctly. Now only the menu appears 
with the available alternate stylesheets, but whenever you click on an item, the 
menu dismisses but the alternate stylesheet is not selected.

    
    

    
  
I've noticed this intermittently as well.  It goes away on mouse down rather 
than on a click.  Try this: when selecting the menu item, mouse down on 
the "View" menu, and without letting go of the mouse button, drag it to the Use 
Stylesheet menu and select a stylesheet, and then release the mouse button.  
Or, highlight the item with the keyboard and press Enter to select it.  It 
always works these two ways for me.  As far as I can tell, it's an XP menu bug.

    
    

    
  
Using 2000-09-01-21/Linux I get rather funny results

a) http://www.people.fas.harvard.edu/~dbaron/css/ssui/
I get only "None" and "Oldstyle", I would expect that there are additionally:
"Forest", "Plain", "Ultramarine", "Steely".
But I can use the mouse to toggle between "None" and "Oldstyle" (without tricks).

b) http://www.webstandards.org/css/opera/altstyledemo.html
I get "None", "Default blue scheme", "Alternative green schema" and "Contrasting
colours", but only "Contrasting colours" works partly (The header is WRONG not
black on white but as with 'blue' it is yellow on blue. The checkmark is besides
both 'contrasting' and 'blue'. "None" and 'green' both direct to 'blue'.

c) http://www.physik.fu-berlin.de/~fsi/en/
This (my) page: I get "None" and a stylesheet but selecting doesn't work.

d) If a page only contains a stylesheet, but without a title="foo" no additional
menu appears. There should be one item linke "Author's style", i.e. it is
possible to switch this style on and off.

    
    

    
  
It is going to get funny, with 2000-09-05-08:
b,c: the same.
a: now shows all items, but only the last "steely" works (100% or 80% I don't
know). All other items default to "Oldstyle". Using "Steely" a checkmark appears
besides it and Oldstyle. All other items only cause a checkmark besides "Oldstyle".

    
    

    
  
Looks like BlakeR1234 somehow moved a single brace character in an unrelated 
checkin (navigator.js 1.210) which basically hoses the stylesheet switching 
logic.  Can you check this simple fix in Blake?

    
    

    
  
Sorry about that.  Fix checked in.

    
    

    
  
With 2000-09-06-06/Linux everything works as expected, but:

a) If you go to View|Use Stylesheet before the document has finished loading,
only a subset of items is shown (and the list not completed later, you may need
to have a slow line to test this).

b) Go to http://www.physik.fu-berlin.de/~fsi/index_en.html,
choose "W3-Ultramarine" and then "None", note that some elements become a very
light grey instead of black (actually all text but the hyperlinks).

c) It is still not possible to choose "None" on pages with CSS which doesn't use
title="foo" (or only uses inline styles, see d). There should be a 'Authors
style' (use another entry name if you want) in this case.
(try for instance: http://www.teamone.de/selfhtml/)

d) The item 'None' only disables the external stylesheets, if you declare the
style in the html file, it still is shown, try e.g.
http://www.physik.fu-berlin.de/~fsi/statistik.html#tab1
Some table rows are grey (using class in tr), this stays that way if you choose
"None" which is not the right thing according to the spec.(Especially since
there is no other way to disable the stylesheets.)

Moreover: If you navigate around on a site which uses alternate stylesheets, you
will miss:
- That history saves the last used stylesheet of a page
- That Reload (not shift reload) keeps using the default stylesheet instead of
the last selected.
- Some way to store the choosen value, i.e. if a site offers a selection of
stylesheets, the selection shouldn't be reset if you just click on to another
page (which offers exactly the same styles located in the very same file)
You may try the URL mentioned in (b), choose a non-default style and navigatate
around, if you are not yet convinced.

    
    

    
  
a. Bug 47734 (DOM StyleSheets collection inaccurate if retrieved during page 
load).  Futured.  For this reason the menu should probably be disabled while 
the page is loading.
b. Bug 47760
c & d. "None" should actually be renamed "Minimal Page Style" since inline and 
persistent styles are still left on.  Currently I don't think there's a way to 
fully turn off everything, including inline styles, so I didn't provide an 
option just to turn off the persistent styles.  History is something we'd like 
to have but it's probably not going to happen this release.

    
    

    
  
Tobias, for any bugs that were not already disposed of by Tim's explanation, 
would you please open a separate bug report for each issue. One Issue == One Bug 
Report is The Golden Rule of Bugzilla to enable independent tracking, 
reassignment, and prioritization of bugs. Thanks!

    
    

    
  
I think this bug can be closed since the basic infrastructure of using
alternative stylesheets is set and working.

To my mentioned bugs:
(a) is bug 47734
(b) is bug 47760
New filled in:
(c) add an menu entry if the (only style=default style) has no title; bug 51686
(d.1) change 'None' into 'Minimal Page Style'; bug 51688
(d.2) add a possibility to disable also inline stylesheets ("None"), related to
bug 32372 (disable stylesheets in pref); bug 51690
(e) Support History; 51692 (This is only reload and back/forward; I haven't
filled in a stylesheet session menagement)

    
    

    
  
In order to seperate bugs, I filled in bug 51848, which is about selecting a
(alternate) stylesheet for printing. If a UI has been established for this, I
think we should only display items in Use stylesheets with media=screen and
media=all. (Until this happend we should still display those with printer in
them because else we cannot select them.)
(The other non all, printer, screen stylesheets might be shown together with the
other links as suggested in bug 2800)

    
    

    
  
Don't listen to [ekrock@netscape.com 2000-09-06 14:57]. This bug is a placeholder 
for everything related to enabling/disabling stylesheets in the UI. A couple of 
bugs that were spun off will be marked as dup. We'll look into the details after 
we ship.

Keywords: helpwanted

    
    

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

    
    

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

    
    

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

    
    

    
  
Pierre, that was a bad move. We don't have a single bug for all aspects of HTML 
4.01 support (for example); there isn't a good reason that we should have a 
single bug for all aspects of alternate style sheet support, either. And this bug 
is already very long.


    
    

    
  
Matthew, this bug is for a fairly well delimited feature that is not going to be 
implemented in 6.0 and I don't want a dozen bugs on my list each describing a 
different aspect of the same feature, down to the role of individual prefs and 
menu items. I prefer everybody to write down ideas here, I'll collect and format 
them and we'll move the debate to the newsgroup during the design phase of the 
next version. Sounds good?

Depends on: 47734

    
    

    
  
There was some discussion of posting this bug to newsgroups after rtm.  Has 
that happened?

    
    

    
  
(marking alternate style sheet bugs for easy tracking...)
Summary: [RFE] UI for alternate and user stylesheets [IMPORT] → [RFE] UI for alternate and user stylesheets [IMPORT] [ASS]

    
  
Summary: [RFE] UI for alternate and user stylesheets [IMPORT] [ASS] → [RFE] UI for alternate and user stylesheets [IMPORT] [AltSS]

    
    

    
  
W3C `Common user agent problems' <http://www.w3.org/TR/2001/NOTE-cuap-20010206>, 
2.1: Implement user style sheets. Allow the user to select from author and
user style sheets or to ignore them.

Pierre: No -- because `6.0', `design phase', and `next version' mean nothing to 
me, and because the debate *wasn't* moved to the newsgroup.

Blocks: 68427

    
    

    
  
*** Bug 68416 has been marked as a duplicate of this bug. ***
No longer blocks: 68427
Blocks: 68416

    
    

    
  
Wanted to add a comment to this.  I hope I don't mess anything up..

I think it would be nice to have an entry in the preferences, like under
Internet Options > Accessability in IE 5.  A place where you could browse or
type the path to the user stylesheet you want to use.

    
    

    
  
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
Keywords: html4, 
          
            mozilla0.9, 
          
            mozilla1.0, 
          
            nsbeta1

    
    

    
  
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

    
    

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

Gerv

    
    

    
  


  

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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#2836).

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#3737).

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? 

    
    

    
  
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

    
    

    
  
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?


    
    

    
  
> 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

    
    

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


    
    

    
  
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.

    
    

    
  
> 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

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  
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?

    
    

    
  
> 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

    
    

    
  
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.

    
    

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

And, while I'm here, I want to chip in on this from 2.4:
>   o A selected alternate style will remain in effect as long as it is 
>    available or until the user selects another style.
>      - How is the availability of an author style to be determined?

This is tricky. I say that if the URI is the same, we assume it's exactly the
same. If the domain is the same AND the style name is the same but the URI is
different, we reload the style but keep it applied. Otherwise, we drop it.
Better to remove style if in doubt rather than apply the wrong style to a random
page. Authors should not do silly things like having the same URI refer to two
different style sets, and if they do, they should expect to confuse user agents.

Has the W3C group thought of this? Perhaps a unique "style id" attribute on the
Style tag - different from the Title, which is meant for presentation to the
user.

Gerv

    
    

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

    
    

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

|      - How is the availability of an author style to be determined?

We need to be able to handle the following situation:

Set 1:
 <link rel="stylesheet" media="print" title="Printer" href="styles/bw-base.css">
 <link rel="stylesheet" title="Red" href="styles/color-base.css">
 <link rel="alternate stylesheet" title="Green" href="styles/color-base.css">

Set 2:
 <link rel="stylesheet" media="print" title="Printer" href="styles/bw-base.css">
 <link rel="stylesheet" media="print" title="Printer"
       href="styles/printer/main.css">
 <link rel="stylesheet" title="Red" href="styles/color-base.css">
 <link rel="stylesheet" title="Red" href="styles/red/main.css">
 <link rel="alternate stylesheet" title="Green" href="styles/color-base.css">
 <link rel="alternate stylesheet" title="Green" href="styles/green/main.css">

Set 3:
 <link rel="stylesheet" media="print" title="Printer" href="styles/bw-base.css">
 <link rel="stylesheet" title="Red" href="styles/color-base.css">
 <link rel="stylesheet" title="Red" href="styles/red/gloss.css">
 <link rel="alternate stylesheet" title="Green" href="styles/color-base.css">
 <link rel="alternate stylesheet" title="Green" href="styles/green/gloss.css">

Set 4 (different site?):
 <link rel="alternate stylesheet" title="Green" href="styles/forest.css">

Set 5:
 <link rel="stylesheet" media="print" title="Printer" href="styles/bw-base.css">
 <link rel="stylesheet" media="print" title="Printer"
       href="styles/printer/main.css">
 <link rel="stylesheet" title="Red" href="styles/color-base.css">
 <link rel="stylesheet" title="Red" href="styles/red/main.css">

Set 6:
 <link rel="stylesheet" media="print" title="Printer" href="styles/bw-base.css">
 <link rel="stylesheet" media="print" title="Printer"
       href="styles/printer/main.css">
 <link rel="stylesheet" title="Blue" href="styles/color-base.css">
 <link rel="stylesheet" title="Blue" href="styles/blue/main.css">
 <link rel="alternate stylesheet" title="Red" href="styles/color-base.css">
 <link rel="alternate stylesheet" title="Red" href="styles/red/main.css">

If I visit 2, "Red" will be selected because it is the preferred style. If I 
then visit 6, the preferred style, "Blue", will be selected because I did not 
actually select "Red". Preferred styles do not set the user selection.

If I pick "Green" in set 1, 2, or 3, it should be selected every time I visit 
any one of them, but not selected for set 4. So, if the title is the same and at 
least one of the (resolved) URIs is the same, then it's the same Style.

If I then visit 5, "Red" will be selected, because "Green" is not available, and 
"Red" is the preferred style. When I go to 3, "Green" will once more be 
selected.

If I visit 6, "Blue" will be selected, because "Green" is not available, and 
"Blue" is the preferred style. If I select "Red" from the Use Style menu, and 
then return to 3, "Red" will be selected in 3 because I consciously chose it.

An automatically assigned style never overwrites the user's selection.


    
    

    
  
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.

    
    

    
  
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.

> We need to be able to handle the following situation:

Right. So can you suggest an algorithm, please? :-)

Gerv

    
    

    
  
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.

    
    

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

> Right. So can you suggest an algorithm, please? :-)

Yes, I can. :-)

Here 'tis, since you asked:

In the following text, "alternate styles" includes "preferred styles" (but not 
vice versa).
"Page-Defined Style" refers to the default (preferred) style choice when no 
preferred stylesheet exists.

"None":
  "none" is a persistent option. That is, once it is selected, it does not get
  unselected until the user specifically selects something else.

Style History format:
A history is kept of all alternate styles selected.
The Style History contains
  - a list of all alternate Styles used, sorted by last-visited date
  - a list of all alternate Styles dropped in favor of "Page-Defined Style"
    (may be a list of references to Styles in visited Styles list)
  Each Style consists of
    - a name (title)
    - a list of Stylesheets sorted by last-visited date
    Each Stylesheet holds
      - a URI
      - a last-visited date
  The last-visited date of a Style is the most recent last-visited date in its
    list of Stylesheets.

The Style History gets cleared with the regular History, and Stylesheets expire 
from it in the same time period regular Pages do from the regular History.
If a Style has no more Stylesheets, then it, too, expires.

Adding to the Style History: **
  - Persistent stylesheets are never added
  - Alternate stylesheets are added when selected
  - Preferred stylesheets are -only- added if selected either
      - by the History
      - by the User when switching from alternate to preferred
  - Preferred stylesheets are -not- added if
      - they are automatically selected (defaulted to)
      - they are selected by the User when switching from none to preferred
  - If "Page-Defined Style" is explicitly selected over a previously selected
    alternate style, then that Style gets added to the list of dropped styles.
    The Style is removed from this list the next time it is selected.

Selecting an Alternate Style:
  1.) All the alternate styles in the page are organized into Alternate Styles.
      An Alternate Style consists of
        - a name
        - a list of stylesheet URIs
  2.) The Alternate Styles are checked against the dropped Styles list
      Iterate over the dropped Styles until a match is found or the list ends.
      For each dropped Style -
        Iterate over the list of Alternate Styles
        For each Alternate Style - 
          Check the name of the Alternate Style against the archived Style
          If the name matches
            Iterate over the list of stylesheet URIs in the matching Alternate
                                                                     Style
            For each Alternate Style -
              Check the archived Style's list of Stylesheets for a matching URI
              If one is found, the Alternate Style matches; cache a reference to 
                                                            the Style and break
  3.) To select the Alternate Style, the Style History visited list is
      iterated over until a matching Style is found, the archived Style being
      examined matches a dropped style (we cached the most recent one in step 2)
      or the list ends.
      For each archived Style - 
        Iterate over the list of Alternate Styles
        For each Alternate Style - 
          Check the name of the Alternate Style against the archived Style
          If the name matches
            Iterate over the list of stylesheet URIs in the matching Alternate
                                                                     Style
            For each Alternate Style - 
              Check the archived Style's list of Stylesheets for a matching URI
              If one is found, the Alternate Style matches; select it and break
      If no matching Style is found, use the Preferred Style (or Page-Defined
      Style, if there is none)--but do not add it to the Style History!

** This is a departure from the Summary in that once explicitly selected, the
default style is treated more like another alternate stylesheet than like a
persistent option. To restore the Summary's behavior, remove the last three
"Adding to the Style History" rules and exclude "preferred style" from the
definition of "alternate style" in the entire text.

You did ask...

    
    

    
  
So far I think that fantasai@escape.com's last outline is the best.

Personally my $.02, without persistent alternate stylesheets (i.e. mozilla
remembers the selected alternate stylesheet for a whole given site and every
revisit until another is selected), mozilla implementation is only a token gesture.
I know as a web developer of sites I would use alternate stylesheets but can not
justfy to my boss the effort or cost needed to make the site additions without a
browser correctly implementing them.

I vote for adding the basic common sense stuff first and make additions later
like print ui (where in the print dialogs you can select print styles) or tweak
 the implementation for the odd scenario's later.

    
    

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

> Here 'tis, since you asked:

OK, that blows my mind. Someone who understands style sheets better will have to 
review it. But well done for writing it, because it needed writing.

Are we going to make an attempt on this bug without History support, or is it 
not worth it? I have a mental handle on how to do it without, but if we have to 
integrate with History that'll mean a whole lot of changes over there, and 
it'll be far more complex. Perhaps a separate bug should be filed? Something 
like "allow generic metadata to be associated with items in History"...

Gerv

    
    

    
  
As I see it, the Style History needs to be recorded separately, not integrated
into the regular History. Otherwise we get the scenario where I switch styles,
go back one page, and Mozilla switches the styles back to what I had before.

    
    

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

    
    

    
  
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.

    
    

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

    
    

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



    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
Since this is a dup of bug 103062, blocks bug 103053.
Blocks: 103053

    
    

    
  
Alternate style sheets have nothing to do with navigation, so bug 103062 is a
wontfix, not a duplicate. Removing dependency on bug 103053.
No longer blocks: 103053

    
    

    
  
There's no reason the current "Site Navigation Toolbar" needs to continue to be
called that. It could equally (even preferably) be called the "Site Toolbar" or
"Document Toolbar".
To me it makes sense to have all site or document specific elements of UI on the
one toolbar. Currently the only argument I've seen for not having alternate
stylesheet selection on that toolbar amounts to the fact that the toolbar
currently has the word "Navigation" in it's name. It doesn't have to be that
way, it's just an artifact of the way the toolbar came into existance.
bug 103062 is the bug on renaming the "Link"/"Site Navigation Toolbar" toolbar.

    
    

    
  
That should have read bug 102991
Sorry for the spam.

    
    

    
  
Yes, my understanding of what you are terming the "navigation" toolbar was that 
it was a UI for the <LINK> tag.  As such, it includes a stylesheet linking 
mechanism, not just navigation.

    
    

    
  
The backend source for the info for that toolbar is an implementation detail. It
should contain whatever UI we think logically fits there. (For example, someone
suggested What's Related could also live there, as well as being a sidebar panel.)

Gerv

    
    

    
  
I understand that this toolbar doesn't need to include the stylesheet UI, but 
let us at least come to a public decision and enumerate the reasons for this 
decision, so that we don't leave the rest of the world in limbo.  AFAICT, the 
decision has at best been a tacit assumption among the UI gurus.

In other words, please explain what "logically fits there" and why.  Is this not 
a fair request?

    
    

    
  
Dude, I want the stylesheet UI there :-) My point was that "It's a <link>
toolbar, and stylesheets use <link>, so their UI should be on the toolbar" is a
bogus argument.

Gerv


    
    

    
  
Someone mentioned having the link/navigation/whatever -toolbar be a "Page" 
toolbar. That is, contain things that are specific for the viewed page. That 
sounds like a good idea to me.

    
  
Blocks: 104166

    
    

    
  
> Currently the only argument I've seen for not having alternate
> stylesheet selection on that toolbar amounts to the fact that the toolbar
> currently has the word "Navigation" in it's name.

That isn't the only reason.  Thinking of the toolbar as a links or navigation
toolbar was in the collective consciousness from the beginning.  It's in the
contributed specs which explicitly talk about leaving out stylesheets.  It's why
   I mimicked the Personal Toolbar in its design.

It's not too difficult to make the toolbar look less like the Personal Toolbar
should people decide to go that way.  But don't say it's only in the name.  It's
the other way around.  The name is derived from what we originally intended the
toolbar to be.

FYI, for recent discussion over the name, see bug 102991.  Discussion during
development goes all the way back to bug 87428 and bug 2800.
I agree with mpt that bug 38521 is a better place to lobby for this.

No longer blocks: 104166

    
    

    
  
bug 38521 ??? As if discussing and implementing what I proposed in bug 103062
hasn't been gratuitously wontfixed, duped and bounced around various bugs enough
already.....Sheesh.

It's simple. 
- I want a decent UI for choosing between alternate stylesheets for a document
(ie A UI that gives an indication that a choice is available, having it buried
in a menu is certainly not a good UI).

- The choices you are offered for alternate stylesheets are pertinant to the
current document. It would be good if this was reflected in the UI if possible.
By this I mean it should not be placed in a part of the UI generally reserved
for non page specific functionality (menubar, navigation bar, personal toolbar).
The UI in these areas remains consistant, the contents do not change depending
upon the document content. The new toolbar we have seems to fit this criteria
nicely.

No one has given me a reason why this new toolbar, forgetting it's name,
wouldn't  be an appropriate place for an alternate style sheet UI. 

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.

    
    

    
  
I think that before progress can be made on Paul's points, there needs to be a
decision about the "link toolbar". Is it for navigation, or is it for
page-specific "chrome"? The original intention--and as this feature is currently
expressed--is as a site navigation toolbar. This is a product of the orientation
of most defined LINK relationships toward navigation. I'll assert that the
primary motivation for this toolbar has been the pursuit of "good" support for LINK.

A rationale behind the current design seems to be, "Let the Web page modify a
defined portion of the browser UI." Sounds reasonably harmless. German Bauer
raises a red flag: this implementation blurs the boundary between the browser
chrome and the Web page. German's reservations are justified. Mozilla has been
burned here before. Remember the first incarnation of the Modern theme? That was
the one Netscape designed with a "flat" appearance to blend in with Web page.
Users hated it for exactly that reason. Now, instead of making the browser UI
look like the Web page, the navigation toolbar makes a part of the page look
like the browser UI.

The important point here is that users really *do* notice what's part of the
page, and what is not. They notice because this distinction provides an
important reference point when interacting with the Web browser. If we obfuscate
that reference point, we are doing a disservice to users.

I think the link toolbar is very useful and I'm glad to see it finally in the
browser. It should not go away, and it should not be hidden from "average"
users. It should be visually distinct from both the Web page *and* the rest of
the browser chrome, so that users can clearly identify it as a special feature
of certain Web pages.

If we acknowledge that this toolbar is first and foremost a way for different
Web pages to provide a consistent UI to common functions, "site navigation" is
but one of its potential uses. So to Gerv's suggestion that the fact that this
toolbar uses LINK elements in the page to get its information is simply an
implementation detail, I say: hogwash. Providing a good implementation of LINK
was the motivation for this toolbar. And users depend on discerning what is part
of the page and what is not: it is not appropriate to treat the Web page as an
arbitrary datasource that is transparent to the user, because that datasource is
anything *but* transparent. That is a design *feature* of Web browsers--not an
artifact.
And anyway, do we really need a *whole toolbar* for site-specific navigation
functions? Share the real estate.

    
    

    
  
> A rationale behind the current design seems to be, "Let the Web page modify a
> defined portion of the browser UI."

That may be one way to characterize it.  I tend to think of it this way: there
is a standard way to represent some standard relationships between web pages. 
The linktoolbar displays these relationships in a standard location.

> Sounds reasonably harmless. German Bauer
> raises a red flag: this implementation blurs the boundary between the browser
> chrome and the Web page.

TITLE has been displayed in the window title bar since Mosaic days without
blurring the boundry between chrome and webpage.  I don't see users scurrying
away in fear because a web site just took over their window title, no more so
than when button, text, and list widgets infect their pristine web page, showing
up in their content whenever the page has FORM elements in the BODY... ;)

JavaScript lets you alter the status bar to good or ill effect.


Anyhow, back to the story at hand.  Please decide quickly if stylesheets will
have a home in the _______ Toolbar (formerly known as Site Navigation Bar). 
Gerv is asking that we wait on deciding a name for this Toolbar (bug 102991)
until the decision on stylesheets is made.


    
    

    
  
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 and an item "Remember for this site" that would be checked by 
default.  The definition of "site" should not be based on the host name but on 
the URL of the directory that contains the current page.  Also, I don't think it 
would be useful to rememmber the setting per page.  Authors will provide 
stylesheets (read "skins") for their entire sites, not for individual pages.


            +-------------------------+
            |  None                   |
     Style: |- Default                |
            |  Old Style              |
            |  Modernist              |
            |  Midnight               |
            |  Ultra Marine           |
            |-------------------------|
            |v Remember for this site |
            +-------------------------+

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.


    
    

    
  
>an item "Remember for this site" that would be checked by default.

The user shouldn't have to think about this. The stylesheet selection should 
persist automatically.

> Also, I don't think it would be useful to rememmber the setting per page.

Agreed.

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


    
    

    
  
> My vote goes to adding the stylesheets in a Document Toolbar
> and an item "Remember for this site" that would be checked by default.

ACK

> The definition of "site" should not be based on the host name but on 
> the URL of the directory that contains the current page.

Or remember the location + title (specified by <link>) of the 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.

ACK. But who will use a standard-compliant browser today?

    
    

    
  
> 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


    
    

    
  
Agreed on all suggestions.  I especially like Sacha's idea to remember the 
location and title of the stylesheets.  It makes the implementation much more 
efficient.  Another advantage is that if different sites share the same set of 
stylesheets, it allows us to select the last stylesheet that was used on any of 
these sites.


    
    

    
  
I don't like the idea of sharing style sheet prefs between sites.  If we did 
that, a site could get a good idea of what other types of sites I visit by 
seeing which style sheet my browser chooses for me when given various 
combinations of choices.  (If every site gave the same set of choices, that 
wouldn't be a large privacy problem, but most sites that have alternate style 
sheets give them relatively unique names.)

    
    

    
  
> I don't like the idea of sharing style sheet prefs between sites.  If we did 
> that, a site could get a good idea of what other types of sites I visit by 
> seeing which style sheet my browser chooses for me when given various 

If the Browser remembers the location, the SS must the same as at the other 
site, it must have the same location. So the other site has to look at foreign 
logs.
An option to turn on/off this would be useful.

OTOH: Sites might copy the most popular SS to get a better design.

    
    

    
  
Since nobody's going to bother reading 2881 lines of mostly irrelevant text to 
see what's been said already on this particular aspect of the whole generalized 
Style Switching thing -

FYI: Previous discussion on style selection history began on 2001-06-28 (Gervase 
Markham) and ended three days later (2001-07-01, fantasai).
See also bug 51692: "[RFE]Used stylesheet should be stored in history" (which 
hasn't seen discussion since last year).
and bug 83663: "Alternate style sheet setting not stored [AltSS]" (resolved dup)

    
    

    
  
Sascha: a site can use javascript to find out what style sheet is being used to 
view the page.  One was is to use the getComputedStyle() function, which tells 
the page what styles have been applied to a given element.

    
    

    
  
Jesse: Wouldn't user style sheets be a privacy problem too? If you are really
worried about privacy problems could you not use the style sheets in the way you
described?

    
    

    
  
Basic: it would be nice if a web site couldn't guess at the rules in my user 
style sheet, but they can, and I don't consider that to be a huge privacy hole, 
partly because few users have user style sheets.  If Mozilla remembered which 
stylesheets I chose from a web site and then applied those choices to other 
pages, that would allow a site to guess at what other sites I have visited, 
which I consider more of a problem.

    
    

    
  
fantasai politely hinted at this, but I'll be more blunt.  Please move
discussion about remembering style sheet selection and its implications to bug
51692.  

Besides being a more appropriate place to discuss it, bug 51692 could use some
serious love.

    
    

    
  
> Please move discussion about remembering style sheet selection and its 
> implications to bug 51692.

Actually, I think bug 83663 is more appropriate; bug 51692 is too narrowly 
focused. 83663 also has more information. But since it's marked a duplicate of 
this bug, discussion goes here..

Pierre: Would you mind terribly if I took over this bugs report? It needs 
untangling.

> I don't like the idea of sharing style sheet prefs between sites.  If we did 
> that, a site could get a good idea of what other types of sites I visit

Define "site". Give an example where selecting a stylesheet by name + uri 
creates a privacy problem. Explain how we can avoid this problem without giving 
up style selection memory. 
(There's a sample set in [fantasai@escape.com 2001-06-28 12:01]--you might find 
it useful.)


    
    

    
  
Reassigned to fantasai.  Thanks for taking it over.

Agreed: there is no real privacy problem here and if there is one, it is even 
much smaller than issues raised by cookies.  BTW, we could reuse the prefs: if 
cookies are disabled for a domain, we don't remember the stylesheet selection.

Assignee: pierre → fantasai
Status: ASSIGNED → NEW

    
  
Status: NEW → ASSIGNED

    
  
Depends on: 51692

    
    

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

    
    

    
  
Like I said in my bug that was marked as a dup of this, I think alternate style
menu should be placed in the Site Navigation Bar. 

    
    

    
  
"One bug report == one issue is one of the golden rules of Bugzilla because it
enables independent tracking and prioritization of each issue."
                                              -- ekrock@netscape.com, bug 4510

This bug is a mess; it's over 3000 lines of a wide range of topics--more than
one bug, certainly. It's hard to find what's been already said on a given issue,
and things are getting lost in the dupes and text.

So I'm splitting up this bug. Or untangling it, if you will. Your comments
won't get lost; they're either incorporated in the summary (for those prior to 
April 2001) or they've been exerpted into the appropriate bug report. If you've
made a comment on a particular issue, I've probably CCed you on the bug. (Just
trying to avoid spam. ;)


*** This bug has been marked as a duplicate of 107023 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE

    
  
Whiteboard: REPLACED BY BUG 107023

    
    

    
  
Verified unwieldy.
Status: RESOLVED → VERIFIED

    
    

    
  
Why don't you create a sidebar tab for easy acces for alternative or user 
stylesheets.
(tabs can be customized, so users can easily add or remove this feature)

    
    

    
  
I think it would be confusing for users if we put preferences into sidebar 
panels.  Sidebar panels don't change the browser behavior.  It could be an 
invitation for security breaches too.

Product: Core → Mozilla Application Suite

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: