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.

@Catrope will take a look at the possible solutions and propose a path forward.

Hi @Alladyn21, can you provide a link to the page in question where the chart is failing to render?

In T396913#10919803, @Catrope wrote:

My 2 cents: I see charts as content, so I think they should be in the language that matches the content around them, not the language the UI is in.