-
-
Notifications
You must be signed in to change notification settings - Fork 553
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XWIKI-22581: FocusCatcher input has no label #3577
Conversation
* Replaced the FocusCatcher artificial input with a semantically better span. * Updated the style of the gallery to use css grid instead of hackish solutions all around. * Improved accessibility by changing the div interactive controllers with buttons. TODO: Check further the half screen large picture maximized gallery behavior bug and find a fix for it.
* Fixed the full screen display vertical overflow issue.
* Fixed a typo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good with some minor (code formatting) comments.
...eb/xwiki-platform-web-war/src/main/webapp/resources/uicomponents/widgets/gallery/gallery.css
Outdated
Show resolved
Hide resolved
...eb/xwiki-platform-web-war/src/main/webapp/resources/uicomponents/widgets/gallery/gallery.css
Outdated
Show resolved
Hide resolved
...eb/xwiki-platform-web-war/src/main/webapp/resources/uicomponents/widgets/gallery/gallery.css
Outdated
Show resolved
Hide resolved
/* Instead of an arbitrary element to catch focus, we use the index. | ||
* This index already stores the current image state, might as well be responsible for providing quick controls and | ||
* explanations about these quick controls. | ||
* Note that wrapping the image in an interactive container to handle this would have been a good solution too. | ||
* However, this wrapping caused the image to overflow the CSS grid vertically when in maximized mode. | ||
* Technically I couldn't find a CSS solution to prevent this, so I decided to make do without wrapping. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/* Instead of an arbitrary element to catch focus, we use the index. | |
* This index already stores the current image state, might as well be responsible for providing quick controls and | |
* explanations about these quick controls. | |
* Note that wrapping the image in an interactive container to handle this would have been a good solution too. | |
* However, this wrapping caused the image to overflow the CSS grid vertically when in maximized mode. | |
* Technically I couldn't find a CSS solution to prevent this, so I decided to make do without wrapping. */ | |
// Instead of an arbitrary element to catch focus, we use the index. | |
// This index already stores the current image state, might as well be responsible for providing quick controls and | |
// explanations about these quick controls. | |
// Note that wrapping the image in an interactive container to handle this would have been a good solution too. | |
// However, this wrapping caused the image to overflow the CSS grid vertically when in maximized mode. | |
// Technically I couldn't find a CSS solution to prevent this, so I decided to make do without wrapping. |
Multiline comments are normally used to document functions (methods) and classes (or types in general).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a code style for javascript AFAIR. I assumed it'd be best to use the same comment style as the one we use for CSS. It would be interesting to keep trace of this rule so that new contributors won't make the same mistake. I created the draft doc https://dev.xwiki.org/xwiki/bin/view/Drafts/Javascript%20Code%20Style/ for now.
Reference of where we can already see this codestyle in action
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assumed it'd be best to use the same comment style as the one we use for CSS.
JavaScript is a programming language, unlike CSS, so I don't think it makes sense to look at CSS code styles for defaults. The default should be the Java code style IMO.
* Comment formatting Co-authored-by: Marius Dumitru Florea <marius@xwiki.com>
The comments on this PR are addressed and it is ready for further review or a merge. |
* Replaced the FocusCatcher artificial input with a semantically better span. * Updated the style of the gallery to use css grid instead of hackish solutions all around. * Improved accessibility by changing the div interactive controllers with buttons. * Fixed the full screen display vertical overflow issue. (cherry picked from commit 4241c3c)
Jira URL
https://jira.xwiki.org/browse/XWIKI-22581
Changes
Description
Clarifications
Screenshots & Video
Video demo:
2024-10-18.13-54-58.mp4
The gallery controls are tested both with the mouse and the keyboard.
Before:
After:
I tried to keep the visuals as close as possible as what was here before. The only differences I can spot are:
previous
/next
buttons. This happens because of the default padding that was added when transforming this element in a button. IMO this change is not a problem.Executed Tests
Manual tests: see above + tests with different screen sizes.
Built changes with
mvn clean install -f xwiki-platform-core/xwiki-platform-web/xwiki-platform-web-war -Pquality
and testedmvn clean install -f xwiki-platform-core/xwiki-platform-office/xwiki-platform-office-test/xwiki-platform-office-test-docker -Pdocker -Dxwiki.test.ui.wcag=true
. The WCAG violations reported did not highlight any issue with the gallery anymore.Expected merging strategy