Web Charts

[AdamSobieski]

WebKittens

No response

Title of the spec

Web Charts

URL to the spec

https://github.com/WICG/proposals/issues/97

URL to the spec's repository

No response

Issue Tracker URL

No response

Explainer URL

https://github.com/WICG/proposals/issues/97

TAG Design Review URL

No response

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/829

WebKit Bugzilla URL

No response

Radar URL

No response

Description

The Web Charts proposal intends to add a new HTML media element, <chart>, alongside the <audio> and <video> elements.

Charts can provide interactive visualizations for static data as well as for time-based, dynamic, streaming data. Scenarios for this latter case, consuming "data video", include displaying streaming data from: sensors, business intelligence and analytics, and stock markets.

Accordingly, the proposed <chart> element would be conceptually derived from the <video> element, utilizing most or all of its attributes, and extending its content model. In this approach, any eventual HTMLChartElement interface would extend HTMLMediaElement.

For scenarios involving the visualization of static data, here are some markup examples:

<chart src="data.csv" width="600" height="400">
  <script type="text/javascript" src="https://cdn.webcache.org/bar-chart.js" />
</chart>

<chart width="600" height="400">
  <source type="text/csv" src="data.csv" />
  <source type="text/tsv" src="data.tsv" />
  <script type="text/javascript" src="https://cdn.webcache.org/bar-chart.js" />
</chart>

In these above examples, the provided scripting logic processes the selected input data into interactive content, e.g., HTML, SVG, Canvas, WebGL, or WebGPU content, in the shadow DOM.

Next, we can add configuration settings for the provided scripting logic to consume utilizing the data block capabilities of <script> elements when they are provided content of a type other than text/javascript.

<chart src="data.csv" width="600" height="400">
  <script type="text/javascript" src="https://cdn.webcache.org/bar-chart.js" />
  <script type="text/json" src="settings.json" />
</chart>

<chart width="600" height="400">
  <source type="text/csv" src="data.csv" />
  <source type="text/tsv" src="data.tsv" />
  <script type="text/javascript" src="https://cdn.webcache.org/bar-chart.js" />
  <script type="text/json" src="settings.json" />
</chart>

Next, for time-based, dynamic, streaming data scenarios, here are some markup examples. In the following examples, the MIME types of video/mp4 and video/webm are utilized as placeholders.

<chart src="data-video.m3u8" poster="loading.png" autoplay="true" controls="true" width="600" height="400">
  <script type="text/javascript" src="https://cdn.webcache.org/bar-chart.js" />
  <script type="text/json" src="settings.json" />
</chart>

<chart poster="loading.png" autoplay="true" controls="true" width="600" height="400">
  <source type="video/mp4" src="data-video.mp4" />
  <source type="video/webm" src="data-video.webm" />
  <script type="text/javascript" src="https://cdn.webcache.org/bar-chart.js" />
  <script type="text/json" src="settings.json" />
</chart>

Finally, we can add a <style> element so that charts could provide custom styling instead of only being able to utilize the style of their containing documents.

<chart src="data-video.m3u8" poster="loading.png" autoplay="true" controls="true" width="600" height="400">
  <script type="text/javascript" src="https://cdn.webcache.org/bar-chart.js" />
  <script type="text/json" src="settings.json" />
  <style  src="custom.css" />
</chart>

<chart poster="loading.png" autoplay="true" controls="true" width="600" height="400">
  <source type="video/mp4" src="data-video.mp4" />
  <source type="video/webm" src="data-video.webm" />
  <script type="text/javascript" src="https://cdn.webcache.org/bar-chart.js" />
  <script type="text/json" src="settings.json" />
  <style  src="custom.css" />
</chart>

[marcoscaceres]

I guess the main question I have is: how does it semantically differ from <figure> or <picture> or even <video>... or <img>, really?

Media-capable HTML elements are generally used as rendering containers/viewports, however, this seems to rely on JS to render the chart which defeats the purpose of having the element.

Consider, to meet the bar for a new HTML element, this should just work:

<!-- this should render something meaningful without JS -->
<chart src="chart.format"></chart>

Similarly, with the <video> example, it seems to replicate existing capabilities that are already part of <video> but without significant usability, accessibility, or internationalization advantages for end users.

