This bug is to remove the "Page Style" menu from Firefox's View menu. The rationale is that this command had extremely low usage in our usability metrics coming from test pilot, especially relative to the surrounding very high usage menu items. This menu command will also not be available from the Firefox menu on Windows 7 and Vista.

For exsample, this page provides three style "Classic", "BMO","Dusk". If the menu removed, how can I choose them? Is alternative method available?

I sometimes use this feature, when I get hard-to-read webpages (too small fonts, text with too pale color - yes, it can't be solved by full zoom! -, and so on.) It is an important feature for accessibility even if it is not used frequently. Some alternative way are extremely required if the feature is removed from the "View" menu.

Alternate Style UI is necessary for us. Reference: Initial commit of alternate stylesheet support in Firebird. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=browser.xul&branch=&root=/cvsroot&subdir=mozilla/browser/base/content&command=DIFF_FRAMESET&rev1=1.191&rev2=1.192 Bug 253722 -- [AltSS] remove alternate stylesheet UI https://bugzilla.mozilla.org/show_bug.cgi?id=253722 Bug 257859 -- [AltSS] Re-insert Alternate Stylesheet UI https://bugzilla.mozilla.org/show_bug.cgi?id=257859 Bug 262065 -- [altss] temporarily disable altss statusbar icon until 83663 fixed https://bugzilla.mozilla.org/show_bug.cgi?id=262065 Bug 83663 -- back-end implementation to store Alternate style sheet settings [AltSS] https://bugzilla.mozilla.org/show_bug.cgi?id=83663 Bug 216537 -- Persist alternate stylesheet selection using content prefs https://bugzilla.mozilla.org/show_bug.cgi?id=216537 Bug 107023 -- [AltSS] Tracker for Alternate Style UI https://bugzilla.mozilla.org/show_bug.cgi?id=107023

https://addons.mozilla.org/img/uploads/previews/full/31/31792.png Is the "Page Style" toolbar button bundled like Context Style Switcher? Context Style Switcher :: Add-ons for Firefox https://addons.mozilla.org/en-US/firefox/addon/544/

I don't think the UI should be gone by the reason "low usage". The UI isn't needed for most people, I agree. But some users may need it for critical reasons such as comment 2. And the UI isn't useful due to bug 216537. Though, per-site setting mechanism was implemented for zoom, it is still not used for this UI. Therefore, I think that "low usage" is unfair for a reason of this bug's decision. Perhaps, it should be a customizable toolbar button with dropdown menu.

Disablility users can disable Web pages' fonts and color settings from Options > Content > Fonts & Colors. They can even set Minimum font size. Non-Average users can restore the ability to select alternate styles by installing Extensions. Is there a more convincing reason to keep the menu?

(In reply to comment #6) > Disablility users can disable Web pages' fonts and color settings from Options > > Content > Fonts & Colors. They can even set Minimum font size. > Non-Average users can restore the ability to select alternate styles by > installing Extensions. > Is there a more convincing reason to keep the menu? The option changes appearance of any webpage even if the page uses CSS reasonably (to provide regular accessibility). It's not always true that plain webpage without author-defined style provides best accessibility. In my case, disabling author-defined styles completely is an extreme action, when I got webpages which have very very hard-to-read appearance. If 90% of webpages I get require "without author-defined style" feature, I will use the option in the preference dialog to activate it permanently. However, actually I don't need to do it for most webpages now.

Then Develop > Disable Styles (like Safari) may be a good compromise. "Choosing alternate styles" feature is useless for bad Web pages.

Need not we respect these? http://www.w3.org/TR/html401/present/styles.html#h-14.3.1 > User agents should apply the author's preferred style sheet > unless the user has selected a different alternate. http://www.w3.org/TR/CSS21/conform.html#conformance > 5. If the source document comes with alternate style sheet sets > (such as with the "alternate" keyword in HTML 4), > the UA must allow the user to select which style sheet set the UA should apply. > A user agent that renders a document with associated style sheets > must respect points 1-6 and render the document according > to the media-specific requirements set forth in this specification.

(In reply to comment #9) > the UA must allow the user to select which style sheet set the UA should apply. But it is not necessary to be present in the View menu. Probably it should be changed to a customizable toolbar item as Nakano-san said. I didn't even notice that Bugzilla had alternative style sheets until I read comment #1 because there is no visual indicator of the presence at all. The current UI is not beneficial to anyone except specification lawyers.

(In reply to comment #10) > > the UA must allow the user to select which style sheet set the UA should apply. I'm sorry, The sentence is a failure of the quotation... I wanted to quote this. > User agents should allow users to select from alternate style sheets. > But it is not necessary to be present in the View menu. Probably it should be > changed to a customizable toolbar item as Nakano-san said. I agree with the bundle of the toolbar button. In that case, appropriate keyboard shortcut might be needed.

(In reply to comment #11) > In that case, appropriate keyboard shortcut might be needed. I don't think so because most useful shortcut key combinations are used already. Therefore, we should not consume remaining key combinations for such low usage functions.

(In reply to comment #12) > I don't think so because most useful shortcut key combinations are used > already. Therefore, we should not consume remaining key combinations for such > low usage functions. How to use "Page Style" toolbar button in keyboard-only browsing?

(In reply to comment #13) > (In reply to comment #12) > > I don't think so because most useful shortcut key combinations are used > > already. Therefore, we should not consume remaining key combinations for such > > low usage functions. > How to use "Page Style" toolbar button in keyboard-only browsing? It means that the UI should be in menu even if it'll be removed from [View].

(In reply to comment #2) > I sometimes use this feature, when I get hard-to-read webpages (too small > fonts, text with too pale color - yes, it can't be solved by full zoom! -, and > so on.) It is an important feature for accessibility even if it is not used > frequently. Ditto. I only use this once in a few weeks or even months, but when I use it, it's extremely handy.

(And no, I don't want a button for this on my toolbar.)

The UX team is very eager to get this bug landed over the next few days in order to make Beta 11. If anyone can get a patch for this bug posted soon, we will push hard for reviews and approval (even though this isn't blocking). You can view all of the related bugs to clean up the traditional menu bar here: http://areweprettyyet.com/4/traditionalMenu/

Comment on attachment 506638 [details] [diff] [review] Patch removes Page Style from View menu This patch is obsolete, see Bug #611568 for the patch that takes care of this.

Alex, has there been discussion about the fact that this would break CSS2.1 conformance, as well as WAI UAAG 1.0 checkpoint 4.14 conformance? Could you summarize that discussion here?

Comment on attachment 506652 [details] [diff] [review] Removes Page Style from browser menu There's a reference to pageStyleMenu in browser.js that needs updating, and browser_page_style_menu.js looks like it will also be broken by this. I think this particular removal is too controversial for Firefox 4, focus/effort is better spent elsewhere.

>Alex, has there been discussion about the fact that this would break CSS2.1 >conformance, as well as WAI UAAG 1.0 checkpoint 4.14 conformance? Could you >summarize that discussion here? Neither of those have been discussed. Our desire to remove the control is based purely on usage metrics, the implementation level nature of the UI, and (very peripherally) the fact that IE9 and Chrome have removed it as well. Also, this control has been gone on Windows Vista/7 for every beta of Firefox 4, and that hasn't seemed to cause much of an uproar.

Relevant link: http://www.w3.org/TR/WAI-USERAGENT/guidelines.html#tech-select-style-sheets Might also belong in the context menu with Page Info and other less commonly used (but useful when the situation requires it) functionality.

Perhaps we should leverage the openedWithKey attribute for cases where they might be using a screen reader?

(In reply to comment #24) > Might also belong in the context menu with Page Info and other less commonly > used (but useful when the situation requires it) functionality. Page Info is a function to provide about the pages meta info, isn't it? And according to usage rate of the function, context menu is too　common way to provide it by usage rate? So I thought that it is better to places the function of changing the page style in menu.

(In reply to comment #23) > Neither of those have been discussed. Our desire to remove the control is > based purely on usage metrics, the implementation level nature of the UI, and > (very peripherally) the fact that IE9 and Chrome have removed it as well. IE9 and Chrome's change are regression for users accessibility? And IE9 is beta now. When the release time, it may comes back... IE9 is not adequate to judge the function... > Also, this control has been gone on Windows Vista/7 for every beta of Firefox > 4, and that hasn't seemed to cause much of an uproar. I thought, its unimplemented to "Firefox button" is Firefox's implementation delays by discussed about this bug.

(In reply to comment #23) > the fact that IE9 and Chrome have removed it as well. Fact? My IE9 9.0.7930.16406 still have a Style menu item in a View menu and I can still select page styles from the menu. Are you using a more recent internal build?

> Also, this control has been gone on Windows Vista/7 for every beta of > Firefox 4, and that hasn't seemed to cause much of an uproar. ??? View-Page Style has NOT been gone in Firefox 4. Keyboard-savvy users will not care about whether the menu bar is displayed by default or not. Or are you planning to remove the menu bar completely as Chrome have done?

(In reply to comment #25) > Perhaps we should leverage the openedWithKey attribute for cases where they > might be using a screen reader? I think that could be a good compromise, show it when menu is triggered via keyboard, similar to Back/Forward menu items and other things that are useful for accessibility.

Ok, so I messed up on this bug. Comments #0 and #17 were both generated when filing and updating a large number of bugs in aggregate. And I read and then failed to reply to a number of comments about accessibility, up until fantasai's comment #22 (which consisted of a tired "wait, what?"). IE9 still has this in the alt-accessible menu, and we definitely should as well, using the openedWithKey attribute.

I don't think this is a screenreader / mouse-disabled accessibility issue. It's more general than that. The feature is also there for sighted, mouse-wielding users. So hiding it except when openedWithKey doesn't make much sense to me.

All other show-only-for-keyboard items described in bug 626825 have primary UI. Is there an alternate UI for mouse users to select page styles? That said, I will not oppose the change so strong because my concern was all resolved. - This change does no longer violate CSS 2.1. - Keyboard-only browsing is no longer blocked which is also useful for sighted users. - Now power-users can display the menu item by using userChrome.css. Even Extensions are not required. - The current UI is not so kind anyway (see comment #10). Probably it's the reason of low usage. More convenient UI should be delegated to Extensions, I think.

(In reply to comment #33) > - The current UI is not so kind anyway (see comment #10). Probably it's the > reason of low usage. More convenient UI should be delegated to Extensions, I > think. I agree that the current UI is not convenient. However, I think browser should provide the basically function about rendering pages like this.

I personally am using "Page Style" submenu on a DAILY basis to turn styles off and on. So, in my opinion, this cannot and should NOT be removed at all. In extremis, there should be an settings' OPTION to enable/disable this, OR the "Page Style" submenu items should be just moved to "Web Developer" submenu. NOT removed at all anyway. Even IE finally has "Page Style" submenu since version 8, and this was very positive and right improvement. Thanks.

Just wondering, would it be possible to just not display the menu item if there are no alternative styles available (not counting "No Style" as one)? BTW, would have been weird if Microsoft removed a feature they just introduced a version ago.

(In reply to comment #36) "No Style" should not be hidden even if other styles are not present (see comment #2 and comment #7).

Perhaps we should show it if certain accessibility tools are detected (e.g. High Contrast).

Someone else is going to have to take over this bug, no time in the foreseeable future to work on it. :(

Some discussion of this in bug 856787. It seems to me that this is mostly a developer tool. So perhaps the solution is to remove the menu altogether, and have something in the devtool window.