[got to this one a little late... for those who've forgotten, empty
lines in the javascript output of LJ's parser hook extension were being
enclosed in <p></p> by the parser]
On Mon, 06 Feb 2006 18:40:13 +0100, Tels wrote:
Moin,
On Monday 06 February 2006 06:17, LJ wrote:
Cynicism aside Rob, I appreciate the reply.
Did a bit more digging, and found this 'bug' in bugzilla:
http://bugzilla.wikimedia.org/show_bug.cgi?id=1772
Seems like it's been around awhile. I updated the version, added a
note, and voted for it.
For the time being I can work around it by limiting the text I insert
between my tags (no newlines). However, I'd like to publish my
extension, and I'm unlikely to do so if I have to have the caveat of:
'you have to format the tagged content just-so...'.
Don't know if my previous global flag or callable method ideas have
much merit ( or are feasible to integrate into the parser structure ).
But, it'd be nice if a developer latched on to them... :)
Btw, the Graph::Easy extension (returing HTML) also runs into this. Even
when you add no emoty lines and leading spaces, mediawiki seems to insert
a paragraph every N lines or so. This of course creates wierd empty
spaces in the generated table :(
In the end I stripped *ever* \n from the output and now return a gigantous
long line.
A way to switch this off from my extension would be great, because the
emitted HTML becomes impossible to debug or inspect.
I've had a similar problem with cells for a summary table being too
bloated when the content is enclosed in <p></p> tags.
My solution was the "'long way' around" as LJ put it - preemptively add
identifiable paragraph tags within the tag rendering hook, within an
identifiable block, and then remove them in a ParserBeforeTidy hook.
Doing this properly also required escaping any preexisting such block
markers in a ParserBeforeStrip hook - all in all an inefficient schlep and
I agree that a method of indicating to the parser that it should avoid
paragraph tag insertion for any given hook would be useful.
Ultimately it works though, without needing to return all content on a
single line or otherwise give up formatting, and the approach could be
adapted for newlines - the tag rendering function would enclose itself in
the block markers and convert empty lines to the pair of identifiable
paragraph tags.
For reference, the tags I'm using are <p class="remove"> and </p
>, and
the block markers are __STARTREMOVEPARA__ and __ENDREMOVEPARA__.
Also, LJ, you
originally wrote:
a section or two above, it's stated that when you
forcibly render text
with the parser, you can turn off the <p> tags with a simple 'false'
Iirc, this only applies to the first line of text provided to the parse
function - later lines will be enclosed in <p></p> tags as usual.
--
http://members.dodo.com.au/~netocrat