With @lwatson's patch, you can't accidentally de-select an item in a multi-select menu using the Tab key.

I think the conclusion here is that we don't recommend the Codex link styles should be applied to all a elements in a blanket fashion in an environment like MediaWiki, where there are lots of other a elements which need to look and behave differently. These styles are intended for text links, not for buttons/menu items /etc. We provide the Link styles as a mixin to allow users to specify custom selectors in order to avoid these collisions.

In T375826#10189869, @thcipriani wrote:

Hey @egardner I talked to @dancy at the end of last week, and he's carving out time this week for frontend/codex work.

As to where the scaffolding lives, I think this would live inside the scap codebase (but I'll leave it to @dancy to veto that idea).

In T374873#10189633, @Dogu wrote:

It doesn't seem like there would be an issue with keeping our i18n folder directly in the main repository. Instead of this task, perhaps we could add the Codex PHP i18n translations to translatewiki.net by filling out the new project template. Alternatively, if there is already an existing translation for Codex, we could consider setting up an update in the Codex PHP repository as well.

Hey @thcipriani – do you all have any idea when you all will start this work, and who will be doing it? We have carved out some time in our current sprint (which begins today) to help with this. Just trying to make sure that myself or another DST engineer is available when you all are ready to start, especially if some dedicated pair-programming time ends up being called for.

We're going to proceed with the current approach (builders that return immutable widgets which can be further passed around, combined with a dedicated getHtml() method) and see how it works.

A couple of initial thoughts/recommendations:

I think for the DST side I can say that, if we went in this direction, we'd want to have at least one or two non-DST engineers involved as maintainers to make it clear that this was a shared responsibility. Ideally folks from a few different teams (including DST) would have a hand in this codebase.

In T375181#10169527, @Bean49 wrote:

Thank you. Is there any CSS trick I can apply until then?

I've moved this to blocked because there is some uncertainty of whether this should be applied at the skin level or within Codex itself.

In T374876#10169398, @MusikAnimal wrote:

In T374876#10169251, @egardner wrote:

Hey @MusikAnimal – could you provide a little more context and information about what sort of input you are looking for from us? I can do a quick pass to look at your usage of Vue.js and Codex to look for coding conventions, best practices, etc. but if you are looking for anything more specific let us know.

A quick review to ensure we're not doing anything dumb with Vue/Codex would be great!

Hey @MusikAnimal – could you provide a little more context and information about what sort of input you are looking for from us? I can do a quick pass to look at your usage of Vue.js and Codex to look for coding conventions, best practices, etc. but if you are looking for anything more specific let us know.

@Dogu would it make sense to have a build method to return the constructed object as well as a render method which 1) constructs the object and 2) returns the final HTML in a single method? Then we could provide a simple approach for convenience as well as a possibility to do more involved things (pass around a constructed component with all data before rendering) where necessary?

In T373708#10166283, @Dogu wrote:

I agree with @LucasWerkmeister, so after the discussion, I started a refactoring process again. I can finish this refactoring within this week and discuss it again. Anyway, refactoring doesn't change the API; on the contrary, it allows us to create more API approaches.

Hi @Bean49 – this is a Chrome bug; I've filed an upstream bug report here: https://issues.chromium.org/issues/369085363

In T373989#10154171, @AnneT wrote:

I like the attribute selector solution, but would recommend we add it in Vector (and Minerva if applicable) where the mixin is applied rather than in the mixin itself. The additional specificity—the equivalent of adding a class—is not ideal, so I think we should only add it where it is needed: inside MediaWiki where there are many anchor elements styled as buttons. We don't recommend styling links as buttons, so I don't think it's worth the additional specificity to account for it in the mixin, which could be used outside of Vector/MW.

@Esanders @dchan I'd like to update the Codex link mixin (which gets applied by Vector and inadvertently targets OOUI link-buttons) to exlcude any elements with [role="button"].

In T251790#10139509, @MusikAnimal wrote:

Yes thank you all!

Should we do anything about coverage reports? It's be great to have them published on https://doc.wikimedia.org/cover/

I'm also working on the documentation. Please feel free to review/edit as you see fit! https://www.mediawiki.org/wiki/Jest

We are finalizing language for RELEASE-NOTES but this task can be considered complete. Thanks to all the participants for helping to close out this 4+ year old task!

Thanks to @Ladsgroup for shedding some light on our CI configuration process.

@DLynch what do you call the pop-up widgets like "Edit Link" in VE? This was the element that was being rendered in #mw-teleport-target and being improperly sized right?

In T373875#10130197, @CCiufo-WMF wrote:

In T373875#10129301, @Esanders wrote:

I don't think there are upstream changes needed here. The fix is to not apply font scaling to interface components in the content area. Unless you plan to start scaling interface components?

Okay, I might be misunderstanding what happened here. You're right that the intention is not to scale the interface with the font size preference for now (that's open for discussion in T370549). I think there were still some concerns from DST around use of hardcoded font size values and mw-teleport-target styles. Maybe @egardner can provide some more info.

Thanks for resurrecting this task! So far all Vue code has lived in skins or extensions, but if we are going to put components into Core directly then we should have a test suite there as well.

In T373708#10127749, @Dogu wrote:

We've fully transitioned to using Mustache templates for all components, replacing PHP-based markup generation entirely.

In T373872#10116068, @ItamarWMDE wrote:

Hi @egardner, thanks for the prompt reply. The current use case is described and linked in the ticket itself. The idea is to not have to replicate logic that is already afforded to us by browsers and is part of the WHATWG standards. In particular, to be able to use constraint attributes on codex components and leverage the Constraint Validation API instead of fashion our own validation checks (or use 3rd party libraries). Each of the components can adhere to different constraints, of course, as described in the linked WHATWG HTML Standard: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#constraints

Hi @Raisha_Abdillah and @HendryVarianto03 – thanks for reaching out and sorry that this feature has not been better documented yet. We developed the dark mode feature based on some work that was being done in the Vector skin, and we haven't fully fleshed-out the non-MediaWiki usage of this feature.