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.

Hey @simon04 – we've introduced a new CSS file, codex.style-bidi.css as of Codex v1.12.0. This file is not intended for use in MediaWiki but it could be loaded by a stand-alone app like yours if you want to support client-side direction switching.

I think a follow-up patch that makes these new demos a little more meaningful (for example, by including a status message that shows up when the components are in the "error" state) would be a good idea. But I agree that this is not blocking for now.

In T371998#10114762, @Nunya wrote:

Hi @egardner, I would like to give this a shot. Can I go ahead and assign it to myself?

Hi @ItamarWMDE, thanks for this task and the associated patches. I've filed T373941 to represent the fact that the DST engineering team will spend some time discussing and considering your suggestions over the next 1-2 weeks, and we'll get back to you.