To add a bit more explanation, the original colors are not colors available in Codex. So to assign these as tokens, we need to use the closest existing color while considering how the two new colors compare to one another.

Sounds good to me!

Thanks for this response and analysis. I think we should try a couple of different options, as listed in the description (updated). One thing to note is that with our first pass as dark mode colors, it was not necessarily a goal to have the same contrast ratios that are in light mode. Instead, we are optimizing for slightly less contrast while still being accessible to optimize for readability, which we know changes from light mode where a higher contrast in colors doesn't affect readability whereas in dark mode it can for certain people. This is not to counter the suggestion to darken these colors to create more contrast, but a note against the need to match the same contrast ratios in light mode. That being said, I think we can get closer without sacrificing readability. Thank you for your involvement in helping us get there.

Thanks @Jack_who_built_the_house for bringing this to our attention. I think the point you are making is very valid. We are in the process of refining some of our dark mode values as we learn of instances like this, so thank you for adding this to our radar. I would suggest we make a change to some of the dark mode tokens to add a bit more contrast in the examples of color-subtle and color-placeholder. This would be a change on the system side, so something we should track for improvements to dark mode tokens.

1. I'm thinking both, as top only feels slightly odd to be a default, since traditionally we find pagination at the bottom of these elements, but bottom by default might lead to it going missed on very long tables. So both feels like a good option as it asks the implementor to opt out of top or bottom, but curious how others feel about this.
2. I believe pagination should be the closest element to the table which it is paginating. So with everything included, I would suggest the order should be:

To @bmartinezcalvo 's second point, I imagine we might just omit this on smaller screens, as it is not necessarily interaction but potentially helpful information. Alternatively we could stack these elements, but that might make for a longer screen or content.

The team who builds Codex is currently working on an expansion to our color palette, which would include values for a wide spectrum of colors ranging from very light to very dark. These will be added into our system as option tokens and used within Codex as application or decision tokens to be used across system elements. We are not planning to open up the option tokens, just like we don't currently.

My take on the two open questions:

Thanks for chiming in. I've updated this patch with this revised approach, to use Codex tokens but match [as closely as possible] the existing colors for both backgrounds/borders and text individually. I will work on getting someone on DST to review this patch and get it merged in in preparation for the next Codex release.

@egardner This is what @JFernandez-WMF and I were thinking as well, to add in this exact application token. I would say that gray.800 for light mode and gray.100 for dark mode are the appropriate values. Julieta, does this sound right to you?

Okay, great. Yes, the idea is that these values would live in Codex and be a part of the token library.

@JScherer-WMF It seems that a few people have responded elsewhere to the same question already so I will defer to their responses.

Update, summarizing design feedback and potential next steps:

Answering these questions at this point after conversations on DST:

The type scale defined in T363850 has been tested in Figma, exploring how components can proportionally adapt to different body font sizes. This testing provided examples for body font sizes of 14, 16, 18, and 20 and a sample can be seen below.

Similarly to what was found in an audit previously conducted as a part of T344515, we found a variety of slightly different type styles across Codex, Vector, and MinervaNeue. Below is a current audit including the most up to date font modes across the listed skins.

An update from the design side: Justin and I met today and discussed our next steps, which are to gather design feedback on potential paths forward. We will be gathering internal feedback first on decisions around the similarities and differences between diffs and bytes, how that influences highlight and text colors between the two, and what values of colors we should be using. Will circle back.

I would encourage us to consider adding the option for an icon on the right of other interactive action components, like Button and Link, as a part of this task.

I would vote for option 2, as content overflow feels less like a design principle and more like a guideline.

This proposal seems fine to me. Thanks for working on this.

@Jdlrobson It looks like this patch which fixes the issue with red link color tokens is set to be included in the next Codex release, scheduled to happen tomorrow.

Thanks for bringing this to our attention. To appease the automated tests, I've updated this color ever so slightly to meet necessary contrast ratios in the patch listed directly above. The change is unnoticeable but fixes the issue.

I agree with the simpler, easy to read, latter approach in Volker's comment.

@Jdlrobson Glad you spoke with Eric about this. These cases are exactly why we created the @color-inverted-fixed token.

This patch which fixes this issue has been merged and will be a part of the next Codex release.

I am working on fixing this as a part of T363911: Fix red link tokens for dark mode.