https://bugzilla.wikimedia.org/show_bug.cgi?id=41057
--- Comment #4 from [email protected] 2012-10-16 15:49:09 UTC --- I think because of the lost <td> tag, the DOM is thrown off sufficiently so that DSR calculations might not be able to capture all RT-able content. Consider this example: {| |{{BBC Radio}} |row2 |} Now, let us look at the token stream that is sent to the tree builder: <table>, <td>, <bbc-meta-start>, ...., <bbc-meta-end>, </td>, <td>, row2, </td>, </table> But, if you look at the DOM that comes out the tree-builder, it looks like: .... </table>, row2. So, a closing </td> tag that should have matched with the lost td-tag is instead closing the outer table. In the bargain, source wikitext information about the leading "|" before row2 and the table closing "|}" is lost because the tree builder discards the mismatched <td>, </td> and </table> tokens in the end. This rts as: {| |{{BBC Radio}} row2 Now, let us take an example closer to the wikitext found on the BBC page: {| |{{BBC Radio}} |{{echo|row3}} |} The trailing DOM for this looks like this: ... </table> <span data-parsoid="{'src':'|{{echo|row2}}','dsr':[18,32]}" about="#mwt2" typeof="mw:Object/Template">row2</span> And, this roundtrips as: {| |{{BBC Radio}} |{{echo|row2}} I'll examine this more, but when the DOM semantics change, I am not sure if DSR can always robustly fix this up in all situations given that DSR computation relies on DOM structure. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- 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
