MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

Hint Technically speaking, you can declare as many app bars as you want in whatever pages you want,
and they’ll all be present in the DOM. However, the last one that gets processed in your markup will be
the one that’s topmost in the z-index by default and therefore the one to receive events. Windows does
not make any attempt to combine app bars, so because page controls are inserted into the middle of a
host page like default.html, an app bar in default.html that’s declared after the page control host
element will appear on top. At the same time, if the page control’s app bar is larger than that in
default.html, a portion of it might be visible. The bottom line: declare app bars either in the host page
or in a page control, but not both.
App Bar Basics and Standard Commands
As I just mentioned, an app bar can be declared once for an app in a container page like default.html or
can be declared separately for each individual page control. The HTML AppBar control sample does the
latter, because it provides very distinct app bars for its various scenarios.
Scenario 1 of the sample (html/create-appbar.html) declares an app bar with four commands and a
separator:
This appears in the app as follows, using the ui-light.css stylesheet, in which we can also see a tooltip,
a focus rectangle, and a hover effect on the Add command (I placed my mouse over the command to
see all this):
In the markup, the app bar control is declared like any other WinJS control (this is becoming a habit!)
using some containing element (a div) with data-win-control="WinJS.UI.AppBar". Each page in this
sample is loaded with WinJS.UI.Pages.render that conveniently calls WinJS.UI.processAll to
instantiate the app bar. (It is also allowable, as with other controls, to create an app bar
programmatically using the new operator.)
278