We don't yet support HTML 4.0's OPTGROUP element. Here's how it should work: <SELECT name="ComOS"> <OPTGROUP label="Fruits"> <OPTION>Apple <OPTION>Orange <OPTION>Pineapple </OPTGROUP> <OPTGROUP label="Meats"> <OPTION>Beef <OPTION>Chicken </OPTGROUP> <OPTGROUP label="Deserts"> <OPTION>Ice Cream <OPTION>Cake </OPTGROUP> </SELECT> Should render as: [ Fruits ] [ Meats ] [ Deserts ] When you mouseover "Deserts" for example, you get: [ Fruits ] [ Meats ] [ Deserts > Ice Cream ] [ Cake ]

Working on this...

This is parsed correctly the content model correctly now. Since this requires a UI not provided by native list boxes, the holding point seems to be implementation of GFX rendered form elements.

*** Bug 2069 has been marked as a duplicate of this bug. ***

*** Bug 2077 has been marked as a duplicate of this bug. ***

Note that Opera 3.5 supports this. You can check it out for an example implementation.

*** Bug 2122 has been marked as a duplicate of this bug. ***

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Reassigning qa contact to cpratt@netscape.com

This is a requirement for the list and drop-down list

*** Bug 3323 has been marked as a duplicate of this bug. ***

The w3 spec talks about "future" implementations having multiply nested optgroups for hierarchical views. It would be really nice if we could have the ability to nest optgroups - like: <SELECT name="ComOS"> <OPTGROUP label="Fruits"> <OPTGROUP label="juicy"> <OPTION>grapes <OPTION>watermelons </OPTGROUP> <OPTION>Orange <OPTION>Pineapple </OPTGROUP> </SELECT>

Supported in 5-17-99 4:00pm build for GFX-rendered widgets only. Option groups are rendered as a italic bold headings with the option elements offset to right below them. Option groups will not be supported for native rendered widgets so I am marking this bug as fixed.

Um, I need some clarification on this. Using my simple test case at http://schist/forms/optgroup.html, I don't see this rendering in the UI at all. I'm afraid I don't really understand kmcclusk's comment about GFX- vs. native widgets... on a basic level, if I don't see this in the UI, I don't consider this fixed. Please let me know how to proceed. Thanks!

