browser: accessibility: fix incorrect semantic use of a <table> tag

[hcvcastro]

" the

element, only elements (table rows) and within those, or elements (table cells), should be used. "

Change-Id: Iafff80c01158a1cb08d3a6f8cc29cbc00b9aaeb5 Signed-off-by: Henry Castro [email protected]

[eszkadev]

This PR causes regression, some weird spacing inside some list views:

Would be good to check also in:

• macro dialog
• zotero dialog because they have additional complex structures inside treeviews

[eszkadev]

Hi I have proposal:

• we have at least 3 types of treeviews
• can we make separate classes for them? so they all inherit from TreeViewControl, have the same api, but implement differences inside

It will be much easier to modify in the future if we know what we are changing... Also could you comment above each of the classes in which dialogs that specific implementation can be tested?

so I would expect that main "entry point", treeview handler will do something like:

if (some condition)
    treeControl = SimpleTreeControl()
else if (something else)
    treeControl = MoreAdvancedTreeControl()
else if (...)
     treeControl = SomeOtherType()
else
     error('unkonwn type');

[eszkadev]

Also it would be nice to merge this step by step: so please implement one kind of treeview -> then we review and merge this one implementation (other types use old handler). Then we do second and so on

[hcvcastro]

Hi I have proposal:

we have at least 3 types of treeviews
can we make separate classes for them? so they all inherit from TreeViewControl, have the same api, but implement differences inside

Thanks, I analyzed too, but first I wanted to convert to class and reuse almost all possible code, then we can separate in 3 sub-classes, inspecting the shared code, but the problem here is the iterations of data.entries, the initial idea is to auto-detect the treeviews type in one loop iteration

[hcvcastro]

It will be much easier to modify in the future if we know what we are changing... Also could you comment above each of the classes in which dialogs that specific implementation can be tested?

I agree

[hcvcastro]

so I would expect that main "entry point", treeview handler will do something like:

if (some condition) treeControl = SimpleTreeControl() else if (something else) treeControl = MoreAdvancedTreeControl() else if (...) treeControl = SomeOtherType() else error('unkonwn type');

The problem I have found how to auto-detect which type of treeview, I did not analyze the Core side, it could send data.entries, with children or not, with headers or not, or 1 column, all it must be done in one loop iterations, we cannot iterate for every type =)

[eszkadev]

Build warnings:

browser/src/control/jsdialog/Widget.TreeView.js
  1019:4   warning  'selectionElement' is assigned a value but never used  no-unused-vars
  1161:11  warning  'state' is defined but never used                      no-unused-vars
  1173:4   warning  'selectionElement' is assigned a value but never used  no-unused-vars

[hcvcastro]

It is in pause, I did not finish it yet.

[eszkadev]

Dialogs with more advanced testing scenarios:

• macro
• review -> manage changes in writer
• navigator
• Zotero dialog
• Format -> Character (lists of fonts)