At first I've only wanted to mail about <contextmenu> misplaced in the
"Components" category, but now the list goes longer and longer:
1) <contextmenu> and <contextmenuitem> shouldn't go into the
"Components" category, that's really just wrong, there aren't components
in any way. Should be moved into "Menus and Commands".
2) <drawview>, <splash> and <splash_view> aren't components, too.
3) Move <dataselectionmanager> from "Data" to "Menus and Commands",
because <selectionmanager> is placed in the same category. It makes more
sense to me to stick both classes together.
4) <event> and <handler> are covered in 3 (three!) sections ("Language",
"Events" and "Scripting"), I doubt this is necessary.
5) lz.CSSStyleSheet in "Scripting" -> I don't think anybody is
interested in that class, people only want info about the <stylesheet>
tag (which is currently missing!). I'd make all lz.CSSStyle* classes
private.
6) I'm not a big fan of documenting classes multiple times in different
categories. For example a couple of service classes are handled in
"Events" and in "Services". IMO using only the "Services" section is
sufficient.
7) <node> is covered too late, the "Scripting" category should be moved
way higher.
8) I'd appreciate if "Base Classes" appears before "Components", maybe
it should even be renamed to "Base Components" or whatever.
9) Different order of categories:
Structure, Language, Scripting, View Basics, Base Classes, Components,
[[Animation, States, Layouts, Menus and Commands] , Services, Data,]
[HTML Markup, Media, Audio Video], RPC, Charts and Graphs, Development
- [a,b,c] means a, b and c may appear in any order, nesting is allowed
You may be tempted to say: Wait, where is "Events"?
But IMHO, "Events" can be removed, because all entries (except
lz.Eventable) are already covered in other sections, lz.Eventable should
be moved in the same category as <node>.
