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

Note that in any case this is a requirement for full HTML4 compliance.

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

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

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.

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.

It isn't really related.

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.

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

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.

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?

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.

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.

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.

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

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

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

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.

*** 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?

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

(marking alternate style sheet bugs for easy tracking...)

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.

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

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

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.

Alternate style sheets have nothing to do with navigation, so bug 103062 is a wontfix, not a duplicate. Removing dependency on bug 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.

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

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.

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

Verified unwieldy.

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.