if we don't have any other examples where codex lacks anything meaningful that jqueryui has, can we just edit this task to a mere feature request for a draggable window (which is likely going to be declined anyways)?

a question born from ignorance & curiosity: given that codex received several minor updates after 2.3.1, should this task still stay open?

thanks!

basic feature parity

in my humble opinion, draggability for a dialog isn't «bare minimum». either the statement of «codex not being insufficient», or the example, isn't quite right. there are plenty examples of fully-functioning gadgets and other interface modules built using codex, without a single line of jqueryui.

In T433433#12167105, @DVrandecic wrote:

In my head it was. :) My bad

manually connected the article to the wikidata item. was this supposed to happen automatically?

2 examples seem to be present on the current version of the docs:

happy to have you as a contributor in the community!

In T432676#12164067, @Neelimaa1 wrote:

Submitted the Gerrit patch for this task. Kindly review it when you have time. Thank you!

In T432676#12142287, @Neelimaa1 wrote:

Hi! I'm working on this task now. I'm looking into the issue and will update it with a patch soon.

hey! thanks much in advance! ^^

In T426193#12004417, @Sgs wrote:

@ekrem could you elaborate what is the test: with the --line-height-medium styling disabled via devtools trying to validate?

In T428556#12001389, @Pppery wrote:

In T428556#11998171, @ekrem wrote:

i think there should be a boolean column in the interwiki table to turn this auto conversion on/off for any interwiki link, tbh. it's not the best experience having to replace all space signs with plus signs when linking to [[google:]], for example.

See the (admittedly poorly-named) T43618

In T426193#11941826, @Sgs wrote:

This is not testable until a new Codex release is created. I'm on the process of getting the right provisioning to do so, until then moving to blocked.

screenshots from https://doc.wikimedia.org/codex/latest/components/demos/message.html:

i think there should be a boolean column in the interwiki table to turn this auto conversion on/off for any interwiki link, tbh. it's not the best experience having to replace all space signs with plus signs when linking to [[google:]], for example.

In T414882#11784560, @Jdlrobson-WMF wrote:

Thanks for flagging @ekrem the collapsible headings were not shipped as intended (but not in the way you flagged) and we've restored padding around them thanks to you bringing to our attention.

However the issues you are flagging seem to relate to overrides in MediaWiki:Minerva.css here > https://en.wiktionary.org/wiki/MediaWiki:Minerva.css#L-127 for example. @Ioaxxere could you take a look? It seems they were added in 2024

i'm sorry if this is not the place, but i thought opening a new task while there's already an ongoing one would be a bit too much.

the fix causes another visual issue, as observed on enwikt (Module:data tables as an example):

In T410264#11378610, @kostajh wrote:

@ekrem thanks for the offer, but apparently it should be fixed soon per T357352#11370504

In T410264#11378362, @kostajh wrote:

Thanks for filing. It's an issue caused by some work done here T357352#11361006

In T398529#11037058, @Izno wrote:

In T398529#11036991, @ekrem wrote:

i'm sorry for not reporting this earlier, but on azwiki, where the change resides in common.css, the fix doesn't affect the minerva skin (see fig. 1).

The mobile website does not load Common.css. Minerva on the desktop website is fine.

i'm sorry for not reporting this earlier, but on azwiki, where the change resides in common.css, the fix doesn't affect the minerva skin (see fig. 1). it just doesn't get loaded, and it doesn't appear in the computed styles section in the devtools of the browser (see fig. 1); i don't know why. such an issue isn't present on my local wiki (see fig. 2 and 3).

fwiw, this could be a temporary solution :3

In T398825#10979242, @Krinkle wrote:

The amount that the icon is cut off seems to depend on context. Not sure if this is a surprise or not, but thought it worth mentioning.

Here's uselang=en and uselang=de compared.

Ref T353005.

hello! see T398529 :3

In T398621#10972988, @A_smart_kitten wrote:

Unless I'm missing something, seems potentially similar to T398529: Message: icons can get cut off depending on message text length?

In T396665#10907167, @Nemoralis wrote:

It’s likely due to this change in Common.js: https://az.wikipedia.org/w/index.php?title=MediaViki:Common.js&diff=prev&oldid=8163271

I have now disabled (commented out) the code

cc @ekrem

this is what i think as well; since there was no sitenotice shown after the 11th, there wouldn't be a close button as well. the error could be likely prevented by an optional chaining. sorry for missing it and thanks for letting me know :3

@CCiufo-WMF, of course; i'm rewriting a "summary buttons" gadget in codex, which lets you quickly fill in the edit summary:

it looks like i didn't notice that the edit form is a literal <form> :D now that i try the aforementioned <cdx-button type="button" />, it works perfectly. thanks to everyone engaged in this task :3

In T391775#10739186, @CCiufo-WMF wrote:

I don't think this is a Codex issue. The button doesn't automatically apply any special attributes like type="submit". I imagine the behavior would be the same with any button added to the editor interface.

In T391512#10728590, @Johannnes89 wrote:

the language selector located to the right of the page name isn't functional at all in the editing mode.

It's working in Wikitext 2017 and VisualEditor, but not in the regular 2010 Wikitext editor

In T391512#10728532, @Aklapper wrote:

i'd like to access interlanguage links without switching to the reading mode

Why? Please provide a use case.

@CCiufo-WMF, as a wikipedian, i frequently use some gadgets like categorymaster and twinkle to ease my work, however, their aged ui which is not optimized for the dark mode and mobile devices makes using them a pita. so, as a dev who already has some experience with vue, i decided to build a replacement for them, enhancing their interface using codex — whence the name comes. the gadget also includes some codexified interfaces that were built with ooui, or were handled directly using wikitext etc. (such as move requests, upload requests etc.)

@CCiufo-WMF, one thing i can show you atm is a link added to the personal portlet, which opens the aforementioned settings panel. i'm using the codex icon (i used the raw logo file in the example) to distinguish it from the user preferences link:

In T387668#10625761, @CCiufo-WMF wrote:

Cool! Do you have any screenshots you can share? We don't usually refer to Codex directly in any interfaces built with it, so it would be good to see the use you have in mind.

Again, we're not really opposed to adding the icon, but want to understand first how it might actually be used, because we haven't previously identified a need.

@CCiufo-WMF, thank you so much for your attention. yes, i'm building a gadget for azwiki using codex and i think there is a place where the icon fits :3