joomla-cms
joomla-cms copied to clipboard
joomla
[5.2] Feature/collapseable tables
Pull Request for Issue #38335 .
Summary of Changes
Added function for collapsing child item for:
- Menu List View
- Categories List View (used in Category, Newsfeed, Banners)
- Tags List View
Testing Instructions
- Go to one of the above listed views and create multiple Items with child items in different Levels.
- Set the listlimmit to All
- After apply the patch
- Click to the arrow Buttons in the Table row. The Child items should disapaer and the arraw should trun from down to right
- Click again to the arrow button, The Child Items should again apear and the arrow turns from right to dowm
Actual result BEFORE applying this Pull Request
No function, because new feature
Expected result AFTER applying this Pull Request
New feature should availible. How it works is described in the Testing Instruction
Link to documentations
Please select:
-
[ ] Documentation link for docs.joomla.org:
-
[x] No documentation changes for docs.joomla.org needed
-
[ ] Pull Request link for manual.joomla.org:
-
[x] No documentation changes for manual.joomla.org needed
wont setting the list limit to zero create big problems on sites with a lot of categories etc
@brianteeman Do you have a different idea how to solve this? I think in 99.9% it will work really good to list all categories.
I have suggested various corrections and bug fixes.
- change collapsable to collapsible
- change header to a td not a th
- fixed copy paste errors in the js comments
- renamed the storage key
I like the idea, but we already wasting so much space for columns... we need a better solution for this.
I like the idea, but we already wasting so much space for columns... we need a better solution for this.
its not a waste of space when it has a function.
Should we move the arrows in the column with the checkbox? Or merge the drag&drop column with an other.
But in my opinion we have enough space for this column. It is only visible when the listlimit is all. So it will used by the most Users in desktop and not mobile enviroment.
its not a waste of space when it has a function.
did you ever used joomla on a non > 1920 screen?
that are images with sample data, if you look at real world data it's horrible...
In my opinion an 1920 screen is the industry standard, I think you don't get screens with less that 1920 nowadays
if you refuse to use the functionality provided then its not a suprise you dont like it.
/me not saying the ui in this PR is great but the reason for rejecting is just plain daft
I just read again throupgh the discussion in #38335 and wants to point out some points of the discussion there:
- All of the participants in this discussion think it will be an good feature to make the maintainace of large menu/catogory trees more easier and more clear
- I used icons which allready exists in the icon font
- this feature is really easy to adapt by third party extension developer, they only have to add an class and column to their tables.
- I added this feature for all tree views. (I looked to the Database installtion file for tables with an
rgtandlftcolumn)
@brianteeman if you hava a suggestion to improve the UI let me know.
I just developed this feature because I think it will really improve the usability when working with large category/menu trees. Aside from that in the feature request where nobody who said that it is an feature which we don't need. In my opion it is okay to use this little space for the column in the list view for this good improvement.
I would start by adding some css to remove the padding and margin which will reduce the column width and fix the horizontal alignment
before
after
might also look at a different icon - perhaps something with a border
@brianteeman thats looks good, but is this part of this feature or is it better to make make a general refactoring of the list views after a brainstorming process.
@brianteeman thats looks good, but is this part of this feature or is it better to make make a general refactoring of the list views after a brainstorming process.
i would do it now
As I think that this is a more complex topic, I opened a new issue for it, as it is not advisable to simply adjust the spacing etc. without further consideration, especially with regard to a11y. See Issue #41631
It's fine to create another issue for the wider problem but if this PR is to be merged it really needs to be improved as indicated above
I like the idea of collapsing. Could you place the arrow not in an extra table cell but together with the title? Like the lock icon for checked-out articles. Needs less space and is easier to understand.
In my opinion an 1920 screen is the industry standard, I think you don't get screens with less that 1920 nowadays
https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide
not really, not even in Europe, if you want to trust this statistic.
brianteeman:
if you refuse to use the functionality provided then its not a suprise you dont like it. /me not saying the ui in this PR is great but the reason for rejecting is just plain daft
and @brianteeman stop insulting me and do not put words in my mouth I didn't say.
hleithner:
I like the idea, but we already wasting so much space for columns... we need a better solution for this.
That's what I say: "we need a better solution for this"
of your screenshots the real offender is the com_content list of articles on a multilingual website.
this pr does not change that view at all
@HLeithner and @brianteeman: what to you think of the idea of @chmst to add the arrows to the title field
as its the only way that harald will accept this (as it doesnt change the number of colu,ms) then I think its the only way forward
as its the only way that harald will accept this (as it doesnt change the number of colu,ms) then I think its the only way forward
once again stop this, I never said that, what I said is "we need a better solution for this". and with this is not only mean to add another column or hiding that the column/row gets bigger.
So what is your objection then to this pull request as it's obviously not clear at all why you are blocking this improvement
I like the idea of collapsing. Could you place the arrow not in an extra table cell but together with the title? Like the lock icon for checked-out articles. Needs less space and is easier to understand.
@chmst @brianteeman any a11y implications from that change? Do we have to update the th for the title column in that scenario to let users know about the extra function in that column?
I think that here is a big a11y implication. It needs careful testing. Every action must be announced (collapse, expand) and the arrow must act as a toggle. We have similiar behaviour on menu-modules assignement, where we can collapse and expand the menu tree.
so instead of it saying "Show/Hide Child Elements" you want it to specifically say "Show Child Elements" and "Hide Child Elements" as appropriate?
I really like the feature, but it is not accessible at the moment. I did a check with a screen reader (I'm not an expert here) and the arrow only "tells" show/hide child elements, but not if it is open or closed and the child elements are only hidden visually, the screen reader knows nothing about the status. I'm not sure if that is the right thing role tree / treeitem): https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Treeitem_Role but aria-expanded true/false is necessary.
