Okay, so what if we did the following:

In T362650#10033805, @KStoller-WMF wrote:

@CCiufo-WMF - Will the engineering improvements associated with this task be complete by DST? If yes, can you provide an estimated timeline for when these Lookup UX improvements will be complete? (I'm trying to determine if Growth needs to make a fix on our side to ensure the Community Configuration form isn't responsible for generating more production errors).

Cross posting my reply from T370074#10035630:

I would recommend not tokenizing this value for now. This seems like a very specific use case that should live as a decision in the skin until we either find more uses for it or it becomes more "stable". I have a feeling the color might change as we get more feedback about how it behaves with different SVGs and I don't think a dependency on Codex there makes sense. Does that work for you all? We can still add color-base-fixed as requested in T371529.

In T370074#10033801, @JScherer-WMF wrote:

In T370074#10033615, @Jdlrobson wrote:

Hey @JScherer-WMF please see T371529#10033077 - DST are concerned that we are using an inappropriate token for the background here.

I'm fine to wait for a new token for this and mark this as blocked on others in the meantime. @CCiufo-WMF and DST can decide what naming convention makes the most semantic sense for dark mode image backgrounds. If we decide we don't want to wait, we can use the hex described in the task description, mark it as tech debt, and update it to the design token when it's available.

In T371529#10033065, @Jdlrobson wrote:

For clarification background-color-disabled is not needed for community. It's needed by web team in T370074. color-base is the only one that I am proposing for community.

The overall effort to expand the palette is now captured in T371516. I've updated this task to just be about developing the new palette, but we still need to do more testing and rework parts of the doc site before we can deploy it.

In T363515#10009578, @bmartinezcalvo wrote:

I've included the error states in Combobox, Lookup, and Radio in this Figma branch. And I've also updated these components guidelines including the error state in this patch. We will merge both the Figma branch and the patch once the implementation part has been completed.

@CCiufo-WMF since we decided to just work on the design part of this task during the sprint, should we move this task outside the sprint now until we decide to work on the implementation?

In T368478#10020961, @Pietrasagh wrote:

Template:Graph:Chart (eg. on English wikipedia) would be better place to look for users preference of charts parameters.

• For users it's very important to be able define their own colors.
• It would be great to have step line graph. It's good replacement for bar chart for large amount of data points. It seems to be very easy to implement in eChart.
• It would be great if charts would use local Wikipedia language. This was especially annoying for date formatting with Vega.

Significant amount of charts created with module Module:Graph and Template:Graph:Chart were bar charts. Parameters for a start would be same as for line.
Mixed line/bar chart would be great to have but we can leave it to later.
Definition of bar chart and mixed charts seems to be much easier in eChart than in Vega.

In T363416#10019433, @lwatson wrote:

Options

Option 1: Disable the custom input initially. (This means we continue with the current design.)

• Select the radio/checkbox to enable the custom input.
• Codex or users handle the disabled state (undecided between engineers).

Option 2: Enable the custom inputs initially.

• Clicking into the enabled custom input will automatically select the radio/checkbox.
• Codex handles the enabled/disabled state automatically for the user.
• Allow the flexibility to enable/disable the custom input initially as seen in Vuetify: inline text field

It sounds like we need to do a bit more investigation on the best path forward here. I'd recommend we start with a timeboxed spike to evaluate the different options.

I believe character counters for Codex components are all achieved through a custom help text slot in the Field component. Wouldn't this also be possible with ChipInput?

The successor to the Graph extension will be Charts, and the scope is outlined in the project page. I'd encourage discussion on the talk page rather than on this task.

In T369499#10016943, @Jdlrobson wrote:

if we want to keep the preference, I think it's relatively easy to support by strengthening the CSS selector to always apply. It probably should have been like that anyway.

The above patch does the following:

• Limits the preference to article content links. Previously this applied to all links including menus (but in most cases wasn't working due to more specific-CSS selectors)
• Changes the behaviour of "never" to never underline links to behave consistently with the description of the preference. Users that want underline on hover should use the default option.
• Ensures that underline will always apply to all links in the content.

I think we should aim to demo one single-series line chart and then at least one with multiple series. There are some examples in this sandbox page (see the COVID-19 cases for single-series and the "Graph of general election results in Don Valley West" for multiple series).

Published here.

In T360154#10015414, @egardner wrote:

One thing that folks should keep in mind if we stick with the approach of: "keep the first visible row at the top of the table when page size changes" – if the user is on the last page of items, and they increase the rows per page, they will not see any change. The table will not reach "backwards" to give them more data; it will keep the first row at the top and show up to X items until the data runs out.

If anyone is worried about the user not seeing any visible change in response to their action in such a scenario, we could consider making the table height always change based on the "items per page" selection, regardless of whether or not enough rows exist to fill the space.

In T165118#10015313, @CCiufo-WMF wrote:

There are no longer any plans to upgrade Vega. The Graph extension will be succeeded by Charts, a new extension being built this year as part of a dedicated WMF initiative. Apache eCharts has been selected as the framework to power these charts, but using Vega has not been ruled out entirely for future use (see T368336#9971574 for more context).

In T165118#10015313, @CCiufo-WMF wrote:

There are no longer any plans to upgrade Vega. The Graph extension will be succeeded by Charts, a new extension being built this year as part of a dedicated WMF initiative. Apache eCharts has been selected as the framework to power these charts, but using Vega has not been ruled out entirely for future use (see T368336#9971574 for more context).

There are no longer any plans to upgrade Vega. The Graph extension will be succeeded by Charts, a new extension being built this year as part of a dedicated WMF initiative. Apache eCharts has been selected as the framework to power these charts, but using Vega has not been ruled out entirely for future use (see T368336#9971574 for more context).