https://bugzilla.wikimedia.org/show_bug.cgi?id=50589
--- Comment #9 from Gabriel Wicke <[email protected]> --- > You really need to be parsing *after* template expansion and tracking all the > text that the templates generate. We are tokenizing templates and content separately so that we can cut template vs. non-template content on a token level. Attribute keys and values can also be templated, but we don't support templates producing several attributes and parts of a token. This and the need to infer resulting DOM structures affected by template-produced tokens already adds a lot of complexity, but at least the results can somewhat sanely be represented in DOM. Having 1/3 of a DOM element's start tag be generated by page source and 2/3 templated on some arbitrary boundary would be a nightmare to represent in DOM and even worse in a UI. You are right though that we *could* in theory represent something like |{{singlechart|..}} as a special case of a multi-part templated construct. This would run counter to our desire to move towards self-contained templates though that are easier to edit both in wikitext and the VE. Removing the pipes in the page and returning the full table row from singlechart would be better in that regard. > Removing the pipe doesn't quite work, though: take a peek at > http://en.wikipedia.org/wiki/2012_%28It_Ain%27t_the_End%29?veaction=edit vs. > http://en.wikipedia.org/wiki/2012_%28It_Ain%27t_the_End%29 and notice how the > manual entries and the templated entries align in the normal view but > scramble > in the edit view. Indeed, it seems that we don't recognize single-line rows that don't start with ||. As a workaround, it should be possible to emit '||' from the template instead. I'll file a bug for our table row tokenization bug. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
