Open Bug 83663 Opened 23 years ago Updated 2 years ago

back-end implementation to store Alternate style sheet settings [AltSS]

Categories

(SeaMonkey :: UI Design, enhancement, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement

Tracking

(Not tracked)

Milestone:
Future

People

(Reporter: mikko.rantalainen, Unassigned)

References

Details

(Whiteboard: [Hixie-P0])

Attachments

(1 file)

pseudo-code for fantasai@escape.com 2001-07-01 03:27
3.54 KB, text/plain
Details 
When visiting a site and user selects alternative style sheet from View-Use
Style Sheet and goes through a link next page uses default style sheet even it
provided similarly named style sheet. For example page 1 could provide style
sheets "Hicolor" (default) and "Monocrome". Now if user selects "Monocrome"
style, display is updated accordingly, but when user clicks a link to go to page
2 mozilla uses "Hicolor" instead of expected "Monocrome". Mozilla should use
identically called style sheet instead of default one if one exists.

Some things to consider: if site A provides style sheet "Style2" and site B
provides similarly named style sheet should we use that instead of default one?
How do we detect site change? Or should mozilla use same [different from
default] stylesheet only if that's linked to same resource? This would limit
support to linked style sheets only. See bug 63213.
ccing mpt for UI-type comments.  status => NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Certainly, style sheet selection (like text size selection, and encoding
selection) should persist from page A to page B in the same window (or in a link
spawned from that window), where a style sheet with the same name *or* URL is
offered for both those pages. If it didn't, that would be annoying. (In the edge
case where page B offers both a style sheet with the same name but a different
URL, and a style sheet with the same URL but a different name, use the one with
the same URL.)

This behavior should be overridden where I have already been to page B and
chosen a different style sheet -- so I can choose one style sheet for page A and
another for page B, and flick between them without having to constantly change
the style sheet settings. That means that any non-default style sheet (and
encoding, and text size) selection for each page should be stored in the global
history entry (and, ideally, bookmarks entry) for that page. However, that
should be filed as a separate bug which does not need to block this one.
Depends on: 63213
Interesting suggestion...  The discussion around alternate stylesheets takes 
place under bug 6782. Marking dup.


*** This bug has been marked as a duplicate of 6782 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
*** Bug 91109 has been marked as a duplicate of this bug. ***
I think that this is really a dupe of bug 51692.  Seems that 6782 is more about 
gui additions while this is about remembering the altSS choice for the site.  
This is just for reference.


Splitting up bug 6782 ("UI for alternate and user stylesheets").

"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

Comments from bug 6782:


------- Gervase Markham <gerv@mozilla.org> 2001-06-28 03:49 -------

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


------- fantasai@escape.com 2001-06-28 12:01 -------

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


------- Gervase Markham <gerv@mozilla.org> 2001-06-29 15:00 -------

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

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

Gerv


------- fantasai@escape.com 2001-07-01 03:27 -------

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



------- James Lariviere <jameslariviere@yahoo.com> 2001-07-01 05:29 -------

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.


------- Gervase Markham <gerv@mozilla.org> 2001-07-01 08:09 -------

> 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


------- fantasai@escape.com 2001-07-01 08:36 -------

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.


------- Pierre Saslawsky <pierre@netscape.com> 2001-10-11 20:09 -------

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


------- fantasai@escape.com 2001-10-11 22:35 -------

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


------- Sascha Claus <SC_LE@gmx.de> 2001-10-12 10:18 -------

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


------- Pierre Saslawsky <pierre@netscape.com> 2001-10-12 15:31 -------

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.


------- Jesse Ruderman <jruderman@hmc.edu> 2 2001-10-15 21:37 -------

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


------- Sascha Claus <SC_LE@gmx.de> 2001-10-16 00:03 -------

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


------- Jesse Ruderman <jruderman@hmc.edu> 2 2001-10-16 14:52 -------

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.


------- _basic@yahoo.com 2001-10-16 21:40 -------

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?


------- Jesse Ruderman <jruderman@hmc.edu> 2 2001-10-18 12:48 -------

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


------- fantasai@escape.com 2001-10-19 14:08 -------

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


