There's been some recent discussion in the mediawiki IRC channel about the Parser's handling of whitespace in tag extension output. Specifically, if the output of a tag contains leading whitespace or consecutive newlines, they are replaced with <pre> blocks and </p><p> combos respectively.
I'm planning to fix this, and I was curious which version(s) would receive the fix when finished. Does this qualify as something which would be backported, or only in the latest release? Thanks in advance.
-- Jim R. Wilson (jimbojw)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin,
On Friday 16 February 2007 13:38:47 Jim Wilson wrote:
There's been some recent discussion in the mediawiki IRC channel about the Parser's handling of whitespace in tag extension output. Specifically, if the output of a tag contains leading whitespace or consecutive newlines, they are replaced with <pre> blocks and </p><p> combos respectively.
I'm planning to fix this, and I was curious which version(s) would receive the fix when finished. Does this qualify as something which would be backported, or only in the latest release? Thanks in advance.
If you fix this, I owe you a beer.
Tels
- -- Signed on Fri Feb 16 13:58:18 2007 with key 0x93B84C15. View my photo gallery: http://bloodgate.com/photos PGP key on http://bloodgate.com/tels.asc or per email.
"People who are rather more than six feet tall and nearly as broad across the shoulders often have uneventful journeys. People jump out at them from behind rocks then say things like, 'Oh. Sorry. I thought you were someone else.'" -- Terry Pratchett
btw - there's now a bug to track this issue:
http://bugzilla.wikimedia.org/show_bug.cgi?id=8997
(Oh, and I don't drink alcohol - but I'd love an espresso anytime :)
-- Jim
On 2/16/07, Tels nospam-abuse@bloodgate.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin,
On Friday 16 February 2007 13:38:47 Jim Wilson wrote:
There's been some recent discussion in the mediawiki IRC channel about the Parser's handling of whitespace in tag extension output. Specifically, if the output of a tag contains leading whitespace or consecutive newlines, they are replaced with <pre> blocks and </p><p> combos respectively.
I'm planning to fix this, and I was curious which version(s) would receive the fix when finished. Does this qualify as something which would be backported, or only in the latest release? Thanks in advance.
If you fix this, I owe you a beer.
Tels
Signed on Fri Feb 16 13:58:18 2007 with key 0x93B84C15. View my photo gallery: http://bloodgate.com/photos PGP key on http://bloodgate.com/tels.asc or per email.
"People who are rather more than six feet tall and nearly as broad across the shoulders often have uneventful journeys. People jump out at them from behind rocks then say things like, 'Oh. Sorry. I thought you were someone else.'" -- Terry Pratchett
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux)
iQEVAwUBRdWqd3cLPEOTuEwVAQJr5Qf+LA+h9zEw0Wy/owWyQkE5i3CayYIfaAQn AKIwt3ezxCrQI6ADqYURcgRILKn8WVtlOeSbAcX8hPyI0ua7WshiEOli03bMYyTi iNBRNXGkFnYgwEsb3l1QoitfUDEsXrq9K0vGxgB67xPG80U1nU3RQrjg7Ug/VbVq T28bJgZxKCF4fJkccIiFItTy8OnLJlWAk2OE78NFknHOBYew3KMnlK308czsCZcB v1KpIdJfrPH44RyACpWmJn88t8hHbBD8WyIWsHlMw2ZAS3GPwRIyhV8oK+zMY7et DCwKt2EXHew9R8K69u2kLRq2tEmmfUl8euczQNSoGB/snuOfmHjgZQ== =2GmR -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 16/02/07, Jim Wilson wilson.jim.r@gmail.com wrote:
I'm planning to fix this, and I was curious which version(s) would receive the fix when finished. Does this qualify as something which would be backported, or only in the latest release? Thanks in advance.
If I were release manager, I wouldn't backport it, but that's just me - it changes the Parser behaviour and could introduce unforeseen problems, so I wouldn't incorporate it into a stable branch.
Rob Church
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Wilson wrote:
There's been some recent discussion in the mediawiki IRC channel about the Parser's handling of whitespace in tag extension output. Specifically, if the output of a tag contains leading whitespace or consecutive newlines, they are replaced with <pre> blocks and </p><p> combos respectively.
The general problem IIRC is that until the extension block's contents are replaced it's not necessarily clear whether it should be treated as a block element or an inline element.
Eg, you may need to wrap a <math> in <p>s but you shouldn't so wrap something that outputs itself as a <p> or a <pre> or whatever, or you end up with odd spacing and inconsistent markup.
I'm planning to fix this, and I was curious which version(s) would receive the fix when finished. Does this qualify as something which would be backported, or only in the latest release? Thanks in advance.
Backporting questions can usually be answered pretty easily:
a) Is it a security fix? no
b) Is it vital for the software to run? no
So, probably no. :)
In particular note that a change to parser behavior is the kind of thing we really *don't* want to introduce in a preexisting stable branch.
As an example of 'vital' fixes; a bug that causes MediaWiki to fail on a certain version of MySQL or a certain major web server might have a decent chance of being backported to the latest release branch if it's not a large change.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
Thanks Brion,
Eg, you may need to wrap a <math> in <p>s but you shouldn't so wrap something that outputs itself as a <p> or a <pre> or whatever, or you end up with odd spacing and inconsistent markup.
Do you happen to know where in the Parser (trunk) this decision is made?
On 2/16/07, Brion Vibber brion@pobox.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Wilson wrote:
There's been some recent discussion in the mediawiki IRC channel about
the
Parser's handling of whitespace in tag extension output. Specifically,
if
the output of a tag contains leading whitespace or consecutive newlines, they are replaced with <pre> blocks and </p><p> combos respectively.
The general problem IIRC is that until the extension block's contents are replaced it's not necessarily clear whether it should be treated as a block element or an inline element.
Eg, you may need to wrap a <math> in <p>s but you shouldn't so wrap something that outputs itself as a <p> or a <pre> or whatever, or you end up with odd spacing and inconsistent markup.
I'm planning to fix this, and I was curious which version(s) would
receive
the fix when finished. Does this qualify as something which would be backported, or only in the latest release? Thanks in advance.
Backporting questions can usually be answered pretty easily:
a) Is it a security fix? no
b) Is it vital for the software to run? no
So, probably no. :)
In particular note that a change to parser behavior is the kind of thing we really *don't* want to introduce in a preexisting stable branch.
As an example of 'vital' fixes; a bug that causes MediaWiki to fail on a certain version of MySQL or a certain major web server might have a decent chance of being backported to the latest release branch if it's not a large change.
- -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF1d0pwRnhpk1wk44RAgEGAKCexnXS6nmzKU22eUAaNTuhTCXjFQCg1F/r sGqN/YMkmw4MQaF71plviwY= =A6pj -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Wilson wrote:
Thanks Brion,
Eg, you may need to wrap a <math> in <p>s but you shouldn't so wrap something that outputs itself as a <p> or a <pre> or whatever, or you end up with odd spacing and inconsistent markup.
Do you happen to know where in the Parser (trunk) this decision is made?
IIRC you want to start hacking around doBlockLevels().
- -- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org