nextcloud-vue
nextcloud-vue copied to clipboard
nextcloud-libraries
fix: regression in list item's extra slot
☑️ Resolves
- Fix https://github.com/nextcloud/mail/issues/9334
🖼️ Screenshots
| 🏚️ Before | 🏡 After |
|---|---|
🚧 Tasks
- [ ] ...
🏁 Checklist
- [ ] ⛑️ Tests are included or are not applicable
- [ ] 📘 Component documentation has been extended, updated or is not applicable
- [ ] 3️⃣ Backport to
nextrequested with a Vue 3 upgrade
The "after" image also looks broken, for the NcListItem I would only expect two lines of text working and the tags to be shown on the very right.
The "after" image also looks broken,
Yes the after is still a bit broken, the tags should be aligned with the lines
This is how it looks on nc.cloud
for the
NcListItemI would only expect two lines of text working and the tags to be shown on the very right.
Isn't the extra slot supposed to show elements below the lines
The "after" image also looks broken,
Yes the after is still a bit broken, the tags should be aligned with the lines This is how it looks on nc.cloud
this is fixed on mail side, i already pushed a pr for that https://github.com/nextcloud/mail/pull/9336
Was there a design review? It seems this component gets extended to an all-in-one-solution. Especially that there is now a 3rd and 4th line introduced, which might be ok but we need to make sure not to break anything (e.g. a11y where you need to make sure to NOT include interactive elements ).
Makes more sense now thank you for the explanation, I'll try to work on a different solution
I mean if it fits in the component fine, but we can not have nested interactive elements. This only works with some specific focus handling (e.g. how menu bars work, you can tab the first element but next tab will be outside the menu bar, you then need to use arrows to change focus).
Hello @susnux, this is still an issue on mail, i would get @jancborchardt @marcoambrosini @nimishavijay involved, what would be a good compromise :)
If it was up to me, I would keep it on the right side, with the argument, that its like this since couple of months and nobody complained about the space, which means that either people are fine with it, or its not used at all :), now that we have different layouts, people can always choose a layout where the list is wide. But, of course, i would be fine to work on another solution.
An interactive element (the a) must not contain any other interactive element (the NcActions).
Are you sure that this is the case @susnux ? afaik an <a> cannot contain another <a> but it can contain buttons
e.g. most cards in card layouts
e.g. most cards in card layouts
In valid implementation, they are not wrapped in <a>. They have a link inside and either use custom onclick (like we do in Files) or stretch the link in a pseudo element (like we do in Apps list).
But in both HTML validity and accessibility having nested interactive elements is not valid.
I donn't know which would be the better approach. cc @ShGKme and @susnux
what we're trying to accomplish is just a third line for 'non interactive- non clickable "tags" ' would that be acceptable ? So move the slot outside the NcActions rename it (thirdline? ) ?