I think @DTorsani-WMF would be the right person to weigh in on this component going forward though!

@dmaza I can't remember exactly, but looking at the timing of when I moved it to the backlog, I think it was just a matter of not seeing it as a priority as Design-System-Team was winding down. Originally, we intentionally put off creating a pagination component when we were building the table component, so as not to complicate the design of that component.

I agree with @Andrew's assessment in T407296#11274680 that we won't benefit from simply selecting the "simplest" tools or the ones we think will be "easiest" to migrate. That would result in backloading all of the risk and potentially signaling that this whole effort will be easier than it really is. That said, we also want to avoid trying to make a POC so comprehensive that is actually just ends up being the entire end-product. It would be helpful to start by defining what constitutes a tool's "complexity" (i.e. is it compute needs? storage? build & deploy setup?). Maybe there is a dimension of complexity we can intentionally leave out of the POC if we know it won't be trivial but can be cleanly sliced out without affecting a majority of tools.

In T407296#11274680, @Andrew wrote:

"After building a pilot bare-metal toolforge replacement, how hard was it, and does it seem like something that would be easy to maintain, or hard to maintain?"

If that's the question we're going to answer (and I think it is), then next we should define a scope for what we mean by 'pilot toolforge replacement' so we know when to stop building and when to start evaluating. I propose we define that scope by selecting an existing small set of tools to run on the new toolforge, and when they work then we're done.

If others agree with that, then we need to decide if we're targeting simple tools or complicated ones. It's my opinion that we should intentionally choose the most pathologically-complex tools we can find for the pilot, because if we choose trivial ones then we'll wind up deciding that the whole bare-metal migration is easy when all we've actually proved is that doing easy things is easy.

I'm not sure if all the major browsers we support have a native "desktop mode" setting. If they don't and it is functionality we want to continue supporting for all users, is there a way to keep the footer links but have them behave consistently with the native browser behavior so that we don't end up with issues like T407023?

Ok, I think I can now confirm this particular issue is caused by a combination of using the footer links + using the "Desktop site" toggle in my mobile browser. The footer links seem to set a browser-stored flag that locks the skin that is being used to render the page (MinervaNeue for the "Mobile view" link and Vector 2022 for the "Desktop" link), even if my browser is requesting the "desktop site". Once I clear my cookies and site storage, the behavior of the "desktop site" toggle returns to what I expect.

In T405655#11236444, @Miriam wrote:

Thanks @CCiufo-WMF ! This has been prioritized on our end. @CMyrick-WMF will work with you. @CMyrick-WMF please update this task with the steps/timeline once you've clarified with the team.

Can we include a note about this in the next tech news entry?

Possibly related / same issue in T398597: Transformed .chart pages crash when the underlying .tab page contains null values

I think the generic situation where switching the default column is helpful is any time when a column or workboard's purpose changes from its original intention, but you don't want to create a new project tag to represent the change.

@Supergrey1 would you be able to confirm this is working now?

Oops, sorry about that @Formasit-chijoh ! Re-assigned to you. I'll see if someone is available to review.

This actually should be fixed now after recent updates in T395165. Further refinement is coming in T397664.

I'll keep the task open since the sandbox is unknown to most Codex users and we may still want to consider having a demo as described in the task description on the button component page.

We've discussed adding the icon to the configurable demo at the top of the page, but my understanding is that there's some complexity with that given the icon is not actually a button prop. There are however examples of buttons with icons and varying actions/weights in the button sandbox demo.

Not sure if this is a Codex issue. I'm assuming the overflow behavior can be customized with CSS specific to the UserInfoCard.

The general guidelines around the Toast component is to not overly rely on them to communicate critical information or actions. Toast are meant to be supplemental and brief, which is why only one action is recommended at most, and stacked notifications should be rare (even if from the same feature/system). There are of course going to be exceptions to this which is why most Codex components (including the Toast) are designed to be flexible enough to customize for a specific use case. Many of the mw.notification use cases don't follow these guidelines and would need to be revisited before being ported to the Codex Toast. Using the component wouldn't automatically replace whatever logic is built in to mw.notification. All the "don'ts" in the spec should be taken as recommendations and not strict rules.

@DTorsani-WMF maybe something you can take a look at once you have a chance.

Just noting this doesn't seem to be a problem for Typeahead in Vector 2022:

Actually, upon further review, I'm thinking this might really be unintentional. The CSS classes applied to the diff lines are not using the CSS custom property controlling font size, but other elements of the page (even the + and - icons beside the lines) are changing. This is not really a Codex issue though and would probably be better resolved by Web-Team or Editing-team.

Just noting that I believe this is intentional. The "interface" components of the skin don't currently scale with the font size switcher. That may change based on what comes next from T363845#10910994. Boldly untagging as a bug report but please let me know if this in fact did used to behave differently.