In the <guimenu>File</guimenu> menu. In the File menu.

Select <guimenuitem>Quit</guimenuitem> to leave. Select Quit to leave.

In docbook-css 0.2, the 'Quit' in this example would gain an arrow in front of it. That shouldn't appear any more. In the <guimenu>File</guimenu> menu, select <guimenuitem>Quit</guimenuitem> to leave. In the File menu, select Quit to leave.

Within a menuchoice, a guimenu followed by a guimenuitem will gain a seperating arrow, to emphasise the navigation action the user will typically make with the mouse. Select <menuchoice><guimenu>File</guimenu><guimenuitem>Quit</guimenuitem></menuchoice> to leave. Select FileQuit to leave.

Contents of the email element is simply rendered to look like a traditional HTML link, with the addition of surrounding cheverons. There is no behavior tied to this element. Please send a message to <email>localpart@hostpart</email>. Please send a message to localpart@hostpart.

The keycap element gains a background colour and raised borders in attempt to make it look a bit like a key on a physical keyboard. To try and stop the border dangling into the line bellow, the keycap text is smaller than the surrounding content. Press <keycap>F1</keycap> for help. Press F1 for help.

Click on <guibutton>Ok</guibutton> to continue. Click on Ok to continue.

The keycombo element is for grouping keycaps that the user needs to invoke 'together'. To try and emphasise this, we add a dash before the second, and subsequent, keycaps in the keycombo. Unfortunately, this content appears inside the border-styling of the keycap elements, rather that 'between' the elements. I should probably remove that dash. Hit <keycombo><keycap>ctrl</keycap><keycap>c</keycap></keycombo> to quit. Hit ctrlc to quit.

A citation just gets the typical square brackets fore and aft. As <citation>Al, et al</citation> mentions, As Al, et al mentions,

This makes use of the CSS quotes mechanism. I don't think that CSS automaticaly handles i18n issues (?), and docbook-css certainly doesn't, yet. <quote>Arrrr!</quote> exclaimed the pirate. Arrrr! exclaimed the pirate.

Currently, nesting empasis tags makes the text bold, as well as italic. I think tradition is to return to upright text in this case. Maybe the current styling should be changed to match. <para><emphasis>'plain' emphasis</emphasis>, <emphasis role="strong" >strong emphasis</emphasis>, <emphasis role="bold" >bold emphasis</emphasis>, <emphasis role="underline" >underline emphasis</emphasis>, <emphasis role="strikethrough" >strike-through emphasis</emphasis>.</para> <para><emphasis>Within already emphatic text, <emphasis>how</emphasis> do you turn up the volume?</emphasis></para> 'plain' emphasis, strong emphasis, bold emphasis, underline emphasis, strike-through emphasis. Within already emphatic text, how do you turn up the volume?

When the directory class is used, we add a '/' after the element content. This would be bad if the document already contains a trailing slash, and it also assumes unix-style paths. See <filename>README</filename> within <filename class="directory" >src</filename>. See README within src.

A <sgmltag>tag</sgmltag> without a <sgmltag class="attribute" >class</sgmltag> looks dull. More fun are <code><sgmltag class="starttag" >sgmltag</sgmltag>sgmltag<sgmltag class="endtag" >sgmltag</sgmltag></code> elements with classes <sgmltag class="attvalue" >starttag</sgmltag> or <sgmltag class="attvalue" >endtag</sgmltag>. An empty <sgmltag class="emptytag" >tag</sgmltag> is also possible. We might want to talk about entities, like <sgmltag class="genentity" >amp</sgmltag>. XML may include <wordasword>processing instructions</wordasword>, like <sgmltag class="xmlpi" >xml-stylesheet</sgmltag>. A tag without a class looks dull. More fun are sgmltagsgmltagsgmltag elements with classes starttag or endtag. An empty tag is also possible. We might want to talk about entities, like amp. XML may include processing instructions, like xml-stylesheet.