From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4+) Gecko/20011003 BuildID: 2001100303 It would be nice if there were an item on the links toolbar for the user to choose between linked alternate stylesheets. The button becoming enabled would be a nice visual indication to the user that alternate stylesheets are actually available on a page rather than having to guess and look View->Use stylesheet on the off chance.

I second this. Good idea. Marking NEW cause I can't find a dupe.

A test case is http://www.webstandards.org/css/winie/altstyledemo.html The view -> Use Style Sheet menu works great in Mozilla, but it would be nice to add it to the More menu on the Links toolbar, perhaps as Alternative Styles or Other Style.

Huh? I recommend a WONTFIX on this one. I don't see any reason to have the same menu appear in two different places on the chrome. I'll leave mpt to judge, however.

Wontfix. Several reasons: * The Links Bar is for navigation, not for changing the display of the page. * Many pages will have alternate style sheets but will not have LINK elements, so that the Links Bar will not be present. As such most people would rely on `View' > `Use Style' instead, so having a similarly accessible menu in the Links Bar would be a waste of time. * The fact that styles are implemented using LINK is an implementation detail which would seem absurd to a user not familiar with HTML. A menubutton for switching style sheets should, however, be one of the optional buttons available for the Toolbar once we get a customizable Toolbar.

Matthew, it looks like we're in agreement that a menu button should be available for switching style sheets. The problem with "View -> Use Stylesheet" is that there's no obvious indicator to the user that there may be additional stylesheets. A menu button takes care of that problem quite nicely, if it becomes enabled only when multiple style sheets are available. I'd suggest that the logical place for this menu button is on the links toolbar. This seems parallel usage from the user standpoint. Link rel="alternate" generates the "Other Versions" item from the More menu. Why shouldn't alternate stylesheets generate a similar item? Changing styles can create significantly different versions. I don't think most users would notice the difference between changing the style sheet and going to a new page. Since both alternate and alternate stylesheet look like changing pages, I think they should be grouped together. There's no reason the links toolbar couldn't appear when multiple linked stylesheets are available. If you continue to disagree, despite these terrific arguments :-), I'd suggest changing the summary to "Alternate Stylesheet should appear on a toolbar", leaving it open, and directing it to whatever component will be for the customizable toolbar. That way the desire for an alternate stylesheet menubutton won't be lost.

Looks like this is being worked on in several other bugs as well. See bug 6782 and bug 38521.

Through comments on bugs 87428 and 2800 we came to an agreement that stylesheets would not be shown on the link/site navigation toolbar. Having an easy way to switch is good, but the link toolbar is for navigation only, so it should go somewhere else.

guess we should get bug 102991 fixed soon. Calling it link toolbar suggests that stylesheets refered via <link> should be on the toolbar.

The name "link toolbar" is under debate. Considerations include "Site Navigation Toolbar" to better describe, to normal people, what the toolbar is for. MPT is right for marking this WONTFIX. Adding a stylesheet selector would be like adding a font selector to the link toolbar, i.e. out of place.

UI for alternate stylesheets should be discussed in bug 6782; in the (unlikely) case that that bug requires adding a button here, so be it. *** This bug has been marked as a duplicate of 6782 ***

Perhaps, but if you called it a "Site Toolbar", rather than a "Site Navigation Toolbar" it would fit in perfectly :) I'd suggest having site specific stuff in one toolbar would make for quite a nice UI, rather than scattering it throughout various levels of the UI (either View->stylesheet or moving it to any other toolbar currently in Moz, if it doesn't belong in the 'links toolbar' I can't see how you can suggest it should go on the other toolbars which all perform general rather than site specific functions). Bah, midair collision and the bugs resolved again. This bug touches too many things and I haven't got time to touch all those other bugs. I still think having a stylesheet button on a "site" button is a good idea though.

