There are two ways in which Parsoid trips on templates that cause a wikitext construct to be split across top-level-content and templates.
- In one form, the first part of the construct swallows the other part of the construct into its attributes. But in addition, it also swallows following tokens/content as well. The fix is to separate the two and move that other content out back to the top level. (T48811 is an example of this)
- In another form, the construct is split between two adjacent tokens. The fix is to bring content together across tokens / DOM nodes (T69857, T69850, T52603, T46498)
Both these forms affect tables. The first form is seen when a template is used in the table-attribute (and possibly table-row-attribute) position. The second form is seen when a template is used in table-cell-attribute position. The reason why we these two different manifestations of the same problem is because of the peculiarities of how the table-opening-tag and table-cell-tags are tokenized and what the tokenizer can assume about transclusions.
The second form is addressed by the code in dom.t.TableFixups.js where the DOM is examined to bring together the split pieces. However, so far, it only supports templates that generates attributes of a table-cell and a single following table cell. But, we now need to generalize this support to support multiple table-cells being generated by these templates to cover the last of the big unsupported scenarios.
Example wikitext for it is:
{|
|{{convert| 400|m|ft|disp=table|sortable=on}}
|}This affects enwiki:List_of_largest_container_ships (among possibly other pages). Generalizing the code in dom.t.TableFixups.js should probably take care of this.
The longer term fix for both these issues is to start scoping the output of templates to return DOM-representable strings and split some of these monolithic templates into multiple templates, one that generate just the attribute, and another that return just additional content. This also improves WYSIWYG editability of some of these tables.