------- Pierre Saslawsky <pierre@netscape.com> 2001-10-19 14:40 -------

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.
Status: RESOLVED → REOPENED
Component: Style System → XP Apps
Keywords: mozilla1.0
OS: Linux → All
Hardware: PC → All
Resolution: DUPLICATE → ---
Blocks: altss
*** Bug 51692 has been marked as a duplicate of this bug. ***
There's a difference between cookies and automatically sharing style sheet 
choices across all sites.  Cookies allow a group of sites to collude to track 
you across only those sites.  Automatically sharing style sheet choices:
- would allow a site to figure which other sites you have visited and chosen 
style sheets for.
- might allow a site to gather enough information about your style sheet 
choices on other sites to distinguish you from other users.
Jesse, would you please reply to [fantasai@escape.com 2001-10-19 14:08]?
You keep complaining that remembering a style selection "between sites" would 
compromise privacy, but you aren't saying how, you aren't even saying what you 
mean by that, and you aren't offering any alternatives. Repeating yourself isn't 
getting us anywhere; you need to explain.

Suppose netscape.com had stylesheets "blue 1" and "mozmodern", and slashdot.org 
had stylesheets "circuitboard green", "osdn", and "light".  Also suppose that I 
visit these sites, and select "light" at slashdot.

Then I go to a malicious site, which first gives me a page with the 
stylesheets "blue 1" and "mozmodern".  These might be the same as on 
netscape.com, in which case the site would use getComputedStyle to determine 
which on Mozilla uses, or they might be on the malicious site's server, in 
which case the server operator could look at logs to find out which one Mozilla 
uses.  The site then forwards me to another page and does the same 
for "circuitboard green", "osdn", and "light".

Since I selected "light" while I was on Slashdot, the malicious site is now 
able to tell that I read Slashdot, and probably regularly since I bothered to 
change stylesheets.

The solution is to limit style sheet choices in the same way we limit scripts: 
as long as two pages are on the same server, same port, and same protocol, 
style sheet choices should be remembered.
I suggested, Mozilla should remember title *and location*. So there is only a
problem if a site offers the same set of SSs and gets the current SS with JS.
But then this must come to the server, e. g. via hidden forms.

As I said: An option to turn on/off this would be useful.

What do you mean by "So there is only a problem if a site offers the same set 
of SSs and gets the current SS with JS"?  That's like saying that pop-up 
windows are only a problem when a site calls window.open.
When Mozilla remembers the title (specified by <link> element), then there must
be a SS with the same name/title, or Mozilla won't load it. My idea was to
remember title *and* location.
The malicius site out of your example would have to link the stylesheets from
netscape.com and slashdot.org, not only offer SS with the same titles. When the
site uses getComputedStyle, the result must be transmitted to the server.

> That's like saying that pop-up 
> windows are only a problem when a site calls window.open.

