994 - OPTGROUP not implemented yet

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Angus Davis]

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     ]

Comment 1

[Eric Pollmann]

Working on this...

Comment 2

[Eric Pollmann]

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.

Comment 3

[John Morrison]

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

Comment 4

[John Morrison]

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

Comment 5

[Angus Davis]

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

Comment 6

[rods (gone)]

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

Comment 7

[leger]

Setting all current Open/Normal to M4.

Comment 8

[Paul MacQuiddy]

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

Comment 9

[Christine Hoffman]

Reassigning qa contact to [e-mail]

Comment 10

[rods (gone)]

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

Comment 11

[cpratt]

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

Comment 12

[andreww]

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>

Comment 13

[Kevin McCluskey (gone)]

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.

Comment 14

[cpratt]

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!

Comment 15

[karnaze (gone)]

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.

Comment 16

[cpratt]

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.)

Comment 17

[Kevin McCluskey (gone)]

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.

Comment 18

[cpratt]

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 (?).

Comment 19

[Claudius Gayle]

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.

Comment 20

[Claudius Gayle]

cc'ing myself

Comment 21

[leger]

Clearing Fixed resolution since this is Reopened.

Comment 22

[chris hofmann]

rolling over to m8

Comment 23

[Kevin McCluskey (gone)]

Moving to M9

Comment 24

[Kevin McCluskey (gone)]

Moving to M10

Comment 25

[Kevin McCluskey (gone)]

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

Comment 26

[rods (gone)]

Fixed. Implemented using CSS generated content

Comment 27

[cpratt]

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

Comment 28

[Claudius Gayle]

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

Comment 29

[Claudius Gayle]

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

Comment 30

[cpratt]

Attachment: A simple test case (contains a form with an optgroup)

Comment 31

[cpratt]

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.

Comment 32

[rods (gone)]

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.

Comment 33

[rods (gone)]

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?

Comment 34

[cpratt]

Reassigning to claudius.

Comment 35

[Claudius Gayle]

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

Comment 36

[Brian 'netdragon' Bober]

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.

Comment 37

[Brian 'netdragon' Bober]

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

Comment 38

[Travis Freeland]

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?

Comment 39

[Brian 'netdragon' Bober]

Attachment: test case 2 - a file with a lot of sub optgroups

Comment 40

[Brian 'netdragon' Bober]

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

Comment 41

[Brian 'netdragon' Bober]

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

Comment 42

[Brian 'netdragon' Bober]

It is a javascript redirect inside a frame.

Comment 43

[Brian 'netdragon' Bober]

Please ignore that (today is not my day)

Comment 44

[Brian 'netdragon' Bober]

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.

Comment 45

[rods (gone)]

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.

Comment 46

[Brian 'netdragon' Bober]

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