https://bugzilla.wikimedia.org/show_bug.cgi?id=50603
--- Comment #2 from Gabriel Wicke <gwi...@wikimedia.org> --- Some background from https://gerrit.wikimedia.org/r/#/c/76861/: We are mainly dealing with two cases here (from bug 50603): 1) |{{echo|{{!}} Foo}} This produces two tds, which can be merged on the DOM just as in the list item case. 2) |{{nom|Bar}} with {{nom|Bar}} expanding to something like 'style="foo"|Bar' In this case attributes and (at least some) cell content are template-generated. In the templates I have seen the attributes don't contain wikitext links or other problematic syntax that would cause them to parse to non-text content. This means that we can directly convert the prefix of a text node into attributes. The (planned) addition of nested DSR on template content will also give us access to the original wikitext of other template content, which makes this sound even in theoretical edge cases. In general I am trying to keep parsing context for template expansions as minimal as possible. Basically context-free expansions enable parallel expansion and efficient reuse. In this special case we are bending over backwards to accommodate a specific case of poorly nested template use. In the longer term the goal is to move away from this however, so we should keep the impact of such hacks on our code base as minimal as possible. The implementation should be self-contained enough so that we can disable them once less ideal nestings like these are fixed up in our content, potentially using the information we have in Parsoid itself. Your assumption that our current parser framework is synchronous is not actually true. Template / extension expansions and link handling are highly asynchronous. Ironically it is exactly this asynchrony and independent expansion that makes handling this case hard. With a synchronous text-based preprocessor pass as in the PHP parser re-tokenization would take care of these cases. The price of this (no parallelism or template reuse, additional complexity of template encapsulation etc) would be high though. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
