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
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.
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.