Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Unexpected behavior with table and container navigation for nested tables #7382
I've seen the case below in a corporate environment. I agree it isn't common style of coding.
Steps to reproduce:
A. When in the inner table, pressing comma moves you out of it to outer table cell 4
A. When in the inner table, pressing comma moves you out of it to outer table cell 6, so the bottom of the outer table
The outer table is treated as a content table, the inner table is treated as a layout table. This is why pressing comma in the inner table moves you to the edge of the outer table, since layout tables aren't treated as containers. If you enable "Include layout tables" in browse mode settings, issue A goes away.
Points to discuss:
At least there is an inconsistency here, as table nav works for layout tables, but they aren't treated as containers.
I may have thought this at one time, but today I would be fine with ignoring layout tables. I think from memory the issue was more around the complexity to do this, especially with Gecko as we use a hybrid of virtualBuffer and out-of-proc IA2. having said this, some of that code was slightly refactored when abstracting table support for browseMode, so it is worth looking into again. I certainly agree the difference between table navigation and container jumping is bad.
take this example.
Table nav still traps the user, which is annoying. Could we do something like "Leaving nested table" when navigating out of the inner table with table nav?
You can leave the inner table with comma, so I think that is at least something. But I think that data tables inside data tables should be treated as layout tables.