I think a different way of thinking of it is: if the entire element is a link, then the title and description text should be blue by default. Instead, we are currently suppressing the link styling in order for the page title to be black and the description gray. With this change we would instead only be suppressing the link styling on the description text (still displaying it in gray). I think from that perspective we are then using less CSS, and overriding the default styling less.
Can be signed off, given that the issue detected was fixed in a separate patch.
Looking and behaving great! This task and T308273 can now be signed off by design after changes were verified in Safari v15.5, Firefox v101 and Chrome v103 on MacOS Monterey.
Thanks for the patch, @AnneT! Changes are looking great in, as always, Safari v15.5, Firefox v101 and Chrome v103 on MacOS Monterey. The task can be signed-off.
I think that this might be the strongest point against the new navigational menu item styling proposal: the whole menu item is the interactive element here, the one that needs to react to hover and click events, not the title, which is not a link. In the markup, this is expressed by the fact that all the content in menu options (thumbnail, suggestion text) is wrapped in an <a> element. I might be wrong, but moving ahead with the proposal would either involve applying link styling to an element that's technically not a link, or needing to nest two consecutive links with the same href.
A Figma spec sheet is created for the component that includes the scope defined here. A link to the Figma spec sheet's MVP version has been added to this task's description.
Thanks, @Volker_E! While creating the ticket, I also thought this would be solved with the introduction of Codex's spacing tokens, but it seemed necessary to document this in any case just to be safe 🙏🏻
Thu, Jun 23
Thanks so much, @AnneT 💯 I tested the new implementation using the pending state demo in Safari v15.5, Firefox v101 and Chrome v103 on MacOS Monterey. No issues were found: the placeholder thumbnails replaced the white squares and are displayed while images load. Said images display the agreed upon 100ms opacity-based transition on enter. Seeing also that @Volker_E already provided a +2 in the last patch, I consider reasonable to sign off this ticket from a design point of view.
The task can be signed-off from a design perspective. The selected/highlighted menu item displays the right styles regardless of the way in which the menu is reopened. Tested in Chrome v103, Safari v15.5 and Firefox v101 on MacOS Monterey.
Thanks for your reply, @alexhollender_WMF! I think my question should have been phrased differently. Knowing that your team has tested and iterated on the component before, I think the existing TypeaheadSearch has been considered a source of truth. A sort of standard we're aiming for. The change in line-height was a way to try to maintain the same level of scannability in the new component. Therefore my question should have had a more comparative tone, related to the satisfaction of said standards, which already fulfilled by the production component.
I agree with you. In my opinion, the new version makes it easier to parse through the options in the menu. All considered: we weren't planning on conducting any usability testing as part of the implementation of this component, for the reasons stated above, but if we were to introduce (more dramatic) changes to the original designs, it'd then introduce this step in our process.
Wed, Jun 22
Hey, Readers Web team 👋🏻 Supported by the arguments provided by Anne in the comment above, the Codex team identified the need to introduce a Card component into Codex (See Epic: T278311). We've taken the first steps in that direction and defined the scope of a Card MVP (T310628), which will start to be implemented by our team as soon as the corresponding MVP design specs are finalized.
Regarding the transition's duration: I'm torn! I've been trying both options and, while I like the smoothness of 250ms, I agree that faster loading always feels more efficient. We also recently increased the speed of progress bar animations, so I think we could follow the trend and apply 100ms here. After all, it's @transition-duration-base 👍🏻
Indeed! I forgot to ping you about that, @alexhollender_WMF. The content within options has been grouped a bit more closely (option 3) as a result of a recent patch, as Anne just commented. Please let us know if you think this new version improves scannability to some degree.
Behavior and styles are correct in all last versions of Chrome, Firefox and Safari. I detected, though, that the footer's text keeps displaying the active blue color on mouseleave during mousedown. The correct behavior would be for the active styles to be fully removed in that case (see 803610 and T308170: MenuItems should lose highlighted and active states on mouseleave for reference). I'm not sure if this fix should be implemented as part of this same task, or if a separate ticket is needed. Would be happy to create it if so!
Looks great! The only thing that I noticed is that the footer's text keeps displaying an active blue color on mouseleave during mousedown (the problem described by Volker two comments above). These new, consistent active footer styles were introduced by @SimoneThisDot in a recent patch: 805399 (as part of T308273: Apply MenuItem selected styles to Menu footer). Not sure how this fix should be handled or by whom, but let me know in case a separate ticket is needed 🙏🏻
The changes were reviewed in the MenuItem, Select and TypeaheadSearch demos. The alignment between icon and text was correctly maintained under a combination of conditions: increasing the length of item labels to make them wrap, increasing the size of their font, and/or rounding up line height to 1.4 (see comment below). Browsers used: Safari 15.5, Firefox 101 and Chrome v.102.
Hey Sergio. That sounds really good in my opinion, but I should get back at the Design system team for alignment in order to provide a uniform answer. Will do that asap.
Tue, Jun 21
I see and share the concern you're describing. The approach makes it look like some images are still pending or 'failed' to load. After giving it some thought, though, I'd say we should still go ahead with this solution, because it's at least an improvement (the white squares really made the component look broken).
Hey @Catrope 👋🏻 I've been forgetting to ask: do you agree that the implementation of a scroll functionality in the Menu component could be a potential solution for this issue? Copying the main functional requirements from that task (T306932) here for visibility:
Mon, Jun 20
Hi @Sgs! Thanks for sharing your use case. We had doubts regarding the need to incorporate this component into Codex. I originally thought that this could be introduced a styled, reusable <hr> element. Nevertheless, like in the example you shared, these "dividers" are actually implemented as border in most cases (e.g. Wikipedia titles). A far as I can see, we have three alternatives:
Thanks (again) for sharing this really sensible concern, and for already providing solutions, @alexhollender_WMF! 🙏🏻
Tue, Jun 14
Fri, Jun 10
After receiving Alex's thumbs-up (thanks so much for checking! 🙏🏻 ) the changes were verified in the latest versions of Chrome, Safari and Firefox on MacOS Monterey, where everything's looking good. The task can be signed-off from a design pov 👍🏻
This task is ready for design sign-off: all available options in the"Menu with custom menu item display" demo now present the right styling for the hovered/highlighted, active and selected states. Tested in the latest versions of Chrome, Firefox and Safari on MacOS Monterey.
The typefaces' proposal was presented to the Product design team, and shared and reviewed by the members of the Pattern lab team. Feedback was received and acted upon. The current documentation in Figma (access the Typography exploration file here) will need to be adjusted in case we decide to update the CSS font stack to reflect the latest design choices. This possibility is captured in T309158: Update Wikimedia Design Style Guide with typeface choices.
This is nice! It would be great if we could make the configurable MenuIntem interactive. So it would display the selected, active and highlighted states, instead of presenting them in the table. But I believe this is conditioned by the current implementation approach, so all good and ready for sign-off.
No problem at all, @AnneT!
Thanks so much for the detailed explanation and screenshots! Definitely this change makes the issue more apparent, but not scaling icons was going to cause problems whenever font sizes are modified, regardless of alignment
Thu, Jun 9
The Readers Web and Design System teams agreed to let this responsive behavior be handled by Vector, and to not introduce it in the Codex TypeaheadSearch component at this point in time.
The regular label has line-height: 1.6, while the search-query label has line-height: normal plus a 2px margin-bottom. Should these be consistent, too? This would result in a slightly different look in TypeaheadSearch, which makes me think that we should maintain the current search-query line height but move those styles to TypeaheadSearch since they seem to be specific to that component.
The comments were tackled (thanks as always, Bárbara!) and the branch was merged. I added a link to the relevant design specs in the task's description.