1) The site must offer the same SS at the same location (same URI).
2) The site must use getComputedStyle (or anything else).
3) The storing of AltSS must be enabled. (A lot of people don't like this idea :-/ )

I think storing style sheet choices is a great idea, it's just that I think 
each choice should only be remembered for a single hostname because I don't 
want someone who sends me a URL over instant messenger to be able to find out 
that I read slashdot.
Hello to all:

It seems to me that both Sascha and Jesse are on the same page both want SS to 
be remembered by location == hostname / title.  I think it would be silly to 
remember styles that cross over servers or domainnames if virtual servers are 
used.  Hence the best solution is to have a style sheet history that is 
perticular to a hostname (location). Remember them by last selected, and if 
that is not available on some pages then just display what is availabe but keep 
the title in history.  If tricky or dumb web site developers change the uri to 
a perticular SS title then it wouldn't be the browsers responsibility to 
remember that.
> remembered by location == hostname / title

That the style selection should be based on both location and title has been, 
IIRC, undisputed since even before SC_LE@gmx.de joined the conversation.

Location should be resolved URI, not hostname. Host != site, whatever the 
History people may think. We're not going to guess sites' URI boundaries here; 
we can do better than that.

If we're going to have a server/port/protocol check for security purposes, it 
should be just that and not interfere with the rest of the logic. Also, if we 
are going to have such a check, it should be optional and off by default: style 
selection, IMO, doesn't pose a significant privacy problem, and this 
type of restriction cripples the selection memory on sites that span multiple 
servers, such as Yahoo, About, eBay, mp3.com, and a slew of others.
Severity: normal → enhancement
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Blocks: 108391
I think it would be both easier and more efficient if we used only one style 
list--used a 'dropped' attribute instead of a separate dropped styles list. In 
this case, the date on the stylesheets would also need to be updated when a 
style is dropped in favor of Page-Defined Style.

re: multiple windows viewing the same site
Should changing the Style on one window affect them all?
IMO, a change in one window should affect the history in all of them, but it 
shouldn't trigger a reflow. The new style should take effect on the next page 
load rather than immediately.
*** Bug 111937 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0 → mozilla1.2
*** Bug 122985 has been marked as a duplicate of this bug. ***
Bulk moving Moz1.2 bugs to future-P2. I will pull from this list when scheduling
work post Mozilla1.0
Priority: P3 → P2
Target Milestone: mozilla1.2 → Future
I think a nice way to do this is to simply store a list of recently selected
location/title combos and for those really paranoid about privacy you could
implement a pref to break JS API to query SS. This way only original stylesheet
provider could get info about which SS you're using but they could do that
anyway because they have the logs. I mean window.open is already "broken" if the
user decides so and I haven't heard anybody being unhappy with it (I don't care
if pop-up advertisers are unhappy). Another way to solve this is to allow
paranoid people always load *all* linked style sheets no matter if they are used
- how's that for wasting bandwidth.

> always load *all* linked style sheets

This is what we already do....  All linked sheets are loaded; the alternate ones
are deferred to after the main document has been loaded and parsed, while the
non-alternate ones are loaded synchronously.  Otherwise stylesheet switching
would take forever... :)

So from a security standpoint this is a non-issue.


adding cc, and i don't think this is enhancement...
> i don't think this is enhancement

I assume you mean that browsers should be expected to do this,
that while the spec AFAIK doesn't state it directly it should
be read between the lines as the only sensible interpretation 
of multiple linked stylesheets.  If that's what you mean, I
agree, but it is nevertheless an enhancement because AFAIK _no_
current browser already does this correctly.  Mozilla will be
leading the way and enhancing the state of the art in browser
technology on this point, methinks.  If IE or Opera already
does this, nobody has told me about it.  Even more significantly,
no previous incarnation of Mozilla or Netscape had this right, 
either.  That doesn't mean Mozilla shouldn't implement this -- 
it absolutely should -- but it does make it an enhancement.  

Being an enhancement does not necessarily imply that it
is a gratuitous feature, only that it's something we've
never done before.  
*** Bug 137228 has been marked as a duplicate of this bug. ***
From comment 25: "it is nevertheless an enhancement because AFAIK _no_
current browser already does this correctly."

Konqueror 3.0 and Galeon 1.2.1 both do this (although Galeon appears to render
using the preferred stylesheet while loading, then switch to the previously
selected one).
*** Bug 142060 has been marked as a duplicate of this bug. ***
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: REOPENED → NEW
Priority: P2 → P3
*** Bug 153158 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0 → mozilla1.1
*** Bug 159387 has been marked as a duplicate of this bug. ***
*** Bug 162442 has been marked as a duplicate of this bug. ***
*** Bug 163391 has been marked as a duplicate of this bug. ***
*** Bug 173799 has been marked as a duplicate of this bug. ***
Whiteboard: [Hixie-P0]
*** Bug 178924 has been marked as a duplicate of this bug. ***
*** Bug 180779 has been marked as a duplicate of this bug. ***
*** Bug 182876 has been marked as a duplicate of this bug. ***
Now, this thread is discussing very subtil problems about the alternate
stylesheets. I think the main issue somehow got forgotten. As the subtile
problems seem to be fixed first, and the main issue has to wait some years, I
recommend to those, who need the feature now, to write following code into the
onload and unload event handlers. Not nice, but it works and without cookies.