I am in favour of this move, for several reasons: 1) As Tim says, site authors currently have to say on their page: "Hey! I have alternate styles" because no-one is going to check their view menu every page on the off-chance. Using the Site Navigation Bar (which might need renaming to something a touch more general) to provide UI for changing author stylesheets would solve this problem nicely. 2) Other alternative versions of the page, such as translations, already appear on the Site Navigation Bar. MPT has said that the current two dropdown menus are poorly organised. He may well be right. Part of the new solution could be an "Other Versions" menu, which had translations, PDFs etc, and alternate style sheets. The argument that "The Site Navigation Bar is for site navigation" is an invalid one - it's _currently_ just for that. That fact is not a reason why this situation should not change. Gerv

As this issue seems to span multiple bugs I've posted a post in n.p.m.ui entitled '"Link" Toolbar purpose, UI and some added tabbrowser fun.' Perhaps it is more appropriate to have a discussion there and come back to the specific bugs with resolutions, rather than scattering stuff all over bugzilla?

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: ------- Matthew Thomas (mpt) <mpt@mozilla.org.uk> 2001-10-06 09:01 ------- Alternate style sheets have nothing to do with navigation, so bug 103062 is a wontfix, not a duplicate. Removing dependency on bug 103053. ------- Paul McGarry <mcgarry@tig.com.au> 2001-10-09 21:29 ------- 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 102991 is the bug on renaming the "Link"/"Site Navigation Toolbar" toolbar. ------- norton@w5ac.tamu.edu 2001-10-10 09:47 ------- 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. ------- Gervase Markham <gerv@mozilla.org> 2001-10-10 09:58 ------- 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 ------- norton@w5ac.tamu.edu 2001-10-10 10:25 ------- 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? ------- Gervase Markham <gerv@mozilla.org> 2001-10-10 10:41 ------- 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 ------- Jonas Sicking <sicking@bigfoot.com> 2001-10-10 10:59 ------- 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. ------- Tim 'Tool-Man' Taylor <tim@tool-man.org> 2001-10-10 20:02 ------- > 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. ------- Paul McGarry <mcgarry@tig.com.au> 2001-10-11 00:57 ------- 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. ------- Braden <braden@endoframe.com> 2001-10-11 11:50 ------- 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. ------- Tim 'Tool-Man' Taylor <tim@tool-man.org> 2001-10-11 18:02 ------- > 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. ------- Pierre Saslawsky <pierre@netscape.com> 2001-10-11 20:09 ------- 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 ------- Ricky Webb <ricky@thewebmage.com> 2001-10-25 12:00 ------- Like I said in [bug 106510], I think alternate style menu should be placed in the Site Navigation Bar.

Ok, I've read all the comments, and thought about this some more, and it's still wontfix. As far as this bug is concerned, it does not matter what the bar is called. To the non-geek user, the things which appear in the bar (on 99 percent of the occasions when it appears at all) are for navigation. They take the user to a different URL. The text in the address field is different after clicking any of the links. Implying that changing style sheets was at all similar to this navigation, by putting its UI on the same bar, would be wilfully misleading. And on those pages which do have alternate style sheets, there is no particular likelihood that such pages will support LINK navigation at the same time. Most pages which support LINK navigation will not have alternate style sheets, in which case the style sheet button would take up valuable space that could be used for showing a few more uncropped characters of the titles for each navigation link. And many pages which have alternate style sheets do not support LINK navigation, in which case displaying the entire Links Bar just to show a Style menu would be an extreme waste of space. The desire to include alternate style sheets in the Links Bar seems to be partly a result of contributors thinking like HTML parsers (oh, this is a LINK element! I know where that goes ...) instead of thinking like users, and partly a result of contributors trying to work around the fundamental brokenness of Navigator's toolbar structure (the same brokenness which hides the Home button on the Personal Toolbar, and clutters component buttons into the status bar). There should be an optional menubutton for changing the text size of the page; but it should not be on the Links Bar, it should be on the main Toolbar. There should also be an optional menubutton for changing the encoding of the page; but it should not be on the Links Bar, it should be on the main Toolbar. And yes, there should be a menubutton for choosing the style sheet of the page (one which glows when such style sheets are available); but it should not be on the Links Bar, it should be on the main Toolbar. This bug is rather long, so those interested in implementing a `Style' menubutton for the Toolbar please do so in a new bug which depends on bug 15144. (Such a button wouldn't be shown by default, but I'd turn it on as soon as it was implemented because I like geeky stuff like that.:-)