There were additional reasons why to use a DIV for multi-column submenus at that time, especially to prevent the Wijmo code treat them as regular submenus and apply all the styling and listeners to it's children. It didn't make much sense to model columns as list items either. From a maintenance and debugging perspective, it was also easier to distinguish quickly what was a regular submenu and what was a multi-column submenu, by just looking at the tag.

We have no control over substantial changes made in third party libraries and we'll just have to adjust to their changes and implement whatever is more appropriate and easier for us for the new library codebases.

A UL element with display:block and appropriate list css disabled will render correctly on every browser we support.

Rendering unexpected (according to HTML4) children into a parent is something we do all the time. Hidden input components in particular are rendered in TONS of places that the validator would complain about. HTML4 validation would also complain about us having block level elements inside hyperlinks which is common practice everywhere. Do we care about that to? There is no point in following outdated standards that aren't even supported in the way described.

This is not a good reason to go through all the modifications required to use a DIV. Many of our components render this type of markup.

ICE-7827 was the JIRA for adding the ace:multiColumnSubmenu component. A DIV is used instad of a UL for multi-column submenus. It wasn't possible to use a UL element instead, because according to the HTML 4.0 DTD, a UL element must have at least one LI element as a direct child, and the ace:multiColumnSubmenu only has other DIVs as direct children (one for each column). So, this would result in invalid markup, which could lead to confuse some browsers.

(from http://www.w3.org/TR/html4/sgml/dtd.html)

<!ELEMENT UL - - (LI)+ – unordered list -->
<!ATTLIST UL
%attrs; – %coreattrs, %i18n, %events –
>

I'll have to take a look at the new code to see what's the new mechanism and try to re-implement support for ace:multiColumnSubmenu.

Some ICE-7827 changes cannot be ported to the newest version of Wijmo. Wijmo used to visit the DOM to collect menu items as needed- now a method is used throughout the component _getItems() returns the items from a cached set.

ICE-7827 often attempted to change the type of items searched for to include divs as well as uls. I think this may have been misguided from the beginning- if we just output a UL instead of a DIV, this broad modification wouldn't be needed at all- and a properly styled UL will render identically to an equivalent DIV.

Committed new feature at revision 28695.

The current wijmo codebase (1.3.0) had to be modified at several points (10+) to treat <div> elements as <ul> elements and thus make them behave as submenus. The newest wijmo codebase (2.0) was analyzed, and it was determined that it follows pretty much the same internal and external API, the same structure and follows the same overall pattern. So, it would be feasible to incorporate this feature if we upgrade our wijmo library.

The ace:multiColumnSubmenu component was added and it can be used instead of a regular ace:submenu component. This component can only contain ace:menuColumn components to represent the menu columns. These, in turn can contain regular submenus and menu items. The submenus will be displayed as plain submenus within the multi-column submenu (i.e. no flyout's).

This feature only works for the ace:menuBar and ace:contextMenu components.