To ensure things don't get lost in the comments here, I'm adding the specific design review tasks (and patches that address them) to the top of this ticket.

In T303321#7837501, @bmartinezcalvo wrote:

@egardner I don't agree with this, we should have one only Tab/Tabs page. If you want we can add two different demos in the same page, but having 2 different pages for the same componen will be confusing for users. It seems that the Tab only has 2 tabs while Tabs has more than 2 tabs, why don't we mix both in the same page and we add a demo prop to configure the number of tabs you want the component to display?

In T303321#7834644, @bmartinezcalvo wrote:

@egardner I send you some corrections I've found in the tabs while reviewing the demo:

1. Why we have 2 different component demos: Tab and Tabs?

I've added a basic prototype MW skin called "Incunabula" – the project repo is here: https://gitlab.wikimedia.org/egardner/incunabula-skin

In T303321#7823228, @Catrope wrote:

Another scroll-related issue is that, when you use the arrow keys to navigate to a tab that is out of view, the tabs bar doesn't scroll, and you end up navigating between tabs that are invisible.

In T303321#7820509, @Volker_E wrote:

@bmartinezcalvo One reason to rely on box-shadow and border combination for the focus in OOUI was to have rounded focus outlines. The tabs above in your example feature 0 radius edges. I'd unify those.

I've filed a bug task for the demo behavior I mentioned upthread: https://phabricator.wikimedia.org/T304894. This is an issue coming from Vitepress, not from the component itself.

In T303321#7795536, @bmartinezcalvo wrote:

If it's possible to update the focus state, I think option 2 (blue outline around the tab for both type of tabs) is the most unified option with the rest of our components with focus state.

Personally I would like to see gadget and user script authors gain the ability to start using Vue and Codex for their own projects. I think this will eventually be possible but there are a couple of blockers at the moment.

You can see a live demo of the Tabs component here:
https://772516--wikimedia-codex.netlify.app/components/tabs.html

@Volker_E I agree that we should evaluate some of the keyboard behavior (like how Up and Down arrows should work). It should be pretty easy to change things if we decide that one approach or the other is the best. Same goes for the "wrap-around" behavior – I can enable this if needed but I wonder if things are clearer/more obvious to the end user without it.

This has been resolved, the impacted code is running again in the target browsers.

Closing as declined since we're deprecating WVUI for Codex (which uses Vite, built on top of rollup) shortly.

@bmartinezcalvo I was just working on this today. I'd like to propose a few changes to this based on what I've been reading in this article: https://inclusive-components.design/tabbed-interfaces/#keyboardbehavior.

I've deleted the main branch in Gerrit, and cherry-picked the only commit which had been merged there but not to master. The master branch can be considered canonical from here on out.

Sorry about this – I initially created this repo in Gitlab where main was used, I didn't realize this would cause problems.

Wow, this is cool! Now that we have this capability, I'm open to suggestions on ways to develop the VueTest extension to make it more useful for QA testing purposes. Would it make sense to have a single dedicated Special page per Codex component (one page could show multiple variations of course)? Should we try to embed the actual demo code from the docs site inside of MW somehow?

In T303321#7781197, @bmartinezcalvo wrote:

Closing this because the extension exists and is in Gerrit. We can open follow-up tasks later if we need to add new functionality here.

I've set this task as a subtask of the Codex Alpha milestone, because it seems like the bulk of the Codex / Abstract Wiki case study is going to revolve around swapping out the existing SD components with Codex equivalents, and making small adjustments where necessary.

In T303321#7777074, @bmartinezcalvo wrote:

@STHart @egardner I've assigned this task to add the disabled state. Do we have the example with disabled tabs for AW? I would like to review it to better understand this use case.

I support investigating clever ways to import/embed type definitions, but I know that can be a bit of a rabbit hole.

@Sarai-WMDE @bmartinezcalvo I've fleshed out this task a bit more and added some relevant information. @STHart I think we may need to prioritize development of this component because not having it will block Vue 3 migration for some projects (because folks who need this layout are relying on an earlier version of this component which is not Vue 3 compatible). Fortunately we 1) have the designs more or less (going back to OOUI), and 2) some implementation work has already been done in old patches and can be used as a starting point.

This task is looking like it is probably not worth the effort; moving to "blocked" for now.

In T300573#7770737, @Jdlrobson wrote:

@egardner @Catrope I've come to the conclusion that it's going to be too painful to convert WVUI to Vue 3, so I think switching WVUI+Vue 2 for Codex and Vue 3 at the same time is inevitable.

I think I was unclear on the desired UX when we were working on selectHighlighted – we actually never want something to be selected and highlighted at the same time due to keyboard navigation, correct?

Is merging of https://gerrit.wikimedia.org/r/c/design/codex/+/770014 blocked until this issue is resolved, or should this be handled in a follow-up patch? I assume the latter but just want to make sure.

@Mhurd We've migrated this extension into Gerrit, so you may want to update your Makefile / Docker setup to clone from the new repo: https://gerrit.wikimedia.org/r/mediawiki/extensions/VueTest

So is the appropriate comparison codex-typeaheadSearch.umd.js (at 23.5KB) vs wvui-search.js (at 19.8KB)?

Great, glad that idea makes sense to everyone!

Does the spacing between MenuItem Icons and labels/descriptions look a bit tight to anyone else?

Getting all the Typescript configuration working properly will be a big hassle here I think. The guidelines I was developing over at T302831 assume a JS migration; migrating between two TS codebases adds a lot more effort because the types shipped in Vue have undergone a lot of changes as well.

@TheDJ thanks! I think that in our case the initialization code will look something like this (inside the mounted() hook for the Player.vue component):