Paul McGarry Reporter
	Description • 23 years ago

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.

	Cormac F
	Comment 1 • 23 years ago

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

	Tim Powell
	Comment 2 • 23 years ago

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.

	Christopher Hoess (gone)
	Comment 3 • 23 years ago

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.

	Matthew T (active 1999-2002) Assignee
	Comment 4 • 23 years ago

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.

	Tim Powell
	Comment 5 • 23 years ago

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.

	Tim Powell
	Comment 6 • 23 years ago

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

	Eric Hodel
	Comment 7 • 23 years ago

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.

	basic
	Comment 8 • 23 years ago

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

	Tim 'Tool-Man' Taylor
	Comment 9 • 23 years ago

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.

	Christopher Hoess (gone)
	Comment 10 • 23 years ago

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

	Paul McGarry Reporter
	Comment 11 • 23 years ago

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.

	Gervase Markham [:gerv]
	Comment 12 • 23 years ago

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

	Paul McGarry Reporter
	Comment 13 • 23 years ago

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?

	fantasai
	Comment 14 • 23 years ago

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. 

	Matthew T (active 1999-2002) Assignee
	Comment 15 • 23 years ago

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