Looks like there's currently no way to feed in raw HTML input into the Table component. As a result, all of the links, checkboxes, and buttons do not render properly.

Two other component-related issues in trying to get this off the ground:

• The Checkbox component also requires a label and an ID, which the design does not have. It's probably good to have a label for the checkbox, but it should probably be hideable (similar to the "invisible label" approach that OOUI has).
• The Table component also has its own <form>, which conflicts with the existing <form> that we have wrapping the entire UI for form handling.

Marking this as stalled for now, since these will probably require changes in Codex PHP first.

Change #1111614 had a related patch set uploaded (by Abaris; author: Abaris):

[design/codex-php@main] Table: Allow raw HTML content in columns

https://gerrit.wikimedia.org/r/1111614

Change #1111629 had a related patch set uploaded (by Abaris; author: Abaris):

[design/codex-php@main] Renderer: Fix usage of visually hidden labels in renderers

https://gerrit.wikimedia.org/r/1111629

Hi @Chlod,

I've addressed the issues you raised regarding the Table component and Checkbox label handling in Codex PHP:

• Raw HTML input is now allowed in the Table component.
• The Checkbox, ToggleSwitch, Field, and Radio components have been updated to properly support visually hidden labels using the isVisuallyHidden property.

Please take a look when you have time. Let me know if any further adjustments are needed.

Thank you very much for the changes @Dogu! I've tested the changes locally and it seems to be working well.

For the Table, the header content still does not allow raw HTML, but I've decided to write about that further in the Epic task than here (T377494#10472075), as its underlying scope is probably larger than just the Table element.

Change #1111614 merged by jenkins-bot:

[design/codex-php@main] Table: Allow raw HTML content in columns

https://gerrit.wikimedia.org/r/1111614

Change #1111629 merged by jenkins-bot:

[design/codex-php@main] Renderer: Fix usage of visually hidden labels in renderers

https://gerrit.wikimedia.org/r/1111629

Change #1114724 had a related patch set uploaded (by Abaris; author: Abaris):

[design/codex-php@main] Table: Allow raw HTML content in header

https://gerrit.wikimedia.org/r/1114724

Change #1113759 had a related patch set uploaded (by Chlod Alejandro; author: Chlod Alejandro):

[mediawiki/extensions/Nuke@master] [WIP] Change Nuke's page list to a table

https://gerrit.wikimedia.org/r/1113759

Change #1116494 had a related patch set uploaded (by Abaris; author: Abaris):

[design/codex-php@main] Label: Do not sanitize label text and add taint annotations

https://gerrit.wikimedia.org/r/1116494

Change #1114724 merged by jenkins-bot:

[design/codex-php@main] Table: Allow raw HTML content in header

https://gerrit.wikimedia.org/r/1114724

@Chlod, it looks like the relevant changes have been merged. Can you revisit this patch to see if it's now unblocked? Also, let us know if you still have the time to finish this patch, otherwise we can pick it up 😄

Hi, @Scardenasmolinar! Working on this now. 🫡 Looks like the button can now be put on the page, and the issue with the label for "SQL LIKE pattern" has been resolved. The last thing we're stuck on is the namespace selector, which still doesn't have a Codex PHP equivalent. Technically, that's a blocker for T153988, but since this is technically a subtask of that, it's also blocking this one.

In T381660#10537683, @Chlod wrote:

Hi, @Scardenasmolinar! Working on this now. 🫡 Looks like the button can now be put on the page, and the issue with the label for "SQL LIKE pattern" has been resolved. The last thing we're stuck on is the namespace selector, which still doesn't have a Codex PHP equivalent. Technically, that's a blocker for T153988, but since this is technically a subtask of that, it's also blocking this one.

Thanks for the follow-up Chlod! On our RTL we discussed this ticket and have a couple of questions:

1. Can we merge this task before T153988: Migrate Special:Nuke to Codex without breaking functionality?
2. Do we have to wait for Codex PHP to be added to vendor to merge this patch?

Our line of thinking is that we want to merge this if it's feature complete and works even if T153988: Migrate Special:Nuke to Codex is still block on the MultiSelect widget.

In T381660#10542541, @Scardenasmolinar wrote:

In T381660#10537683, @Chlod wrote:

Hi, @Scardenasmolinar! Working on this now. 🫡 Looks like the button can now be put on the page, and the issue with the label for "SQL LIKE pattern" has been resolved. The last thing we're stuck on is the namespace selector, which still doesn't have a Codex PHP equivalent. Technically, that's a blocker for T153988, but since this is technically a subtask of that, it's also blocking this one.

Thanks for the follow-up Chlod! On our RTL we discussed this ticket and have a couple of questions:

1. Can we merge this task before T153988: Migrate Special:Nuke to Codex without breaking functionality?

No, since the code for it resides within the Codex PHP renderer, because it requires Codex PHP to begin with. Refactoring the patch for this to run parallel to T153988 will duplicate most of the code from that patch that it's not worth it.

It would have been possible to merge +/1107343 (the task for T153988) already, and that was the case for the past few weeks that the patch has been open, but changes to wikimedia/codex that were introduced as part of v0.5.0 just a few days ago means that patch is now failing due to taint category incompatibilities*. I've already pinged Dogu about this, and I'm hoping to hear a response soon. Of course, it still won't work in production since wikimedia/codex is not in mediawiki/vendor.

* Codex PHP's LabelBuilder::setLabelText() taints argument #1 with exec_html, but MediaWiki's Message::text() taints its return type with tainted.

2. Do we have to wait for Codex PHP to be added to vendor to merge this patch?

Our line of thinking is that we want to merge this if it's feature complete and works even if T153988: Migrate Special:Nuke to Codex is still block on the MultiSelect widget.

To merge: no. To work: yes. This is the case for both this task and T153988, ever since the discussion we had about making Codex an optional dependency.

In summary, T153988 and this task (though it is still somewhat feature-incomplete) could have been merged some time ago already, though with the interface having a multiline "namespaces" text box instead of a MultiSelect. But Codex PHP v0.5.0 is causing issues which prevent that. As soon as that's resolved, it should be possible to merge both. I'll finish up the rest of the code for this task now, so that the only thing that'll be needed is a final version bump on +/1107343 before both become mergeable.

@Chlod; this sounds good. Once the issue with 0.5.0 is resolved, let's be ready to merge in the work as soon as possible.

T153988 ready for review, this one not. Sanitization on table headers means we can't place the checkbox at the header of the first column which selects all or none of the pages on the table.

Change #1124869 had a related patch set uploaded (by Abaris; author: Abaris):

[design/codex-php@main] Table: Allow raw HTML content in header columns

https://gerrit.wikimedia.org/r/1124869