Thanks for providing this updated design! I've responded below to the open questions in the task description.

This would represent a breaking change for some components. For example, if we change the Message component's dismissButtonLabel prop from required to having a default value of 'Dismiss', that prop can no longer be relied upon to enable the dismiss button. We would need to add a new boolean prop, useDismissButton, to do this. We probably should have done this from the beginning, but it seemed redundant at the time. IMO, this seems like a good case for Codex 2.0.0.

In our theme's publish.js, a helper function from JSDoc,getAncestorLinks()[1], is used to generate the link markup for the title elements. Note that publish.js's getAncestorLinks() returns helper.getAncestorLinks(), which returns an array of link markup for each title section.

In T361285#9671047, @DTorsani-WMF wrote:

Question: What would you think is the proper way to write the following sentence?

A

A Button should not be styled as a Link and a Link should not be styled as a Button.

or

B

A button should not be styled as a link and a link should not be styled as a button.

I think option 2 is the most intuitive and grammatically correct, with the least gray area.

@CCiufo-WMF I think we should move this task to the backlog Up Next. This is a subset of the font-size decisions we need to make, and recent discussions have led us to pursue options for desired design behavior first, which can then be followed by deciding how to implement the behavior. Handling font-size tokens is part of that latter decision. We may want to find another way to represent the font-size discussion work on our sprint boards, but IMO this task is specific to one decision and can be backlogged for now. I'm hoping we can get back to it in a sprint or two, once we've made more headway on the design decisions.

See T361048 for the TablePager evaluation task

@Volker_E @Catrope feel free to edit/add to the task description

In T360154#9662388, @Sarai-WMDE wrote:

I wonder if "Simplifying the pagination UI to us as little text/labels as possible" could still have an impact on this decision? My plan was to explore that next.

@Sarai-WMDE I discussed table pagination with the DST engineers today and we came up with some more option questions, even beyond what you and I had discussed earlier. One big blocker may be the translatable label thing - this really does demand a solution like the one proposed in T345386, so that users don't have to pass in numerous translated strings that are the same across most projects. Because of this, and the general complexity here, we think pagination should be removed from the MVP scope and tackled as a separate feature post-MVP. I still strong believe that we should build the pagination UI for consistency's sake, and to prevent Codex users from having to replicate it across projects, but I think we should complete the rest of the Table component first, then tackle pagination as a new feature.

Tagging @lwatson, @Catrope, and @Volker_E since y'all have discussed this margin recently. I don't know exactly why it was implemented the way it was, so please feel free to update my opinionated summary in the task if you have more insight!

@Sarai-WMDE please do combine them, thanks!

I think option 2 is the "correct" way to do this. The 14px context is specific to Vector, so I think the demos of our components in a 14px context should just be displayed in Vector itself. I think this is important for 3 reasons:

1. Philosophical reason: it keeps Codex, including the docs site, skin-agnostic. Having a font-size switcher on the docs site seems cluttered and confusing to me.
2. Technical reason: we are currently discussing making major changes to the way we support using Codex in a 14px context, including shipping a single font-size mode and enabling users to override font-size tokens in their projects (e.g. in Vector). I don't think we should build a font-size switching system on the docs site that might be subject to change, or might not exactly replicate what happens in Vector, which could increase the risk of regressions or unexpected results onwiki.

@Catrope I want to clarify what this task covers. I see 3 distinct things that could have descriptions and optional flags:

Is this just one icon, or do we actually need 3?

1. Sortable, but unsorted (both arrows)
2. Sorted ascending (just the up arrow)
3. Sorted descending (just the down arrow)

In T359074#9638530, @Sarai-WMDE wrote:

Would the prop modify the alignment of any elements within cells? I'm asking because probably the most common use case might be to center-align components.

Documentation for code splitting usage was done with T350792; see https://www.mediawiki.org/wiki/Codex#Requiring_Codex_components_in_MediaWiki_and_extensions and https://www.mediawiki.org/wiki/Codex#Requiring_Codex_component_styles

@Sarai-WMDE is there a use case for aligning the text in a cell to the center? Eric brought up a good point in my patch to introduce a way to align text to the end: perhaps we should include a prop called align that defaults to "start" but has option start, end, and center. Thoughts?

In T360078#9631095, @Sarai-WMDE wrote:

Regarding the sort icon behavior, the only bit I would adjust is:

"When a user clicks a column to sort it, then clicks again, the column becomes sorted ascending" -> Observing existing examples, it appears that an ascending sorting order should be applied right away when the sortable column's heading is clicked.

In T359074#9631327, @Sarai-WMDE wrote:

Regarding the footer: Looks like we just need to apply box-sizing: border-box to .cdx-table__footer in order for the padding to be included in the min-height

@Sarai-WMDE could you please confirm the sort icon functionality I listed in this task?

@Sarai-WMDE I implemented both of these things, but wanted to get your feedback on the results.

Feedback that would be helpful:

• What do you think of the proposed solutions?
• Are there other potential solutions?
• Does anything need to change on the Figma end, in addition to any changes we might make on the implementation end?

Thanks for this feedback, @Sarai-WMDE! I've implemented items 1-6. For the header min-height, I added a component-level token. There are 2 items I haven't addressed yet:

@Sarai-WMDE could you please check out these demos and let me know if you have any design feedback? Thanks!

FWIW, while the Codex Field component differentiates the label text and description text for fieldsets, they are both contained within the <legend> element - in my research, I found that this was the only reliable way to ensure that, when you tab into a fieldset, both the label and description are read to you. I still think this task needs to be done to allow you to pass in separate things for label, optional flag, and description, I just wanted to make this note about the resulting markup.

@CCiufo-WMF the latter; we've thrown around some ideas but are far from a solid long-term solution IMO