Thu, Nov 19
Given the low effort of implementing the positive tabindex approach (changing a few lines in the Mustache templates), I recommend we move forward with that approach because although it's considered an anti-pattern, it effectively solves this issue for mobile as well as non-JS users. If it becomes a maintenance concern in the future, then we can re-evaluate a JS based focus-looping technique.
Tue, Nov 17
Wed, Nov 4
I've been exploring the feasibility of solving this via the DOM order change, i.e. moving the sidebar back inside the header element.
Tue, Nov 3
Wed, Oct 28
Tue, Oct 27
Besides the two approaches considered above, which can be summarized as:
Oct 19 2020
Oct 14 2020
Just to recap the work done in this task: In accordance with the arguments presented above, the DOM order in modern Vector has been changed to reflect the visual flow of the page.
These changes will let us: shed a significant portion of the legacy CSS, improve the presentation on smaller screens, improve the loading experience, and bring Vector in line with more common accessibility patterns on the web.
Oct 7 2020
Oct 6 2020
Looking at the link @Volker_E mentioned, https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader#File_organization
I'm moving this back to the backlog. because as discussed in the gerrit patch here I think we should create a separate variables file for modern Vector if we're going to have different font-related variables (at least at first) in modern and legacy Vector.
Oct 5 2020
Oct 1 2020
Regarding the entry files: skin.less and skin-legacy.less, I was thinking about naming both skin.less since they'd be in different folders. This is similar to the convention in Node of using index.js in multiple places. The downside of that however is that searching for those files in an IDE is difficult because they both have the same names (maybe not a big deal though). Another approach we could use for these entry files is to name them after their ResourceLoader module, so
skin.less → skins.vector.styles.less
skin-legacy.less → skins.vector.styles.legacy.less
That might be overthinking it though...
@Volker_E I like skins.vector.styles.common/ for consistency. I've updated the description with that, also including where layout folders could go.
I definitely agree with removing the term "body" from these classes. That's certainly confusing.
Sep 30 2020
@Bouzinac Although this is certainly a bug, given that switching to "advanced" mode is a workable solution, this isn't likely to be given high priority.
Sep 29 2020
I love the chart on https://www.mediawiki.org/wiki/Design/Link_colors, can we mirror that in the description?
I think what we want from this task is:
Sep 28 2020
The technique of modifying focused elements with JS is typically called focus trapping (or looping). There's a good writeup on medium of the general implementation here: Focus Trapping for Accessibility (A11Y) . It generally involves checking which element is focused and changing the next focused element during a keydown event.
Sep 23 2020
We refrained from estimating this today for the following reasons:
- We weren't sure where these link colors are defined, and if this change will require a change in core,
- If it's just in Vector, we weren't sure how to separate the color variables for legacy and modern vector
- We weren't sure how to change the colors of the related "external link" icon (or any similar icon that appears as part of a link).
- We think this change requires some community consultations.
Sep 21 2020
Sep 17 2020
@Iniquity thanks for mentioning the CC attribution. The individual files we're uploading are actually split into workmarks/tagline e.g. frwiki-wordmark frwiki-tagline. I was thinking these files, since they are just text in an open-source font, might actually be public domain as they might not meet the Threshold of originality to have any license at all.
Sep 16 2020
Sep 14 2020
Sep 7 2020
I've been thinking of doing this for a while now, here are my thoughts.
Sep 3 2020
Sep 2 2020
Aug 31 2020
was just noticing that it's common for the search term to remain in the search box once the search has been submitted. I think this makes sense for search experiences where search leads you to a list of results. I'm not sure if it still makes sense in our case where you land on a specific result (rather than a list).
Aug 27 2020
Aug 26 2020
Aug 20 2020
Aug 18 2020
Aug 17 2020
Aug 12 2020
Is this mainly a question of vocabulary? I think the usage itself is consistent with the BEM concept of modifiers.
Aug 10 2020
Aug 7 2020
Aug 4 2020
Jul 28 2020
The implementation can live within WVUI if potentially useful to any search consumer or directly within Vector if not.
I assumed since this loader should kick in before the Vue library loads, that it should live in Vector.
Jul 27 2020
Are we receiving feedback that this behavior is problematic? If we know this is the eventual final state, I wonder if we need to do anything here?
Jul 21 2020
Jul 20 2020
I did a bit of research as to why this happens. I wasn't aware of this browser behaviour, but apparently, when you click on an internal link <a href="#target">menu link</a> the target element <h2 id="target">over here</h2> actually gets the keyup event if it's focusable. Since our menu button uses tabindex=0 to force focus, it receives the keyup event that originates from pressing the "skip to navigation" skip link.
Jul 16 2020
I found a bug with this implementation. When clicking the "jump to navigation" skip link, the sidebar changes state. The patch above provides a fix by removing the keyup event binding on the checkbox hack. I'm not 100% sure why that event binding causes this to happen, but removing it prevents this behaviour.
Jul 15 2020
... and promise that results will be presented as quickly as possible.
Jul 14 2020
Also re:Loading indicator, I think we have to take into account when we exactly we want that to appear, and how likely it is that someone will see it.
I don't know if we've settled on the loading strategy for the widget, but if we load the code for the widget lazily, e.g. we wait until someone focuses or hovers on the search input before we initiate the search-suggestion code, then it's likely that the initial search suggestions will be delayed (for the benefit of loading less code upfront). In this scenario it might be good to notify the users that some results are on the way, but if we show some sort of loading indicator on subsequent API requests, while users are typing, in between keypresses, I think that might be distracting.
Re: Namespace search. The search API only searches the main namespace unless the beginning of the query matches the namespace name exactly.