function myUnload () {
if (navigator.appName.match(/netscape/i)
  for(i=0; (a = document.getElementsByTagName("link")[i]); i++)
    if(a.getAttribute("rel").indexOf("style") != -1 &&
       a.getAttribute("title") && a.disabled == false)
    {
        top.name="stylesheetname"+a.getAttribute("title");
    }
}
function myOnload (d)
{
  var x = top.name.match(/stylesheetname(.*)/i);
  if (navigator.appName.match(/netscape/i) && x && x.length>1)
      selectStylesheet(x[1]);
}
Comment #27
This I did not know.  Perhaps I should upgrade Galeon occasionally :-)

Comment #38:  
Clever, but we've already been down the road of convincing page authors to
jump through obscure hoops because of browser inadequacies, and I don't think
most of us want to go back to that way of doing things.  I realise Opera and 
IE don't do this right either yet (see my earlier comment), but they should,
and so should Mozilla, and then page authors won't HAVE to load up with tons
of javascript just to give the user some style options.
Regarding the controversy over spanning domains:  I can see both sides of
thise one.  Not storing them across hostnames would break sites with more
than one server (_lots_ of sites these days), so that's bad, but it's still
better than what we have now.  On the other hand, if we do persist the user's
choice across hostnames, there's a (minor IMO) privacy issue, but _only_ if 
the user takes advantage of the (currently mostly non-working) feature, so
again it's still better than what we have now.  

What about Yet Another Paranoid Privacy Pref, "Reveal stylesheet preferences
across sites"?  The default value wouldn't matter, because both sets of users
who would care (those who want alternate styles remembered and those who are
careful about privacy) already go through the prefs and change stuff.  People
who don't change settings aren't going to be affected by this either way.

Or we could _attempt_ to determine whether two hostnames are part of the same
overall site, but that gets hard, particularly in the country-code TLDs.

Personally, I want slashdot and sourceforge (both part of OSDN) to be able
to provide the same set of style options, and if I choose on one, I want 
that choice to persist on the other.  But I can see the other side.  A pref
is probably in order, IMO.  But _either_ implementation improves on the
current situation.
> Regarding the controversy over spanning domains:  I can see both
> sides of thise one.

Remembering the stylesheets on a per hostname basis can be later extended. The
other way roud is difficult. It is the minimum requirement anyway, that must be met.

> What about Yet Another Paranoid Privacy Pref, "Reveal stylesheet
> preferences across sites"?  The default value wouldn't matter,
> because both sets of users

I think ist is true, the privacy issue is relevant. Especially, if stylesheet
say "Big Letters". Ensurances will be very keen on such data. What could be done
as a comprmise is to work on a per hostname basis, but extend the caching of the
style preferences. So, I will have to ajust the style for new sites,
but I will not have to reajust them, when cache data expires. This later case
might be in practice more often and anoying, than the crosshostname situation.

> I think ist is true, the privacy issue is relevant. Especially, if stylesheet
> say "Big Letters". Ensurances will be very keen on such data.

Oh, for goodness sake. 

Any insurance company which has time to write a program which looks at the 404s
for stylesheet requests on its webservers, checks the referrers, goes to the
referring sites, downloads their style sheets and parses them to see if that
person (who they would need to actually identify in another way, and see if they
were actually a customer) has a possible disability which they are not revealing
is one that's about to go bust because it wastes its employees time. 

Can we please get real about this tiny, tiny potential privacy leak, let the
ultra-paranoid build their own browser which has different behaviour (market
niche for Beonex, perhaps), and get on with actually _fixing_ this bug instead
of talking about it?

Gerv
1. There wouldn't be a 404 since if the style set doesn't exist on the new page,
there would be no stylesheet to fetch (and indeed if the style sets were
different then it would be pointless to try to use the same style set).

2. Even if there was a way to get information that way, you'd get a lot more
information just from the referrer itself. And that is something Beonex can
already turn off.