[AdamSobieski]

@marcoscaceres,

One reason for a developer-specified scripting logic approach is that there are so many different types of charts. According to Wikipedia, there are, to consider, the common chart types: histograms, bar charts, pie charts, and line charts. There are also: timeline charts, organizational charts, tree charts, flow charts, area charts, cartograms, pedigree charts, and radial tree charts. There are also the less-common chart types: bubble charts, polar area diagrams, waterfall charts, radar charts, tree maps, streamgraphs, and gapcharts. Beyond all of these types of charts, data visualization designers can also get creative.

The capabilities to be able to provide settings or configuration and to be able to provide custom styling would enhance scripts' reusability and, thus, their cacheability. Would Web developers reutilize scripts from third-party providers, browsers could efficiently cache these resources.

Also, it could become a design goal that Web developers be able to easily change scripts, e.g., without significantly modifying their input data, their configurations/settings, or their styling. Swapping scripts could be done: to change the types of charts, to change between versions of the same vendor's script, or to change between vendors' scripts.

With respect to useability, accessibility, and internationalization, as envisioned, these would be features provided by the scripts which produce styleable visualizations in the shadow DOM for input data.

As for how a <chart> element would differ from existing elements like <img>, <picture>, or <video>, charts' scripts would create and modify visualizations for both static or streaming data utilizing HTML, SVG, Canvas, WebGL, or WebGPU in the shadow DOM. In these regards, charts would be interactive, resizable, and reflowable. Charts would be capable of providing mouseover effects, supporting the selecting of content, providing animations, providing context menus, supporting clipboarding scenarios, supporting drag-and-drop scenarios, and much more.

While it could be useful to have something like:

<chart src="chart.format" />

such a format, maybe a "ChartML", would, I think, encompass the same main points considered in the proposal:

1. Included or referenced input data files or streams in one or more data formats.
2. Scripting logic for visualizing the static or streaming data in HTML, SVG, Canvas, WebGL, or WebGPU in the shadow DOM.
3. Settings or configuration for the scripting logic.
4. Styling.

While instead of providing a script, per point 2, a "ChartML" resource could specify a well-known type of data visualization, the type of the chart, e.g., by URI, I, for one, consider there to be significant room for variation with respect to types' implementations and the set of types of data visualizations to be open-ended.

[rniwa]

This seems like a sort of a thing a custom element can be useful. I don't see a value in standardizing element that then requires scripts to do everything.

[AdamSobieski]

@rniwa, yes, something like a <web-chart> custom element could be useful. Such a custom element could provide a framework with which compatible referenced scripts would interoperate. Also, the "data video" concepts for time-based, streaming data visualization scenarios could be implemented, or at least prototyped, utilizing WebVTT-based text tracks in existing video formats. These text tracks could, for example, contain update operations for memory-resident IndexedDB tables. Reactive solutions for IndexedDB databases exist.

To the second point, also possible are uses of a new attribute, e.g., kind, on <chart> elements utilizing a controlled vocabulary:

<chart kind="bar" src="data.csv" width="600" height="400" />

<chart kind="bar" width="600" height="400">
  <source type="text/csv" src="data.csv" />
  <source type="text/tsv" src="data.tsv" />
</chart>

[marcoscaceres]

The proposal is interesting and we acknowledge that graphs are an extremely useful means to visualize numerical information on the web. However, the proposal doesn't seem to add enough functionality to warrant the standardization a new HTML element.

Given the above points, I'm going to say WebKit is "opposed" to this proposal as is, as:

• it relies on script to do the heavy lifting (or to work at all!), so it's probably better suited to be a custom element.
• it simply wraps and depends on existing HTML elements (ing, svg, canvas, etc.), which do the actual rendering and handle functionality.
• Seems add limited user benefit in terms of usability, accessibility, and internationalization.
• doesn't provide developers with significant ergonomic improvements over what they already have to work with (i.e., they would still need to manipulate a 2D/3D context or SVG file to draw/animate the graph etc.)
• there is no standard format for charts (which is probably a good thing, as JSON, CSV, XML etc. can all be relatively easily fetched and used as data sources)

Further input welcome from other folks, particularly if there is disagreement with my assessment above. If not, we will move to make "opposed" WebKit's official position on this proposal.