Last modified: 2014-06-12 05:32:49 UTC
The extension I wrote creates a table and inserts a <script> ... </script> section. However, it does not work as the call of the doBlockLevel-function destroys the structure, see <p><script type="text/javascript"> </p><p> ... </p><p> </script> </p><p> Therefore, I placed the doBlockLevel-function directly after the internalParse-function. Having this done, the extension works. However, does this lead to any side effects?
Our experience is that changing the order or parser steps always breaks something. I'd recommend to escape the javascript by replacing it by a "cookie" that is replaced by the real java script at the end of the processing. See Parser::strip() for how we do this.
Parser::strip() is precisely the function that is used in the given example. It is broken, because unstrip() is done before doBlockLevels().
The reason Gabriel put doBlockLevels() last, after unstrip(), is because he wanted the output to be valid XHTML. That means not having block-level elements inside other block-level elements. doBlockLevels() will automatically detect nested block-level elements, and will break up the outer one to produce valid HTML. The solution I suggested, in private discussion years ago, is to have doBlockLevels() scan the stripped HTML for block-level elements, and if they are present, to treat the strip marker as a block-level element. Then the resulting string can be unstripped to produce valid XHTML.
*** Bug 1772 has been marked as a duplicate of this bug. ***
*** Bug 8997 has been marked as a duplicate of this bug. ***
*** Bug 27906 has been marked as a duplicate of this bug. ***
The workaround for this problem is to replace newlines in the text that your extension is feeding to the parser with a space. This is what extensions currently do. This behavior is very unlikely to change since some extensions might rely on it.
