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
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.