@MusikAnimal thanks for reporting this! I'm glad you have a workaround for now. The ChipInput component has a prop, chipValidator, that takes in a function that is run when the user attempts to add a new chip. If the validator returns false, the new chip is not added. We need to do something similar in MultiselectLookup, so that you could do something like this in your feature:

I'm guessing this change to the horizontal layout is the culprit @Amire80 @SBisson

re: acceptance criteria, I don't think we should test that the ChipInput doesn't throw an error when a duplicate chip is added. There are 3 tests that check that adding a duplicate chip causes an error—I think we should just remove those. less code : more code :: dumber : smarter

In T366849#10332598, @egardner wrote:

I'd like to advocate for a simple solution where we either allow the developer to disable the second page-size dropdown if desired, or to just match the Codex CSS-only table pager UI and add a small amount of JS (not Vue) to the page when this class is loaded to submit the form on dropdown selection, without the need for an extra button.

Thanks for all the suggestions @DTorsani-WMF!

I've edited my original comment about the submit button to add an option for showing the submit button only when JS is not enabled.

In T366849#10327219, @CCiufo-WMF wrote:

Do we plan to keep the pagination at the top and bottom of the table? I think it looks most empty on the top because there are no other elements in the header. I'd imagine it looks less empty on the bottom?

Thanks for sharing this use case @Sarai-WMF! For now, you could override these styles set on the selected menu item to reset the styles back to default:

@CCiufo-WMF yes, it can be moved to the backlog

We need to figure out if we really want the items-per-page select in the pager section, or if we want to keep it in the filters section above the table. Without JS, we would need a submit button to go with the select, like so:

@Dogu as discussed elsewhere, but posting here for posterity: this task was originally going to cover updates to both the MediaWiki TablePager and the CodexPHP Table, but now that we're not using the CodexPHP Table for the MW TablePager, this task will just cover setting up the empty state in the new CodexTablePager class. I still think it was worthwile to set up the empty state in the CodexPHP Table, so thank you for completing that!

For now, we can just use the DMN patch above to test CodexTablePager via the AllMessages special page. We'll need to add sort to AllMessages, or customize another TablePager instance, to test the sort UI.

@egardner Agreed; I wasn't successful setting up a copy of it in CodexExample so it might be easiest to just work with the real AllMessagesTablePager locally and even consider updating it for real once the migration is complete. For testing purposes, we can edit the table to add sort, a caption, etc. and just not merge that work.

Hey @DSmit-WMF - this is now available in Codex as well :)

@Michael please let us know if you have any further issues with this!

@DSmit-WMF slots for message content are now available in the Field component! Please let us know if you run into any issues using them.

@Esanders can you please clarify whether this needs to be announced as a deprecating change, or if you/other staff intend to handle the necessary updates yourselves? I read the thread on the patch about this but wanted to make sure I understand what needs to happen.

@Dogu The MediaWiki TablePager class uses a message called table_pager_empty. IMO, the CodexPHP table could just expect an empty state message to get passed into it, and not set one automatically. When we update the MediaWiki TablePager to have a Codex display format, we can pass in the table_pager_empty message to the CodexPHP Table for display. What do you think?

I think setting up a TablePager in CodexExample is our best bet. Locally, we can check out the right branch in the CodexExample extension, and this won't affect our work in the core repo.

I'm not sure if this behavior should be consistent across all components. Some components (Button, binary inputs, etc) do something when pressed (active), so it's somewhat important to show a distinction between when the component is active vs. focused. Often, the thing that happens when the component is pressed happens intentionally on mouseup - for example, if you mousedown on a MenuItem, then move your mouse outside of that MenuItem before releasing it, you will not select the MenuItem.

The Codex patches are open, and there's a Codex PHP patch that will resolve this but shouldn't be merged until after the next Codex release.

Re: z-indexes, IMO it would make sense to remove the z-indexes on the page layout sections to allow the more specific z-indexes on individual components to take effect. This is how the scale is meant to work, and the z-indexes on .mw-header and .mw-page-container are interfering with that. In theory, removing these z-indexes shouldn't negatively affect the TypeaheadSearch menu, since it (along with all Codex menus) has a z-index of 50 and, as Jon mentioned, most menus are only open when focusing on the triggering element so only one should be open at a time.

@Michael Aha, thank you for clarifying this! I've added a test that checks the input event when the inputValue prop is used in my patch.

Ahh yeah, this makes sense - we planned the empty state to apply to a Table with absolutely no content, but it makes sense that you might display a table with a thead with defined columns, but no rows. The colspan solution is a good idea.

@CCiufo-WMF oops, yes - I've merged it into that one

This would be easy to do, we'd just need to use the CSS-icon mixin on specific classes:

Assigning to myself as the responsible individual, but @ItamarWMDE is working on the patch to implement this and I'll be doing the documentation