Tooltip Support [Sponsored, Feb 1 Target]

[chriddyp]

Some requirements:

• Ability to display tooltips when hovering over cells.
• Tooltip data will be provided as an additional property in the table
• Each tooltip string will be matched with a cell via a row ID and a column ID so that the tooltips remain associated with the cells when filtering and sorting.
• Tooltip strings will be rendered as plain text or as Markdown. For security reasons, raw HTML will not be supported. For architectural reasons, users will not be able to pass arbitrary Dash components as tooltips. Markdown strings will enable bolded text, italics, line breaks, headers, and tables.
• Tooltips will be styleable via external CSS.
• The position of the tooltip will be automatically determined so that it:
  • Doesn’t block the cell
  • Isn’t hidden
• Users will not necessarily be able to mouse over the tooltip itself to select text or click on links. Doing so would prevent the tooltip from disappearing, a potentially confusing experience.

[Marc-Andre-Rivet]

Documenting the state of the art md2html in Javascript. There are 5 major libraries

• showdown

• commonmark

• marked

• remarkable

• markdown-it

• showdown and commonmark do not support tables correctly and are out.

• marked has bad base styling with faster rendering as a compensation -- with only tooltips in mind it would be out -- for wider md support (in cells) it should still be evaluated

• none of the 3 remaining projects are very active (latest commit mid-2018) so no positive outlier there

Will evaluate performance syntax support more in depth in a later entry for the 3 remaining candidates.

[chriddyp]

dcc.Markdown uses commonmark. Didn't realize tables weren't supported 🙈 . Looks like the commonmark spec hasn't settled on a table syntax yet (https://talk.commonmark.org/t/tables-in-pure-markdown/81/138).

github has their own commonmark extension (https://github.com/github/cmark-gfm). Maybe at some point dash is able to settle on the github-flavored-markdown instead. Would be nice to use the same flavor across dcc.Markdown and these toolitps.

[chriddyp]

dcc.Markdown uses commonmark

er, nevermind we're using react-markdown: https://github.com/plotly/dash-core-components/blob/52b804d100c724ba4b506a84ff635d32daeb37a8/src/components/Markdown.react.js#L4

which uses remark-parse? https://github.com/rexxars/react-markdown/blob/c86ebd4d1d706e09fc7d4fc398dc6a0b136cdc6f/package.json#L44

which seems to support tables: https://rexxars.github.io/react-markdown/

[Marc-Andre-Rivet]

Library	Syntax Support	Size	Performance	Repo Activity
Showdown	no table	.	.	.	.
Commonmark	no table	.	.	.	.
Marked	Yes	23kB min	3rd of 3	Release >= 2019
Remarkable	Yes	93kB min	1st of 3	Last release Oct. 2016, last merge to master Jul. 2018
Markdown-it	Yes+emojis	106kB min	2nd of 3	Last release Jul. 2018, last merge to master Aug. 2018

Remarkable and Markdown-it both have the highest perf for small and big markdowns with a significant advantage for Remarkable 30-40% faster. Marked lags behind significantly (over +100% execution time)

There is no pristine library to choose from as pretty much all Markdown repos are inactive or close to inactive. Might be because md2html is JS is a solved problem. One of the main contributors behind all these projects is the same guy...

There is a low switching cost between Remarkable and Mardown-it. Would isolate usage and start off with Remarkable if only because the table's performance need to be helped as much as possible. The emoji rendering is not crucial and inactive does not mean an unsound repo featurewise.

[bpostlethwaite]

fwiw I've always used 'marked' and respect the maintainer. He does good stuff.

[Marc-Andre-Rivet]

@bpostlethwaite To your point, here is what I like about marked

• we almost share names!
• it is the most active of the 3 projects that have full table support, by a fair margin
• it has the smallest footprint, by a fair margin

This one I looked for this morning after reading your comment:

• it is the most popular by a fair margin, by a fair margin

The project is definitely in a healthier state than remarkable and markdown-it.

My concern is mainly that the table's performance is a hard affair to keep inline as-is. When thinking only of tooltips, the performance is not an issue but thinking of a markdown cell, the library's performance will have a significant impact on the table's behaviour -- scrolling through a virtualized table with a thousand markdown cells visible (for the first time) could have anywhere between ~1% and ~300% overhead depending on the markdown size and the library's performance. For non-virtualized tables with 5k cells, we could be talking seconds of rendering time.

I'll do two more things before moving forward:

• Give a more structured performance test to the 3 libraries
• Investigate the switching cost in more details

[Marc-Andre-Rivet]

Each tooltip string will be matched with a cell via a row ID and a column ID so that the tooltips remain associated with the cells when filtering and sorting.

Since row ID does not exist yet, making the assumption that this means row index for now. Keeping in line with other props.

For now, taking a similar approach to what's been done previously in the table

• tooltips is an object with an entry per columnId, each entry contains an array of row_index ordered values to display in the UI
• column_conditional_tooltips allows conditions if based on a filter string, row_index and column_id
• column_static_tooltip allows a default tooltip definition per column

The tooltip itself can either be a plain string (defaults to text rendering) or an object with type (text | markdown) and value string.