Gerv is right that it is ridiculous to be talking about privacy leaks here.
*** Bug 186026 has been marked as a duplicate of this bug. ***
Removing mozilla1.1 keyword; clearly, it didn't make it. ;) Oh, and adding self
to CC list...
Blocks: 216537
*** Bug 243841 has been marked as a duplicate of this bug. ***
(In reply to comment #18)
> re: multiple windows viewing the same site
> Should changing the Style on one window affect them all?

Yes.

> IMO, a change in one window should affect the history in all of them, but it 
> shouldn't trigger a reflow. The new style should take effect on the next page 
> load rather than immediately.

No, immediately, i think. When i change the style, i want to see the effect --
on all pages.

Keks
I don't think it should change other pages. When you do font zoom it doesn't 
affect other pages. This should be conceptually the same.
(In reply to comment #48)
> I don't think it should change other pages. When you do font zoom it doesn't 
> affect other pages. This should be conceptually the same.

Font zoom ist temporarily, style selection is permanent (it should be permanent)
and it affects the other pages -- after reloading them. But why require a reload?

Yours, Keks
(Sorry for my english! ;) )
No, it should not cause a reflow in all pages because you might, in fact, want
to have different style sets selected on different pages. A prime example would be
switching between "show differences" and "normal", where the first would highlight
INS and DEL and the other would just hide DEL.
How exactly is this done in Konqueror? It is supposed to have the perfect
implementation for this problem, if I believe the reviews and comments I have
read (don't have Konqueror myself). Can that behaviour not just be copied?
Depends on: 200930
Product: Core → Mozilla Application Suite
This bug has a status NEW and doesn't have any patches associated with it but it
seems to be partially fixed because bug 216537 which depends on this bug also
seems to be partially fixed because Firefox now remembers selected stylesheet
(although bug 216537 also ha a status NEW). It is a bit unclear to me but maybe
I haven't noticed something which is obvious for everybody.

Anyway I would like to write that Firefox remembers stylesheets when they are
linked via <link> tag but when the same thing is done via XML declaration (like
on site http://egree.jogger.pl ), it doesn't work.
Maybe you should notice, that this bug is for Mozilla Suite.
Yes, it is, but it blocks bug 216537, so IMHO stylesheet switching shouldn't
work in Firefox if this bug isn't fixed (from comments for bug 216537: "bug
83663. That's where the back-end work will happen; this bug is just for the
Firefox front end.").
I've got FireFox 1.0.3 and it don't remember the alternate style sheet, as much
with the link element as with the xml-stylesheet element.
My Firefox 1.0.3 for GNU/Linux does remember it on site http://aviary.pl/site .
Guys, could we cut the spam?  Firefox has a sorta-fix for this that doesn't
really work quite right but works in some cases and is done completely in the
UI.  This bug is about doing this in the back end and doing it right, which
blocks Firefox doing it right.
You talking to me? ;) If so, then yes, of course :).
What's "working" is probably the site recording the choices you make through the
FF UI and remembering them through its own JavaScript. A lot of JS style
switchers have this side-effect. It has nothing to do with Firefox or Mozilla
remembering anything.
Blocks: majorbugs
No longer blocks: majorbugs
There is an extention that work, it should be integrated to FireFox, this would
solve this bug :
https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&numpg=10&id=192
Tweaking the summary per comment 57 and bug 216537 comment 14 (was: Alternate style sheet setting not stored [AltSS]).
Summary: Alternate style sheet setting not stored [AltSS] → back-end implementation to store Alternate style sheet settings [AltSS]
Assignee: dbaron → jag
QA Contact: ian
No longer blocks: 216537
See Also: → 462352
Folks, the developer assigned to this (jag) apparently hasn't been active in Bugzilla since April 2011. Can this bug be reassigned?
Flags: needinfo?(jag-mozilla)
Sure, but note that this is not a bug for Firefox but for an entirely different product, in case that matters for your interest in it.
Assignee: jag-mozilla → nobody
Flags: needinfo?(jag-mozilla)
Cool, thanks Boris.

BTW, I noticed that jag is assigned to quite a few other bugs (mostly for SeaMonkey, but about a third of them for Core) as well: https://bugzilla.mozilla.org/buglist.cgi?emailassigned_to1=1&email1=jag-mozilla%40jag.dreamhost.com
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: