Input {{#chart:Missing}} in wikitext. In VE this no longer generates a ve.dm.ChartNode, just a regular Template parser function which can't be fixed in the editor:
This should be resolved by using more reliable syntax as described in T393306.
| Esanders | |
| May 4 2025, 9:00 AM |
| F59662680: image.png | |
| May 4 2025, 9:00 AM |
Input {{#chart:Missing}} in wikitext. In VE this no longer generates a ve.dm.ChartNode, just a regular Template parser function which can't be fixed in the editor:
This should be resolved by using more reliable syntax as described in T393306.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| VisualEditor: Treat charts as block, not inline | mediawiki/extensions/Chart | master | +4 -6 |
Change #1163450 had a related patch set uploaded (by Catrope; author: Catrope):
[mediawiki/extensions/Chart@master] VisualEditor: Treat charts as block, not inline
This wasn't actually related to T393306. Error charts have the same RDFa type and data-mw information as regular charts. The issue was that the chart node type inherited from MWTransclusionInlineNode, but error charts are <div>s, and inline nodes can't match block elements. But this was wrong anyway, because <mw-chart> elements are styled as display: block, so we should have been using MWTransclusionBlockNode all along. Fixing this also fixed this bug.
I did try to change the error output to something like <wiki-chart data-mw-chart='{"error":true}'><div class="cdx-message--error" ....</div></wiki-chart> to make regular charts and error charts use the same tag name, but unfortunately Parsoid breaks that because it believes <wiki-chart> is an inline tag and can't contain block tags (which is inaccurate, custom elements are allowed to contain block elements).
It would be nicer for VE if we could always use the <wiki-chart> element, but unfortunately that won't be possible unless and until this Parsoid behavior is changed.
<p><wiki-chart><div>......</div></wiki-chart></p> is parsed by every browser as <p><wiki-chart></wiki-chart></p><div>......</div><p></p> so that's not a parsoid bug per se. It's one of the dangers of using custom elements, which are always parsed as inline AFAIK.
which are always parsed as inline AFAIK
If that is true that seems like a good reason to avoid them. The is attribute proposed on the other task seems like it would cause fewer parser issues.
Change #1163450 merged by jenkins-bot:
[mediawiki/extensions/Chart@master] VisualEditor: Treat charts as block, not inline