Re: Possibly stupid question...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2004-08-29 at 11:27, 'D@7@k|N&' wrote:
> Since I have been working on the hardening tute, I've been doing so with
> the Docs Guide open, so I have an immediate reference for the tags that
> I should be using.  I noticed something, that other people may have
> noticed, but I don't really understand the point of.  The
> <guibutton></guibutton>, <guilabel>, <guimenu>, <guimenuitem>,
> <application>, and several other tags, all seem to just make the text
> bold.  Is there a reason that these aren't more defined?  (Something
> really could would be to id the guimenu buttons, and have the tag insert
> the graphic for that button, etc.)  Without the more differentiating
> characteristics, what is the point of using different tags?

/me is kind-of repeating what Paul said, but ...

The styling (bold, etc.) is in the stylesheets, and has no meaning to us
on the markup side.

The markup should be contextual, only.  We never do things so that they
"look" a certain way in one of the many ways to render a document.  
This lets us focus on the content and not the formatting, and the
separation of the layers lets us have more global control.  We want all
<guibutton/> tags to now make a button-like appearance using CSS in
HTML, but not PDF, we can do that in the XSL and the CSS.

The button-effect was done in Red Hat manuals in the past, and we could
do that if it was worth it.

Here's an example to illustrate the value of proper content tagging and
not worrying about the presentation:

You are writing a tutorial for using GTK+ to create some onscreen
widgets.  It includes <programlisting> blocks with lots of sample code,
some <screen> blocks with commands for installing packages and tweaking
configuration files, and several textual descriptions of a GUI, talking
about the <guibutton>s, <guilabel>s, and <guimenu>s.

One of your readers is very visually impaired.  She has to use two huge
monitors set at 640x480 with large fonts and contrasting colors, and has
both a regular and Braille keyboard, and a Braille printer for output.

If your content was marked up with enough proper detail, an XSLT could
be used to get the XML ready for a custom low-vision reading system that
would:

* Take the <programlisting> blocks and send them intact to the reader's
monitor and Braille output printer (both configured to receive STDOUT);
this lets her see them on screen and confirm what she reads with Braille
output.

* Take the <gui...> elements and display them in a properly nested
fashion to STDOUT, similar to the way they give us File -> Edit -> Foo,
that could be a visually descending tree done in a very big font.

* Take the <screen> and <computeroutput> tags and send that content
straight to the console and Braille keyboard (STDIN), while teeing it to
STDOUT for confirmation via monitor and Braille printer.

Does that help?

- Karsten


-- 
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115  5F1B D992 0E06 AD0E 0C41



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Red Hat 9]     [Yosemite News]     [KDE Users]

  Powered by Linux