Can I ask why you would want to hide the title? I can understand hiding the legend, especially when there is only one data series for example (already captured in T391173).

We had a discussion about using some Data:*.chart as a template—using it with very different data (many *.tab) on many pages. One of the concerns was that someone might add a title and break many pages. Not sure if this is a justified fear; I guess we just don't know how it will work from the human side of things.

Also related: there doesn’t seem to be a good place to document decisions in charts. In tabular data, we can at least add a description, but not in charts. In templates, important notes can be added with HTML comments, but not in chart JSON... So maybe JSON5 or JSON-with-comments could be supported? That might be another way to resolve this problem (by just adding a comment // please don't add a title, this chart is used with multiple tabs).

Since the contents of the Chart are using echarts library I wouldn't recommend or endorse using CSS to hide anything here. I think if you need to disable anything it would be better to request it explicitly and for us to configure a boolean on the chart definition to do this.

I guess these should be props at the chart invocation? something like

{{#chart:Global wind power production.chart|title=hide|legend=hide}}

where the default is show.

In T395281#10864975, @CCiufo-WMF wrote:

I guess these should be props at the chart invocation? something like

{{#chart:Global wind power production.chart|title=hide|legend=hide}}

where the default is show.

I'd recommend in the chart definition itself as it's easier for us to migrate these in future if and when breaking changes occur than it is for wikitext.

{{#chart:Global wind power production.chart|title=hide|legend=hide}}

Sounds good to me.

I'd recommend in the chart definition itself as it's easier for us to migrate these in future if and when breaking changes occur than it is for wikitext.

But the point is to have control in the context of local wiki or even in a specific template. Control over which aspects of the chart should be used. That means exposing some levers to control the behavior. The levers can be classes or options in the call.

BTW, I think classes might still be needed for theming. You might want to look at how pie charts look on Enwiki and the talk page of the template. For example, I tried to convince people to use the default colors, and so far I wasn't very successful. Good luck on that front :)

In T395281#10865813, @Nux wrote:

I'd recommend in the chart definition itself as it's easier for us to migrate these in future if and when breaking changes occur than it is for wikitext.

But the point is to have control in the context of local wiki or even in a specific template. Control over which aspects of the chart should be used. That means exposing some levers to control the behavior. The levers can be classes or options in the call.

Yeah I agree, this is a configuration for how the chart is represented within that specific use in a specific article, rather than a configuration of the chart overall. Similar to to providing sizing options. To be transparent, we likely won't get to this in the scope of the project, but it does makes sense.

BTW, I think classes might still be needed for theming. You might want to look at how pie charts look on Enwiki and the talk page of the template. For example, I tried to convince people to use the default colors, and so far I wasn't very successful. Good luck on that front :)

:(

BTW, I think classes might still be needed for theming. You might want to look at how pie charts look on Enwiki and the talk page of the template. For example, I tried to convince people to use the default colors, and so far I wasn't very successful. Good luck on that front :)

FWIW I'd be worried about providing classes exactly for this reason. There may be good reasons in future to switch from SVG rendering to HTML Canvas rendering (particularly as part of addressing T395490: Support rendering previews of charts as thumbnail images) so IMO we shouldn't be actively encouraging styling via CSS via classes as that would likely lock us into SVGs forever.

Related: https://www.mediawiki.org/wiki/Extension:Chart#Note_of_caution

Two suggestions:

1. The label "Chart definition" (e.g. used for .chart link in [[:en:Template:Chart]], or "Definition" (in the corresponding German template), is misleading for regular readers, who aren’t interested in the JSON code. I suggest "Full view", "Full-resolution view" or "Details" to highlight the main user-facing function. Just like clicking a .PNG thumbnail opens a larger image, this link should be understood as a way to explore the chart more fully. It is of interest especially when the width is limited by a container. While it also exposes image info (usage metadata) and the editable .chart code, that’s not what most users care about and shouldn’t be highlighted. In the future, this view could link to the underlying .tab data and support features like zoom and interactive curve selection, which is not at all about "definition".

2. I use the term "Data source" specifically to refer to the original external dataset—especially in the caption of a self-produced .png plot to make it clear that the image is based on the dataset, not a copyrighted graphic. For the link to the Commons .tab page, the label "Source data" or "See or edit source data" can be improved in my opinion. A more accurate label would be something like "Data", "Raw data", "Table", or "Tabular data". The latter is more focused on the user, as many readers are interested in viewing the table rather than editing it. The .tab page itself typically includes a citation of the original dataset or data source under a section titled "Sources", and usage metadata.