W3C home > Mailing lists > Public > public-html@w3.org > March 2013

Re: Definition of "Toolbar", Alternate Menu Type?

From: Xaxio Brandish <xaxiobrandish@gmail.com>
Date: Sat, 16 Mar 2013 01:16:38 -0400
Message-ID: <CABAoKZkfcd=2y0VUQY40X16RQSj+UQD402BO3Wd-UkMnH=S_TQ@mail.gmail.com>
To: public-html@w3.org
Good morning,

Ah ha!  I believe that I have just, unbeknownst to me, described something
very akin to the <details> element.  The question about the definition of
"toolbar" still stands though, please.

--Xaxio


On Fri, Mar 15, 2013 at 5:39 PM, Xaxio Brandish <xaxiobrandish@gmail.com>wrote:

> Good afternoon,
>
> I believe I originally sent this e-mail to the incorrect list.  Forgive
> the cross-post.
>
> Pardon my ignorance, but I cannot seem to find a definition of "toolbar"
> anywhere in the HTML specification.
>
> The Candidate Recommendation states:
>
> "If a menu element's type attribute is in the toolbar state, then the
>> element represents a list of active commands that the user can immediately
>> interact with."
>>
> (http://www.w3.org/TR/html5/interactive-elements.html#toolbar-state)
>
> and
>
> "A menu (or toolbar) consists of a list of zero or more of the following
>> components:
>>
>>     Commands, which can be marked as default commands
>>     Separators
>>     Other menus (which allows the list to be nested)
>
> (
> http://www.w3.org/TR/html5/interactive-elements.html#building-menus-and-toolbars
> )
>
>
> The Editor's Draft states:
>
> "If a menu element's type attribute is in the toolbar state, then the
>> element represents a toolbar consisting of its contents, in the form of
>> either an unordered list of items (represented by li elements), each of
>> which represents a command that the user can perform or activate, or, if
>> the element has no li element children, flow content describing available
>> commands."
>>
> (
> http://www.w3.org/html/wg/drafts/html/master/interactive-elements.html#toolbar-state
> )
>
> and the subsequent menu (or toolbar) text seems to have changed to:
>
>> "A pop-up menu consists of a list of zero or more menu items, which can
>> be any of:
>>
>>     Commands, which can be marked as default commands (menuitem)
>>     Separators (hr)
>>     Other menus, which allows the list to be nested (menu)"
>>
> (no subsection link)
>
>  I have a few questions based on these pieces of text. Please allow me to
> enumerate them to make them easier to address.
>
> 1) How is "toolbar" defined?
>
> a) Unsourced Wikipedia states currently "In a graphical user interface, on
> a computer monitor, a toolbar is a GUI widget on which on-screen buttons,
> icons, menus, or other input or output elements are placed."
> (http://en.wikipedia.org/wiki/Toolbar)
>
> b) Unsourced Wiktionary states currently "A row of buttons, usually marked
> with icons, used to activate the functions of an application or operating
> system".
> (http://en.wiktionary.org/wiki/toolbar)
>
> c) Merriam-Webster states that a toolbar is "a strip of icons on a
> computer display providing quick access to certain function".
> (http://east.merriam-webster.com/dictionary/toolbar)
>
> d) Can a toolbar consist entirely of text, without using icons?
>
> e) Must a toolbar be a row (implying a horizontal visualization) instead
> of a column?
>
> 2) Based on the draft text, are the terms "menu" and "toolbar"
> interchangeable, or is a toolbar *definitively* a type of menu?
>
> a) The text in the Draft that has changed to state "A pop-up menu..." and
> then define the contents of a menu seems like it should be valid for any
> menu, regardless of whether it is constantly visible or a pop-up menu.  Why
> was this changed?
>
> 3) Regardless of whether looking at the CR or Draft, the <menu> element
> only takes a type of either "popup" or "toolbar".  The <contextmenu>
> element appears only to be relevant to right-click events.  Please consider
> the following scenario:
>
> A viewport exists, split horizontally by a graphical line into two parts,
> with the left part taking 15% of the horizontal space and the right part
> taking 85% of the horizontal space. The left side of the viewport displays
> contextual information.  The area on the right side of the viewport
> contains various elements with which an end user can interact.  When an
> element on the right part is clicked (not right-clicked), the left side of
> the viewport is updated with *contextual* information relevant to the
> clicked element.  This contextual information consists of the size of the
> element, the background color of the element, a link that can be clicked to
> expand the width and height of the element (a command), and an element that
> can be hovered over to display yet more actions and information associated
> with the element.
>
> a) How would the left side of the viewport be defined?  It is not used for
> navigation, so <nav> does not seem to apply.  It is neither a toolbar by
> the above definitions (there are no icons or buttons for it), nor is it a
> popup menu, since it is constantly visible.  By the CR definition of menu
> contents, it *seems* like it should be a menu.
>
> b) Would it make sense to define a third type for the menu element for
> this type of situation, or would it fall under the jurisdiction of another
> element entirely?  I ask in the interest of maintaining semantic markup.
>
> If I have addressed this to the wrong mailing list, please inform me.
>
> --Xaxio
>
Received on Saturday, 16 March 2013 05:17:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:37 UTC