No feedback.

We don't have to use it, but application developers might find it 
useful. Can you provide an updated patch that applies cleanly to HEAD?

Quoting Jan:

"What I like about them is that you can't even select the headers. And 
you still can style them differently if you don't like the default 
layout."



The goal was: to allow developpers to use optgroup if for some reasons 
they need it.

I know it could be called a "cosmetic" feature, but it could make the 
package a bit more usefull too.

but because they're not widely supported we have to have the 
javascript code to handle not selecting the headers anyway...

What I like about them is that you can't even select the headers. And 
you still can style them differently if you don't like the default 
layout.



The code generation could probably be encapsulated somewhere, somehow.

Actually that's one of the places I don't like it - it's so 
inconsistent (also, it makes the code that generates it *very* ugly).



We could achieve more consistent results by applying CSS classes to 
the "header" style options, and I think we could make it nicer for all 
users that way.

I think they can make sense in some places, a good example is the 
calendar drop down in Kronolith.

Can you say *why* you want this? I loved the idea of optgroups at 
first, but they're poorly supported by browsers, they look *very* 
different in different browers that do support them, and I don't think 
they enhance usability much if at all. So I'm inclined to leave this 
out.

Milestone 3.1

Unified diff attached

Allow optgroup rendering in enum and multienum form types