OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: DOCBOOK: Re: gui elements


Along the lines of this previous discussion:

menuchoice is described as denoting a series of actions "from a menu", even though it can contain guibutton, guiicon, and guilabel.

Describing a sequence of GUI elements, beyond menus, is useful--any chance the name (and description) can be updated to
<guisequence> or something?

----- Original Message -----
From: "Brian Lalonde" <brianiacus@yahoo.com>
To: "Norman Walsh" <ndw@nwalsh.com>; <docbook@lists.oasis-open.org>
Sent: Friday, February 15, 2002 10:31 AM
Subject: Re: DOCBOOK: Re: gui elements


> ----- Original Message -----
> From: "Norman Walsh" <ndw@nwalsh.com>
> To: <docbook@lists.oasis-open.org>
> Sent: Friday, February 15, 2002 5:05 AM
> Subject: DOCBOOK: Re: gui elements
>
>
> > / Brian Lalonde <brianiacus@yahoo.com> was heard to say:
> > |   guilink
> > |     To describe a clickable GUI element, such as a link on a web page,
> > |     usually rendered as blue underlined text.
> >
> > I don't personally tend to think of these as distinct GUI items in the
> > same sense as other widgets. They're just text.
>
> For documenting web-based applications, it is as important as marking up
> GUI buttons, etc.
> How would you mark something like this up, so that it could be styled to
> make it obvious to the reader that this is the text of a GUI link
> (via quotes, underlining, bold text, etc.)?
>
>   <step>Click <guilink>Log off</guilink>.</step>
>
> > |   guioption
> > |     A radio button, checkbox, select list option, or range position in a
> > | GUI.
> > |     A class attribute would subdivide the domain.
> >
> > What do other people on the list use to markup these widgets?
>
> Guilabel can likely cover labels for checkboxes and radio buttons, maybe
> even select list options (userinput?).
> To that end, guibutton could also be handled by guilabel.
>
> > |   guimenu
> > |     Remove guisubmenu and guimenuitem in favor of a class attribute to
> > |     subdivide the domain.
> >
> > Six of one...
>
> Except wrt (minor) simplification of stylesheets.
> Actually, I find it odd that some tags, like the menu and admonition
> elements
> were broken apart, despite syntactic and contextual similarity, while
> elements
> like article, database, filename, medialabel, sgmltag, systemitem,
> trademark,
> etc. use class attributes for specificity.
> A smaller number of tags, given the same granularity of meaning, seems like
> a
> good thing.
>
> > |   guilabel
> > |     Add a class attribute to distinguish labels for fields, fieldsets,
> > |     card/tabs, dialog box titles, options, etc.
> >
> > What would the complete list of class values be?
>
> Maybe something like: input/control/widget, value, container,
> caption/titlebar.
>
> -Brian



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC