• Once merged in Vector copy the same rules across to the mobile equivalent for non-AMC users

^^ Please ignore, I accidentally attached the wrong patch

@alexhollender It's trivial, and I'm happy to change it to whatever value you prefer as part of this ticket, but if we go with the 85% are you okay with the hover state of the buttons overlapping with the OBOD?

Or I guess we could use a :hover:after selector to match the hover color to make it not look weird 🙂. Assuming this is what we want when hovered? :

After looking at this more today and unless I'm missing something, I think the fade out technique works better on elements that don't also have a hover state like our user menu links. Notice when the user hovers over the talk link, the gray hover state appears with the fade at the end which could be confusing:

The w3 accessibility recommendations for a combobox could be more explicit on how to handle the tab key, but given that the search component supports the recommended up arrow/down arrow key navigation [1], I'm not sure how necessary (or even desirable) it is for the tab key to navigate through the search results. It is also notable to me that in their example of a combobox, the tab key does not navigate through the results - it only supports up/down arrow key navigation [2]

Something interesting is going on here as it seems to work for me:

@Jdlrobson I was just discussing with @cjming this morning my confusion around popups that have the .mwe-popups-no-image-pointerclass, the .mwe-popups-image-pointer class and popups that don't have either as their usage of those classes (or lack thereof) didn't make sense to me and still doesn't make sense to me.

This was actually an issue I noticed before I7ca6c922b2f4615103e4162d96fd90d891deb1df, and I don't believe is a recent regression. E.g. If you checkout the commit before (1a62ae90cde931763c0fbbf06d1ecff98061ef9d you should see it:

@alexhollender I think I messed up the top spacing on this as well as for some reason there is 12px of top padding + 2px of top margin when T285786 clearly advises only 8px. It should only have 8px of top padding, correct?

@alexhollender Revisions done. Please check latest at https://patchdemo.wmflabs.org/wikis/e097002f78/w/

@alexhollender Can you please check https://patchdemo.wmflabs.org/wikis/608ecb4afa/wiki/Main_Page, and let me know what revisions I need to make. Please note that I am aware of deviations from the spec on the following items and wasn't sure how important they were to you:

Sorry for noise, this is a duplicate of T286822

Moving to upcoming per my POC patch above

POC above. There are several issues going on here (one of which is the text's margin getting clipped as a result of clip-path which @thiemowmde pointed out).

Moving this back to code review per the above patch ^^

Looks great!

Looks good!

we will need to address the spacing between the search (both collapsed & expanded state) and the user icons. should we address that here, or in T285786? cc @Jdrewniak

@alexhollender just a heads up - this has now been merged so it's best to do the design review on beta (https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page) rather than the patchdemo

In T284242#7206819, @alexhollender wrote:

notes from a discussion @nray and I just had:

• we will use a click event to handle the closing of the expanded search field, rather than trying to use the focusout event
• we will modify/remove the max-width on the input field so that it always takes up all available space when expanded
• I will file a separate task regarding the tab behavior for the search menu

How elaborate do we want the sticky header to be for this ticket? Do we want it to have all of the show/hide behavior that is in the prototype: https://people.wikimedia.org/~jdrewniak/dip/p4.html#/en/wiki/Moon ?

@alexhollender can you please take a look at the above patchdemo and let me know if I've missed anything regarding the behavior or design? The icon spacing/sizes is another issue that I believe is being covered in another ticket.

We estimated this a small based on the simplest option of changing the id to pt-talk-alert in Echo. If we want to instead change the default id for this in core, then we should reestimate this ticket as that work would likely be larger than a small.

@Jdlrobson This bug will only surface on new Vector when $wgVectorConsolidateUserLinks = [ 'logged_in' => true ] . Given that $wgVectorConsolidateUserLinks is not enabled in production yet, I don't think it's currently affecting users

It's not clear to me whether this task is focused on real user monitoring (RUM), but synthetic tests to measure search performance were added to the dashboard as part of T251544 . I will close this ticket under the assumption that a more focused ticket for RUM can be created in the future if desired

I think the next question to figure out is whether we want this to only affect modern Vector or whether we want this in other skins as well (e.g legacy Vector, etc). We could, for example, get rid of the transformation logic in other skins and always have the talk link show e.g. in legacy Vector it could look like:

I've moved this back to code review because in the midst of writing up QA steps I noticed a bug involving modern Vector with the $wgVectorConsolidateUserLinks flag enabled (legacy/other skins aren't affected AFAICT) where the notification element has the wrong class (#ca-mytalk instead of #pt-mytalk) and the link is missing the title and accesskey attributes.