Closed
Bug 6782
Opened 26 years ago
Closed 23 years ago
[RFE] UI for alternate and user stylesheets [IMPORT] [AltSS]
Categories
(SeaMonkey :: UI Design, enhancement, P3)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 107023
Future
People
(Reporter: dbaron, Assigned: fantasai.bugs)
References
(Blocks 1 open bug, )
Details
(Keywords: html4, Whiteboard: REPLACED BY BUG 107023)
Attachments
(9 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details |
A good user interface for alternate and user stylesheets would be a very useful
(and neat) feature. Alternate and user stylesheets were among the original
design goals of CSS and an interface for using them has not been properly
implemented in any browser. I've written a document describing what I think
should be part of such an interface:
http://www.fas.harvard.edu/~dbaron/css/ssui/
The functions needed to implement part of the interface are already implemented
in the style code, as I describe in the page above.
Note that requests for this feature have been featured in WSP reviews of MSIE
and Opera:
http://www.webstandards.org/css/winie/#Alternate_stylesheet_UI
http://www.webstandards.org/css/opera/#Alternate_stylesheet_UI
Comment 1•26 years ago
|
||
Can you please comment on this?
Comment 2•26 years ago
|
||
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
Updated•26 years ago
|
Summary: RFE: UI for alternate and user stylesheets → {css1} RFE: UI for alternate and user stylesheets
Comment 4•26 years ago
|
||
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 ...
Reporter | ||
Comment 7•26 years ago
|
||
Two notes:
The top level menus wasn't really a serious suggestion for Mozilla's
distribution chrome, although I know a few people who would want it in
customized chrome.
I really do think it is better to have two submenus of the View menu, one for
user stylesheets and one for author stylesheets, rather than combine them into
one confusing menu.
Summary: {css1} RFE: UI for alternate and user stylesheets → [RFE] UI for alternate and user stylesheets
Two submenus would be fine as well. I suggest not showing the author style
sheets menu at all, when there are none supplied (or at least greying them out),
in order to simplify and reduce the clutter in the menu for the 90% case
initially.
Comment 9•26 years ago
|
||
Bug #11520 is related to this.
Reporter | ||
Comment 10•26 years ago
|
||
It isn't really related.
Comment 11•26 years ago
|
||
Well, considering they're both about submenus to provide good stylesheet
support, I thought anyone reading this might also be interested ...
Comment 12•25 years ago
|
||
"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.
Comment 13•25 years ago
|
||
*** Bug 20040 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
Move to M20.
Comment 15•25 years ago
|
||
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.
Comment 16•25 years ago
|
||
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.
Comment 17•25 years ago
|
||
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 ...
Comment 19•25 years ago
|
||
Note that the Web Standards Project have been clamouring for an out-of-the-box
Alternate Stylesheets user interface for around 2 years now. Every browser they
have reviewed has been missing it, and each time they complained loudly.
Peter Linss did 90% of the work of supporting this, and in fact Viewer already
has a quick and dirty alternate stylesheets interface. David Baron has written
a spec for this UI (see the URL field), which includes information on how to
implement this in Mozilla. I have written some comprehensive test cases for this
too, so testing behaviour once it is written is already possible.
Here are some resources for implementing this:
http://www.people.fas.harvard.edu/~dbaron/css/ssui/
http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt
http://www.bath.ac.uk/%7Epy8ieh/internet/importtest/
http://lxr.mozilla.org/seamonkey/ident?i=GetActiveAlternateStyleSheet
http://lxr.mozilla.org/seamonkey/ident?i=SelectAlternateStyleSheet
http://lxr.mozilla.org/seamonkey/ident?i=ListAlternateStyleSheets
http://lxr.mozilla.org/seamonkey/ident?i=DispatchStyleMenu
It would be truly great if this could be done for FCS...
(BTW, just so that no one claims unfair play: Yes, the Web Standards Project
"they" includes me, the reporter and at least one other person on the cc list).
Keywords: helpwanted
Comment 20•25 years ago
|
||
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.
Comment 21•25 years ago
|
||
| 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.
Comment 22•25 years ago
|
||
> 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.
Comment 23•25 years ago
|
||
>> 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.
Comment 24•25 years ago
|
||
Comment 25•25 years ago
|
||
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.
Comment 26•25 years ago
|
||
Stealing the bug from Don. I'll try Tim's patch and see if it can be checked in
for beta3.
Assignee: don → pierre
Target Milestone: Future → M18
Comment 27•25 years ago
|
||
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.
Comment 28•25 years ago
|
||
*** Bug 45848 has been marked as a duplicate of this bug. ***
Comment 29•25 years ago
|
||
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.
Comment 30•25 years ago
|
||
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.)
Reporter | ||
Comment 31•25 years ago
|
||
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).
Comment 32•25 years ago
|
||
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?).
Comment 33•25 years ago
|
||
> * 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.
Reporter | ||
Comment 34•25 years ago
|
||
But how do you apply both a user stylesheet and an author preferred/alternate
stylesheet at the same time?
Assignee | ||
Comment 35•25 years ago
|
||
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?
Comment 36•25 years ago
|
||
> 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.
Reporter | ||
Comment 37•25 years ago
|
||
> > 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.
Assignee | ||
Comment 38•25 years ago
|
||
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.
Comment 39•25 years ago
|
||
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.
Comment 40•25 years ago
|
||
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.)
Reporter | ||
Comment 41•25 years ago
|
||
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.
Comment 42•25 years ago
|
||
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?
Updated•25 years ago
|
Reporter | ||
Comment 43•25 years ago
|
||
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.
Comment 44•25 years ago
|
||
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.
Reporter | ||
Comment 45•25 years ago
|
||
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).
Comment 46•25 years ago
|
||
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?
Reporter | ||
Comment 47•25 years ago
|
||
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.)
Comment 48•25 years ago
|
||
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".
Comment 49•25 years ago
|
||
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.
Assignee | ||
Comment 50•25 years ago
|
||
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?
Comment 51•25 years ago
|
||
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'.
Assignee | ||
Comment 52•25 years ago
|
||
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.)
Comment 53•25 years ago
|
||
>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.
Comment 54•25 years ago
|
||
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.)
Comment 55•25 years ago
|
||
> 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 ... :(
Assignee | ||
Comment 56•25 years ago
|
||
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.
Assignee | ||
Comment 57•25 years ago
|
||
Assignee | ||
Comment 58•25 years ago
|
||
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.
Comment 59•25 years ago
|
||
(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. :-)
Assignee | ||
Comment 60•25 years ago
|
||
Comment 61•25 years ago
|
||
Adding [fix in hand] in the summary line, acknowledging that Tim's patch doesn't
cover the whole issue.
Status: NEW → ASSIGNED
Summary: [RFE] UI for alternate and user stylesheets → [fix in hand][RFE] UI for alternate and user stylesheets
Whiteboard: [fix in hand]
Assignee | ||
Comment 62•25 years ago
|
||
Assignee | ||
Comment 63•25 years ago
|
||
Assignee | ||
Comment 64•25 years ago
|
||
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.
Assignee | ||
Comment 65•25 years ago
|
||
Comment 66•25 years ago
|
||
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).
Assignee | ||
Comment 67•25 years ago
|
||
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/. >:)
Comment 68•25 years ago
|
||
> 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.
Comment 69•25 years ago
|
||
Fantasai: Could you run through the entire Import Test with your patch?
http://www.bath.ac.uk/%7Epy8ieh/internet/importtest/
Or alternatively (no pun intended), mail me the patched files (ianh@netscape.com)
and I'll do it after nsbeta2 ships.
Keywords: correctness
Updated•25 years ago
|
Whiteboard: [fix in hand] → [fix in hand] hit during nsbeta2 standards compliance testing
Assignee | ||
Comment 70•25 years ago
|
||
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.
Assignee | ||
Comment 71•25 years ago
|
||
Comment 72•25 years ago
|
||
[nsbeta3+]. Easy fix, in hand, contributed from the net.
Whiteboard: [fix in hand] hit during nsbeta2 standards compliance testing → [nsbeta3+][fix in hand] hit during nsbeta2 standards compliance testing
Comment 73•25 years ago
|
||
> There is no distinguishing between media types; I was able to choose Ian
> Hickson's printer styles.
That's fine -- so logn as we don't _apply_ the style then we're ok.
i.e., if there is a style called "a" for screen and a style called "b" for
print, then it is fine to always offer "a" and "b", so long as "b" has no
effect when on screen and "a" has no effect on the printer.
Do we have an r= for this patch?
Keywords: review
Comment 74•25 years ago
|
||
Partial fix checked in:
navigator.dtd
navigator.js
navigatorOverlay.xul
Thanks to Tim Hill <tim@prismelite.com>
Moving to Future now...
Keywords: correctness,
nsbeta3,
patch,
review
Summary: [fix in hand][RFE] UI for alternate and user stylesheets → [RFE] UI for alternate and user stylesheets
Whiteboard: [nsbeta3+][fix in hand] hit during nsbeta2 standards compliance testing
Target Milestone: M18 → Future
Comment 75•25 years ago
|
||
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).
Updated•24 years ago
|
Summary: [RFE] UI for alternate and user stylesheets → [RFE] UI for alternate and user stylesheets [IMPORT]
Comment 76•24 years ago
|
||
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.
Comment 77•24 years ago
|
||
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.
Comment 78•24 years ago
|
||
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.
Comment 79•24 years ago
|
||
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".
Comment 80•24 years ago
|
||
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?
Comment 81•24 years ago
|
||
Comment 82•24 years ago
|
||
Sorry about that. Fix checked in.
Comment 83•24 years ago
|
||
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.
Comment 84•24 years ago
|
||
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.
Comment 85•24 years ago
|
||
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!
Comment 86•24 years ago
|
||
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)
Comment 87•24 years ago
|
||
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)
Comment 88•24 years ago
|
||
Don't listen to [ekrock@netscape.com 2000-09-06 14:57]. This bug is a placeholder
for everything related to enabling/disabling stylesheets in the UI. A couple of
bugs that were spun off will be marked as dup. We'll look into the details after
we ship.
Keywords: helpwanted
Comment 89•24 years ago
|
||
*** Bug 51690 has been marked as a duplicate of this bug. ***
Comment 90•24 years ago
|
||
*** Bug 51848 has been marked as a duplicate of this bug. ***
Comment 91•24 years ago
|
||
*** Bug 51688 has been marked as a duplicate of this bug. ***
Comment 92•24 years ago
|
||
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.
Comment 93•24 years ago
|
||
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?
Comment 94•24 years ago
|
||
There was some discussion of posting this bug to newsgroups after rtm. Has
that happened?
Comment 95•24 years ago
|
||
(marking alternate style sheet bugs for easy tracking...)
Summary: [RFE] UI for alternate and user stylesheets [IMPORT] → [RFE] UI for alternate and user stylesheets [IMPORT] [ASS]
Summary: [RFE] UI for alternate and user stylesheets [IMPORT] [ASS] → [RFE] UI for alternate and user stylesheets [IMPORT] [AltSS]
Comment 96•24 years ago
|
||
W3C `Common user agent problems' <http://www.w3.org/TR/2001/NOTE-cuap-20010206>,
2.1: Implement user style sheets. Allow the user to select from author and
user style sheets or to ignore them.
Pierre: No -- because `6.0', `design phase', and `next version' mean nothing to
me, and because the debate *wasn't* moved to the newsgroup.
Blocks: 68427
Comment 97•24 years ago
|
||
*** Bug 68416 has been marked as a duplicate of this bug. ***
Comment 98•24 years ago
|
||
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.
Updated•24 years ago
|
Keywords: mozilla0.9.1
Comment 99•24 years ago
|
||
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
Comment 100•24 years 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
Comment 101•24 years ago
|
||
ccarlen: Can you answer the question I posed in this bug? LXR claims the code
I'm talking about is yours :-)
Gerv
Assignee | ||
Comment 102•24 years ago
|
||
Comment 103•24 years ago
|
||
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
Comment 104•24 years ago
|
||
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
Comment 105•24 years ago
|
||
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?
Comment 106•24 years ago
|
||
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
Comment 107•24 years ago
|
||
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?
Comment 108•24 years ago
|
||
> 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
Comment 109•24 years ago
|
||
> 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.
Comment 111•24 years ago
|
||
> 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
Comment 113•24 years ago
|
||
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.
Comment 114•24 years ago
|
||
> 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.
Assignee | ||
Comment 115•24 years ago
|
||
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?
Comment 116•24 years ago
|
||
> 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
Comment 117•24 years ago
|
||
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.
Comment 118•24 years ago
|
||
> 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
Comment 119•24 years ago
|
||
> 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...
Assignee | ||
Comment 120•24 years ago
|
||
| > 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.
Comment 121•24 years ago
|
||
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.
Comment 122•24 years ago
|
||
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
Comment 123•24 years ago
|
||
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.
Assignee | ||
Comment 124•24 years ago
|
||
> 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...
Comment 125•24 years ago
|
||
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.
Comment 126•24 years ago
|
||
> 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
Assignee | ||
Comment 127•24 years ago
|
||
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.
Comment 128•24 years ago
|
||
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".
Comment 129•24 years ago
|
||
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.
Comment 130•24 years ago
|
||
*** Bug 83663 has been marked as a duplicate of this bug. ***
Comment 131•24 years ago
|
||
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.
Comment 133•23 years ago
|
||
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.
Comment 134•23 years ago
|
||
*** Bug 103062 has been marked as a duplicate of this bug. ***
Comment 136•23 years ago
|
||
Alternate style sheets have nothing to do with navigation, so bug 103062 is a
wontfix, not a duplicate. Removing dependency on bug 103053.
No longer blocks: 103053
Comment 137•23 years ago
|
||
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.
Comment 138•23 years ago
|
||
That should have read bug 102991
Sorry for the spam.
Comment 139•23 years ago
|
||
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.
Comment 140•23 years ago
|
||
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
Comment 141•23 years ago
|
||
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?
Comment 142•23 years ago
|
||
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.
Comment 144•23 years ago
|
||
> Currently the only argument I've seen for not having alternate
> stylesheet selection on that toolbar amounts to the fact that the toolbar
> currently has the word "Navigation" in it's name.
That isn't the only reason. Thinking of the toolbar as a links or navigation
toolbar was in the collective consciousness from the beginning. It's in the
contributed specs which explicitly talk about leaving out stylesheets. It's why
I mimicked the Personal Toolbar in its design.
It's not too difficult to make the toolbar look less like the Personal Toolbar
should people decide to go that way. But don't say it's only in the name. It's
the other way around. The name is derived from what we originally intended the
toolbar to be.
FYI, for recent discussion over the name, see bug 102991. Discussion during
development goes all the way back to bug 87428 and bug 2800.
I agree with mpt that bug 38521 is a better place to lobby for this.
No longer blocks: 104166
Comment 145•23 years ago
|
||
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.
Comment 146•23 years ago
|
||
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.
Comment 147•23 years ago
|
||
> 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.
Comment 148•23 years ago
|
||
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.
Assignee | ||
Comment 149•23 years ago
|
||
>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.
Comment 150•23 years ago
|
||
> 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?
Comment 151•23 years ago
|
||
> 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
Comment 152•23 years ago
|
||
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.
Comment 153•23 years ago
|
||
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.)
Comment 154•23 years ago
|
||
> 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.
Assignee | ||
Comment 155•23 years ago
|
||
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)
Comment 156•23 years ago
|
||
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.
Comment 157•23 years ago
|
||
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?
Comment 158•23 years ago
|
||
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.
Comment 159•23 years ago
|
||
Assignee | ||
Comment 160•23 years ago
|
||
> 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.)
Comment 161•23 years ago
|
||
Reassigned to fantasai. Thanks for taking it over.
Agreed: there is no real privacy problem here and if there is one, it is even
much smaller than issues raised by cookies. BTW, we could reuse the prefs: if
cookies are disabled for a domain, we don't remember the stylesheet selection.
Assignee: pierre → fantasai
Status: ASSIGNED → NEW
Comment 162•23 years ago
|
||
*** Bug 106510 has been marked as a duplicate of this bug. ***
Comment 163•23 years ago
|
||
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.
Assignee | ||
Comment 164•23 years ago
|
||
"One bug report == one issue is one of the golden rules of Bugzilla because it
enables independent tracking and prioritization of each issue."
-- ekrock@netscape.com, bug 4510
This bug is a mess; it's over 3000 lines of a wide range of topics--more than
one bug, certainly. It's hard to find what's been already said on a given issue,
and things are getting lost in the dupes and text.
So I'm splitting up this bug. Or untangling it, if you will. Your comments
won't get lost; they're either incorporated in the summary (for those prior to
April 2001) or they've been exerpted into the appropriate bug report. If you've
made a comment on a particular issue, I've probably CCed you on the bug. (Just
trying to avoid spam. ;)
*** This bug has been marked as a duplicate of 107023 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Comment 166•23 years ago
|
||
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)
Comment 167•23 years ago
|
||
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.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Updated•18 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•