You need to turn on GFX mode, but unfortunately it can only be done from Viewer. So, I think there are 2 options (1) run viewer first, go to style/widget-rendering-pref and set it to gfx or (2) set the preference in the preference file (sorry, but I'm not sure what it is called). Next, run Apprunner.

OK, I'm stuck. The 1999052408 build does not include viewer.exe. I tried editing prefs.js to include the following line: user_pref("style/widget-rendering-pref", "gfx"); - however, that either didn't change anything or I have the syntax wrong. So... what next? (If it helps, this bug was reported against Win32 and that's the platform I'm using to regress it.)

David, do you know how to manually insert a preference setting for apprunner? I tried using user_pref("nglayout.widget.mode", 2); which is what gets set in default_prefs.js when the viewer sets the widget rendering mode to gfx. I tried placing the same line in prefs50.js but it does not cause apprunner to use gfx rendering.

Still don't see this in the browser UI using the 1999060108 build under NT. Additionally, I still do not know how to enable GFX mode. The fix will remain unverfied until such a time as I can enable GFX mode in Win32 apprunner, or until that mode is enabled by default (?).

the relevant citation in the HTML 4.0 spec is at http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.6. the url now points to a testcase. Changing platform to 'ALL'. REOPENING bug because it just ain't fixed. Since I was unable to get Apprunner to accept the user_pref("nglayout.widget.mode", 2); pref, I looked at Viewer across all the platforms with the 1999061808 builds. Mac and WinNT ignore the OPTGROUP tag in a safe way and just render the options in the dropdown as if they were listed directly under select. Linux Viewer was very strange. Maybe this is known behavior since I haven't used Linux Viewer ever since there was an apprunner. As soon as I turned on GFX widgets and reloaded the testpage a chromeless, grey 'area' appeared in the upper-left hand corner of my monitor. When i clicked the drop-down this area actually mirrored the <options> and picked up selections. Moreover, selecting is this area was reflected in the widget on the page. Freakish anomalies aside, the OPTGROUPS weren't picked up on any of the platforms in Viewer.

cc'ing myself

Clearing Fixed resolution since this is Reopened.

rolling over to m8

Moving to M9

Moving to M10

Rod, Here is another gfx-select issue to test.

Fixed. Implemented using CSS generated content

It's there and looking pretty darned nice IMHO. Marking verified fixed.

well somebody somehow broke this because it DOES NOT work with the 8/24 builds. On WinNT the drop down works properly but selected items are not showing up in the text field. On MacOS the drop down doesn't render properly at all and it is not posssible to check the selection functionality. *note I am talking about Apprunner since I hand-edited the prefs to use all gfx widgets

forgot to mention it works brightly, brightly and with beauty on linux. So this is Mac and Win32 only...

I should also point out that although this was working acceptably (for me at least) on Win32 earlier in the week, the implementation leaves (perhaps) something to be desired, especially whe compared with angus' description in this bug. From a UI perspective, I would indeed expect similar behavior to, say, submenus in menus in a standard Windows application. For example: Click once to drop down the OPTGROUP. You should see: China > India > Japan > And after the cursor hovers over India, you should see: China > India >| Assam | China >| Darjeeling | That is, ideally you would see something that resembles a submenu. As it currently stands, what you get isn't really anything like what I've described above. Although it works OK for me, I definitely forsee usability problems, especially in that things appear in the OPTGROUP now that are not selectable. For example, if you load the attached test case into the 20-Aug-99 build under Win32, you get a long list of things in different fonts. Some are selectable, and some aren't; this may be confusing (or even infuriating) to anyone not familiar with the concept of the OPTGROUP. My two cents' worth.

We talked about this in great length when we first started to do GFX widgets. We decided the current implementation is as much investment we want to make at this time. We may wish to do the more menu-like approach in the future. One reason is, at this time the spec says there is only one level of optgroup/option and the indentation aproach is sufficient for that. For what it is worth, IE doesn't even indent. Resetting to fixed.

I talked to kevin and there are several excellent reason why the bizarre Motif styled menu like way is very broken. 1) optgroups can be in lists 2) When the drop down dropped down you wouldn't know what optgroup the currently selected item was in because it would be hidden. You have have to go hit everyone of the optgroups and make then slid out to see. 3) We are using a standard CSS display attribute to indicate how these things are to be displayed. 4) look closely at the CSS example using the bizarre motif-styled menu thing. It's confusing itself to use and would it continuely grow and shrink to match the size of the selected item?

Reassigning to claudius.

marking VERIFIED for 1999090909 builds. The are some UI concerns I guess but the implementation is satisfactory and works on all platforms.

One thing to note: w3 said in the standard that there is a very good chance that they will add this in the future. Are you willing to have the current versions of NS not follow the standard when they decide to implement this? It is in the standard - a little ambigious but there nonetheless. I believe that they didn't just write that for their own good to have it ignored. I realize that you might have other things to do - but this bug should definately not be marked verified fixed. The reason is that in the future this might be implemented. It should be marked remind or future.

Note. Implementors are advised that future versions of HTML may extend the grouping mechanism to allow for nested groups (i.e., OPTGROUP elements may nest). This will allow authors to represent a richer hierarchy of choices

Amaya implements this the logical way - using cascading menus. Given that Amaya is the W3C's example of how a browser should implement the standard why is Mozilla being lazy on this?

This attachment really does a number on mozilla. It appears all messed up. Maybe it would be better just to implement it. :)

By the way, if it was implemented as indented options, it would be indented way too far.

It is a javascript redirect inside a frame.

Please ignore that (today is not my day)

Travis, I would have to argue that amaya is not quite the industry standard. Look at how it does floating divs as pointed out by dbaron. I would also have to agree with you though that the way amaya did it is the most logical way to do it.

So much to do, so little time. Since this is open source, I say go for it and implement it. :) We have always kept in the back our minds that we would eventually have to support nested optgroupd deeper then one level. At this time I don't think the parser supports a deeper nesting. Either in the next release or the one that follows, depending on time constraints, we will use XBL controld for the form widgets and this will enable us to have cascading menus. When the spec actually changes then someone should file a new bug and assign it to me. But right now, we implement optgroups per the spec.

Thats great, do the more important things first. All I am asking is to remove that Verified Fixed and set it as New.