[whatwg] Suggestion for Menus in Web Forms 2.0

[Matthew Raymond]

Matthew Thomas wrote:
> On 10 Aug, 2004, at 1:15 AM, Ian Hickson wrote:
>> CSS can be disabled. Or not supported at all. It generally is not a
>> solution to legacy fallback.
> 
> Er, really? So in HTML5, what do you propose will be the recommended way 
> of making these controls invisible in downlevel UAs?
> *   <output>

    Output is designed to degrade into its child text.

> *   <button>
> *   <select>
> *   <textarea>

    When Ian refers to "graceful degradation", he means degrading to 
HTML4. Browsers that don't support HTML4 are easily less than 1% of the 
marketshare. These days, most of the web requires a browser capable of 
HTML4 anyway.

> I don't see any way of hiding them in either HTML4 or WF2.

    Why would you hide them in markup?

> If the answer is "without CSS, you can't", why shouldn't that be true
 > for <menu> as well?

    The element <menu> doesn't have any contents by itself, so the only 
hiding I you might be referring to is to kill the margins and padding 
when it contains <command> tags and the like.

> I appreciate that CSS isn't an ideal degradation mechanism, but then 
> making something invisible is an odd sort of degradation for an 
> interactive element to begin with.

   The <ignore> element lives again!!! ;)

>>> Why on earth would you want to hide a menu? It's a menu. If none of 
>>> its items apply to the current context, a menu should appear 
>>> inactive, not hidden. Dynamically hiding and showing entire menus 
>>> would make the interface unnecessarily unstable.
>>
>> We're talking about the menu part of a menu bar here, not the menu bar
>> itself.
> 
> Ahh, I think I see the problem: I think you may have misread my 
> proposal. <menutitle> is part of the <menu>.
> 
>       <menu id="fm">
>        <menutitle>File</menutitle>
>        <itemgroup>
>         <li command="NewRecord">New</li>
>         <li command="OpenRecord">Open…</li>
>        </itemgroup>
>        <itemgroup>
>         <li command="ExportRecord">Export as Text</li>
>         <li command="RenameRecord">Rename…</li>
>         <li command="DeleteRecord">Delete</li>
>        </itemgroup>
>        <li command="SaveAndClose">Close</li>
>       </menu>

    I don't think he misread it at all. The menu title is not rendered 
as part of the actual menu, but part of the menubar. If anything 
inheritance should occur, it should be from the menu title to the list 
items and not the other way around. I'd prefer to see something like this:

      <menulabel accesskey="f">File
        <menu id="fm">
         <li command="NewRecord">New</li>
         <li command="OpenRecord">Open…</li>
         <li separator></li>
         <li command="ExportRecord">Export as Text</li>
         <li command="RenameRecord">Rename…</li>
         <li command="DeleteRecord">Delete</li>
         <li separator></li>
         <li command="SaveAndClose">Close</li>
        </menu>
      </menulabel>

    You would use <li separator> as a separator, and its child text 
would be similar to the separator labels in the Mozilla bookmarks. The 
<menulabel> could alternatively use |for| to be associated with the menu.

    Still trying to figure out those combination menuitem/submenus like 
I saw in OS/2 Warp. In Warp, you could click on "Open" to use the 
default, or there was an optional arrow button that looked just like the 
regular submenu arrow, only it had a button border around it, and it 
would show all the possible programs that you could use.

>> I believe I gave an example that shows why you are wrong in my last
>> e-mail. Basically, there are two ways of showing the label; with and
>> without attributes.
> 
> Again, I don't see why you are introducing multiple syntaxes to make 
> menus degrade to either visible or invisible without CSS, while not 
> doing the same for the Web Forms controls.

    For two reasons. First is that we're only worrying about degrading 
to HTML4. Second is that anything that needs to degrade to nothing in 
WF2 already does.

> If anything, it seems to me 
> that hiding the latter (use case: hiding the toolbar buttons for an HTML 
> editing area that degrades to a plain text editing area in downlevel 
> browsers) would be useful more often than hiding the former.

    I don't see a reason why this can't be accomplished without CSS, 
since the toolbar buttons can be implemented in a way that degrades to 
nothing without the use of CSS. HTML is designed to ignore unknown tags 
by default.