Open Bug 216537 Opened 21 years ago Updated 2 years ago

Persist alternate stylesheet selection using content prefs

Categories

(Firefox :: General, enhancement, P4)

enhancement

Tracking

()

Future

People

(Reporter: 8tfzo9t02, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030817 Mozilla Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030817 Mozilla Firebird/0.6.1+

When I visit a page that offers alternate stylesheets and make my selection from
the pop-up menu in Firebird it changes the page.  When I visit that page again
at some point in the future the stylesheet reverts to the default one.  If I
wanted the alternate stylesheet last time, surely it is fair for Firebird to
assume that I want it this time as well and automatically use the same
stylesheet again.

Reproducible: Always

Steps to Reproduce:
1. Visit the above URL
2. Change to an alternate stylesheet
3. Re-vist the URL (either in the same session or close/restart the browser)

Actual Results:  
Firebird consistently uses the same default stylesheet regardless of how many
times I select a different one.

Expected Results:  
Firebird should remember which stylesheet I picked last time I visited the
page/site and select that one automatically.
Confirmed, seeing in Linux as well (very annoying I might add - I was going to
file a bug on this myself but did a dupe search first). Following a link and
then backing up shows this bug, as does even reloading the page. Konqueror gets
this half right - if you return to the page in the same browsing session via
links, reload, back or forward it remembers the stylesheet. But if you open a
new session (eg, open a new tab and enter the url) it does not.

Firebird's behaviour is identical to Mozilla Navigator's (View | Use Style),
which also has no memory.

We should at least do the same as Konqueror, but preferably we should do one
better and make it permanently sticky.

-->Hyatt
-->minor (annoying as it is, there is a work around)
Assignee: blake → hyatt
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
QA Contact: asa
QA Contact: davidpjames
Blocks: altss
Depends on: 83663
Hardware: PC → All
Summary: Alternate stylesheet selection is not sticky → [AltSS] Alternate stylesheet selection is not sticky
*** Bug 227660 has been marked as a duplicate of this bug. ***
The same applies to a group of pages which use the same set of
alternate style sheets.  If you follow links within that group
of pages mozilla jumps back to the default style sheet after
each link.

And even a simple "reload" makes mozilla jump back to the default
stylesheet, which is very annonying if you are busy editing a
non-default stylesheet.
How about setting a cookie for each site one changes the style at? Many sites do
this anyway to achieve the same result.

Alternatively, chosen styles could be stored as a list, which is compared to
available styles when a page is loaded (I'm guessing this would be damn slow)
Pretty please for Firefox 1.0?
*** Bug 252925 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0RC1?
Not a blocker for RC1, although patches would be nice.
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Fixing this bug properly is dependent on bug 83663, and, practically speaking,
on bug 200930. We don't have a back end for doing style history, and we need to
have a more standardized way of switching style before we can reasonably hook
into one. (bz's working on this) You can probably use JavaScript to approximate
persistence between back-and-forth, but the whole bit about multiple tabs and
interacting with site JS switchers complicates things. It's not ideal, but I'd
do this by
   - setting a _global_ lastSelectedStyleTitle on every page unload
   - on every page load,
     IF lastSelectedStyleTitle is one of the styles on the new page,
     calling the select-alternate-style function with lastSelectedStyleTitle
     as its argument
You would want to do this by cleaning up the style switching functions a bit and
organizing them into a class that can have a persistent data member
(lastSelectedStyleTitle).
In case it's relevant, the JS offered at
http://www.alistapart.com/articles/alternate/
(http://www.alistapart.com/d/alternate/styleswitcher.js) seems to pick up
changes made using Firefox's built-in style switching UI.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Fantasai, in case you are going to add persistent style sheet support, think of
the following things:

- If you go to a part of a site with different style sheets, where the selected
persistent style is not present, use the default style. This one is pretty
obvious :). Question here however is whether it should then reset its
persistence information, or remember it (but use the default where the selected
style is not present) until the user selects a different style. I think the
latter should be done.

- How can the user 'reset' the persistence information. I personally think it
would be a good idea to only persist the stylesheet if it is a different one
from the default one. So say 'classic' were the default of a page, only use
persistence if 'modern' is selected, and when 'classic' is selected again after
that reset the persistence information.

- While using Jeff's extension, when I use the on-site stylesheet selector on
http://map.tni.nl/main/styles.php, nothing happens. That's why the previous
issue of being able to reset is important. Another related question is, should
the persistence information automatically reset when the site's default
stylesheet changes? I think that might be a good idea, it would both fix on-site
stylesheet selectors like the one mentioned, and when the author of a site would
create a new style and make it the new default, it wouldn't go past the user
unnoticed. So aside from storing the chosen persistent style's name, you would
also store the default stylesheet's name to check whether that remained the same.

- How to combine the previous with the first issue then? I'd say, first check
whether the persistent style is present, and if it's not, use the default but
remember the persistence information. If the style is there, but the default has
changed, reset.

- It might be useful to somehow distinguish the default style sheet from the
others. Be it by rendering it as italic (tho' I think this will look ugly :)),
or always placing it at the top of the list. OTOH, I like it the way it is now.

- Where to store this persistence information? There is probably some good
internal place to store this, but what about storing it in a cookie? That would
allow a site to get direct feedback from the user when he selected a different
style, and cookies are actually quite fit to do the job as they're site-specific
and can even have a 'scope' path. There might be a privacy consideration though
(but I think not).

- The user should be given the ability to temporarily select a different style,
so without Firefox remembering it. For example by shift-clicking on the style.

These are the issues and questions I encountered using Jeff's stylesheet
selector extension in practice. I hope they will be useful in implementing and
tweaking the functionality of style sheet persistence, be it for the 1.0 release
of Firefox or after that :).

As a final note, it would be a shame if the stylesheet selector were to
disappear from the next release of Firefox. So I'm glad you're giving it
attention, fantasai :). Also, I'm looking forward to the additional
functionality ('No theme' on every site, etc).


~Grauw
Some sites apply "persistent" stylesheets (rel="stylesheet" rather than
rel="alternate stylesheet") if these are present in addition to alternate
stylesheets a "Basic Theme" entry is included in the stylesheet menu. In fact it
appears on sites with no alternative styles (the style switcher's icon doesn't
appear, but the area is clickable anyway (bug 251821)).
(In reply to comment #11)
...which would have to be taken into account when determining when/how to remove
stylesheets' persistance. I suggest "Basic Theme" is always shown and choosing
it causes the site's default style to be used persistently (i.e. user-selected
styles stop persisting); if another style (including "No Theme") is chosen, that
choice persists.
Greg: to clarify, 'No theme' means no stylesheets at all, except for inline
style= stuff (imho this should not include the style= either, but that's another
bug :)). 'Basic theme' means the basic stylesheet only (basic == not named). The
list of selecteable styles are the named styles (with a title= attribute), where
the default style is the one without an alternate attribute.

If you have the following stylesheet links:
<?xml-stylesheet href="/css/site.css" type="text/css"?>
<?xml-stylesheet href="/css/print.css" type="text/css" media="print"?>
<?xml-stylesheet href="/css/classic.css" type="text/css" title="Classic"?>
<?xml-stylesheet href="/css/modern.css" alternate="yes" type="text/css"
title="Modern"?>

Then No theme will select nothing, Basic theme will select both the site.css and
print.css style, and the 'Classic' named theme will additionally select classic.css.

Basically the 'Basic theme' should include stuff vital to the representation of
the site and present in all themes. For example if you have a CSS class .neg {
text-decoration: overline; } to indicate negative logic in <span
class=".neg">IORQ</span> that should be in the unnamed ('basic') style. If you
choose to style at all, the Basic theme is *always* applied. On top of that, the
named styles give you a choice between one or more layouts, of which one is
denoted as the default (because it hasn't got the 'alternate' attribute). That
is the way it works now, and that is the way it should work.

(end of lesson ;p)

My comment regarding persistence only considers about the named stylesheets
(those with a title attribute). It should handle the others exactly as it is
now. With the word 'persistent' I am NOT referring to the unnamed styles. It is
the named styles which show up as a list in the style selector and which really
change the site's layout. The issue is that if you select one of those other
than the default one, it should be 'sticky' aka 'persistent'.

So, 'Basic theme' is NOT the choice which should lead to 'resetting the
persistence' (unless there is no default stylesheet given and Basic theme is the
only choice apart from No theme). Better put: the choice which should lead to
resetting the persistence information should be the style which would otherwise
be selected by default. If there is a named stylesheet without 'alternate'
attribute, that is the one, and otherwise it is indeed the Basic theme.

I do think that if the user selects 'Basic theme' or 'No theme', that choice
should also persist btw, even though I not explicitly said so.


~Grauw
Thanks for all the comments, I'll keep them in mind for bug 83663. That's where
the back-end work will happen; this bug is just for the Firefox front end.
Please note that the "No Style" option, with the checkin of 253332, will disable
*all* author style, including 'style' attributes and <font> tags. Check out the
View > Use Style menu in a recent build of Seamonkey if you want to experiment.
(In reply to comment #13)
Sounds right to me :)

I think this raises the issue of how to denote which style is the default one.
Perhaps it could appear above the separator, with No Theme and Basic Theme.
Assignee: hyatt → fantasai.bugs
Blocks: 257608
*** Bug 279717 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
This issue effects me in particular with the ZDnet group of sites, which will
not display correctly under firefox 1.04 unless 'no style' is selected. Under
basic style, the text appears as blacked out blocks. It is very annoying to have
to manually change the style to no style each time a link redirects me to a
zdnet page.

On reading the comments above I would prefer a less automated solution. When the
user initiates a style sheet change, simply ask "Remember this choice?". People
don't change styles so often that this would be intrusive. If the user clicks
yes, ask "apply style to this page only?/apply style to all pages in this
site?". An "Advanced" button allowing direct editing of the ruleset should also
be provided.

Interesting thought of the day: I wonder if one of the filtering extensions
(adblock etc) could be used to modify a page to always use a chosen style sheet.
*** Bug 314804 has been marked as a duplicate of this bug. ***
*** Bug 316075 has been marked as a duplicate of this bug. ***
No longer blocks: 257608
Whiteboard: depends on back-end fix in bug 83663
I've written an extension that makes the stylesheet selection sticky. Parts of the code are ugly hacks and I'm not very experienced, but it could help you.

http://home.arcor.de/jonha/files/styleswitcher0_5.xpi
It hasn't been said previously here that an extension called Stylesheet Chooser was already able to do it. Unfortunately it isn't updated anymore, but a "Plus" version exists that supports Firefox 1.5, and which also reintroduces the styleswitcher button in the statusbar.
Mass edit: Changing QA to default QA Contact
QA Contact: davidpjames → password.manager
Hmm, looks like I used to be QA for a few non-Password Manager bugs too. Sorry about that.
QA Contact: password.manager → general
Does fantasai still plan to impelement this?
It's on my to-do list, but not very high. Certainly won't make it for FF3. If anyone wants to take over, I'm cool with that.
Isn't this easy to do now site-specific preferences are supported? http://developer.mozilla.org/en/docs/Using_content_preferences and it's currently used in browser/base/content/browser-textZoom.js to keep the text-zoom sticky.
We don't need bug 83663, we should just use the content prefs service, IMO
Assignee: fantasai.bugs → nobody
Severity: minor → enhancement
No longer depends on: 83663
Priority: -- → P4
Summary: [AltSS] Alternate stylesheet selection is not sticky → Persist alternate stylesheet selection using content prefs
Whiteboard: depends on back-end fix in bug 83663
Target Milestone: --- → Future
See Also: → 462352
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.