Change Details

T259676 is a production crasher. While https://gerrit.wikimedia.org/r/618565 fixes it, @arlolra raised the question of why the `extsrc` property is missing in the first place. Turns out that the wikitext in question is: ``` <i <ref>a</ref>>... ...</i> ``` The HTML i-tag is separate across a newline which breaks it across paragraph boundaries and then fixed by the tree builder which duplicates the HTML attribute which happens to contain the ref-tag. To be clear, this looks like broken wikitext and so doesn't merit a lot of attention on its own. But in terms of consistent handling of scenarios like these, there are two questions to answer here: 1. What is a sensible way to handle extension tags in HTML attribute positions? Typed templates / typed wikitext offers a clear strategy in the future ( i.e. enforce output constraints based on embedding ocntext), but we need a solution before we get there. 2. How we do handle tree builder fixup and HTML attributes of this nature? I'll include a transcript of IRC conversation in a comment below but that conversation effectively raises he above 2 questions.

T259676 is a production crasher. While https://gerrit.wikimedia.org/r/618565 fixes it, @arlolra raised the question of why the `extsrc` property is missing in the first place. Turns out that the wikitext in question is: ``` <i <ref>a</ref>>... ...</i> ``` The HTML i-tag is separate across a newline which breaks it across paragraph boundaries and then fixed by the tree builder which duplicates the HTML attribute which happens to contain the ref-tag. To be clear, this looks like broken wikitext and so doesn't merit a lot of attention on its own. But in terms of consistent handling of scenarios like these, there are two questions to answer here: 1. What is a sensible way to handle extension tags in HTML attribute positions? Typed templates / typed wikitext offers a clear strategy in the future ( i.e. enforce output constraints based on embedding context), but we need a solution before we get there. 2. How we do handle tree builder fixup and HTML attributes of this nature? I'll include a transcript of IRC conversation in a comment below but that conversation effectively raises the above 2 questions.

T259676 is a production crasher. While https://gerrit.wikimedia.org/r/618565 fixes it, @arlolra raised the question of why the `extsrc` property is missing in the first place. Turns out that the wikitext in question is: ``` <i <ref>a</ref>>... ...</i> ``` The HTML i-tag is separate across a newline which breaks it across paragraph boundaries and then fixed by the tree builder which duplicates the HTML attribute which happens to contain the ref-tag. To be clear, this looks like broken wikitext and so doesn't merit a lot of attention on its own. But in terms of consistent handling of scenarios like these, there are two questions to answer here: 1. What is a sensible way to handle extension tags in HTML attribute positions? Typed templates / typed wikitext offers a clear strategy in the future ( i.e. enforce output constraints based on embedding occontext), but we need a solution before we get there. 2. How we do handle tree builder fixup and HTML attributes of this nature? I'll include a transcript of IRC conversation in a comment below but that conversation effectively raises the above 2 questions.