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?
-Charlie
On Sun, 2004-08-29 at 14: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?
The same as the point of any markup language... if a new stylesheet (XSLT?) is developed, you don't have to go back and re-markup all those tags to take advantage of it. Inserting "graphics" for buttons would mean that you have to have a graphic for any button that might come up, and if they change, well, that would be a full-time job just to keep someone on updating them.
In a rendering environment where you could (for instance) simply surround a selected group of characters with a gray frame with a black border, the result would look like a key, no? I think this is possible with Web browsers that support HTML 4.0 (i.e. most everything nowadays).
I'm not sure what the impact is on text browsing people provided you use a transformation like that; likely minimal. Using an actual graphics character, though, would likely screw those folks up. Always think accessibility! I know for a fact there are several visually-impaired and/or blind persons on some of the fedora lists who are very vocal about problems they have with some a11y features.
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
On Mon, 2004-08-30 at 23:22, Karsten Wade wrote:
Here's an example to illustrate the value of proper content tagging and not worrying about the presentation:
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.
Braille keyboard normally ~= soft braille display, a beast that sits under the keyboard, with 40 or 80 character single line display.
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.
As it does with any html, wrapping only the content which is not marked as preserve space. The problem with big magnification is that panning is usually mandatory, since (worst case I've seen) fewer than 20 chars are visible on the screen at once? Special stylesheets won't help in cases like that.
- 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.
Except that a person whose reading media is tactile is restricted to tty class of output? I.e. line at a time, hence they need to keep any 'visual' structure in their heads whilst reading.
- 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.
I've never seen software or devices which split output like that Karsten. Assistive technology on Linux is quite good at accessing html output.
And if current trends are maintained, the combination of braille output and low vision tools is a waste of time. The number of people learning braille is diminishing.
regards, also, david.pawson@rnib.org.uk http://www.rnib.org.uk
On Tue, 2004-08-31 at 10:16, Dave Pawson wrote:
Dave:
Thanks for the corrections to my example. I had mainly made that up from the top of my head, which is why it doesn't exist anywhere yet. :)
We illustrated the point well, though -- properly marked up content can be used in many different ways, and it is important to use tags correctly. We need to envision our document output being styled in many different ways and languages. One of the powers of DocBook is that it gives you a single-source that can be made into many forms of highly accessible output.
- Karsten
On Mon, 2004-08-30 at 23:22, Karsten Wade wrote:
Here's an example to illustrate the value of proper content tagging and not worrying about the presentation:
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.
Braille keyboard normally ~= soft braille display, a beast that sits under the keyboard, with 40 or 80 character single line display.
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.
As it does with any html, wrapping only the content which is not marked as preserve space. The problem with big magnification is that panning is usually mandatory, since (worst case I've seen) fewer than 20 chars are visible on the screen at once? Special stylesheets won't help in cases like that.
- 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.
Except that a person whose reading media is tactile is restricted to tty class of output? I.e. line at a time, hence they need to keep any 'visual' structure in their heads whilst reading.
- 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.
I've never seen software or devices which split output like that Karsten. Assistive technology on Linux is quite good at accessing html output.
And if current trends are maintained, the combination of braille output and low vision tools is a waste of time. The number of people learning braille is diminishing.
regards, also, david.pawson@rnib.org.uk http://www.rnib.org.uk
-- Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl
On Sun, 2004-08-29 at 19: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?
http://www.docbook.org/tdg/en/html/docbook.html I have an icon on my desktop that links to a disk based version of this. the toc provides a full list of tags and hence the meaning of each.
-
D＠7＠k|N& -
Dave Pawson -
Karsten Wade -
Paul W. Frields