Last modified: 2012-05-08 13:54:54 UTC
I'm currently using the brilliant extension mw-slidy http://www.mediawiki.org/wiki/Extension:Mw-slidy to display wiki content using Slidy http://www.w3.org/Talks/Tools/Slidy2/ on a MW is provided by a contractor - version=1.16.0--please let me know if that's too downlevel - also unfortunately behind a firewall for my group @ US EPA. This allows us to automagically display our MediaWiki content (and we use MW extensively) as "real slides" for presentation: IMHO that's a major productivity gain, and should be more widely adopted. mw-slidy basically works as advertised https://github.com/dov/mw-slidy/blob/master/README.mediawiki (with one minor exception https://github.com/dov/mw-slidy/issues/1 ) which is great. Notably mw-slidy delivers "Incremental display of slide contents" as described @ http://www.w3.org/Talks/Tools/Slidy2/#%289%29 but it has an authoring problem which it seems to inherit from the wikitext parser (unless I'm missing something). I would like to be able to write <ol class="incremental"> # discuss ''problems'' # target ''etiologies'' # float generic ''solutions'' # pitch specific ''implementations'' # ''discuss'' ... </ol> This will display, but not incrementally; rather, the entire list displays at once. In order to display list items one-at-a-time in the slidy show, I must instead write HTML, i.e., <ol class="incremental"> <li>discuss <em>problems</em></li> <li>target <em>etiologies</em></li> <li>float generic <em>solutions</em></li> <li>pitch specific <em>implementations</em></li> <li><em>discuss</em> ...</li> </ol> which obviously loses one of the ease-of-authoring advantages of wikitext. It appears this is due to MW not respecting (or passing along) attribute=class for HTML elements={ol, ul} with inner wikitext: am I missing something? Note further that Slidy/mw-slidy supports outlining via the same mechanism: see http://www.w3.org/Talks/Tools/Slidy2/#%2810%29 TIA, Tom Roche <Tom_Roche@pobox.com>
List handling in the PHP parser (see doBlockLevels in Parser.php) does not consider HTML tags as part of the list and proceeds to produce its own list ol tags. Tidy or general tag cleanup stages then strip the outer (now invalid) ol tags. There is a large class of similar issues that are hard to address in the current parser without relatively difficult changes. I am working on the Parsoid parser [1], where this kind of problem is easier to handle. Will try to handle your use case there. [1]: http://www.mediawiki.org/wiki/Parsoid
