[Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
For wider distribution! -- Forwarded message -- From: Jon Robson Date: Tue, Apr 23, 2013 at 5:13 AM Subject: [WikimediaMobile] Rethinking MobileFormatter / Skins To: mobile-l I've been playing around with skins a lot recently. The MobileFrontend extension has had to do various transformations to the content pre-rendering to ensure certain things do not get rendered on mobile (for example table of contents) as well as allow us to do collapsible sections. When rendering content skins are currently limited to rendering the 'bodytext' key. They cannot retrieve the underlying content. I would like to remove restrictions to skin designers - for instance currently a skin designer has no control over where the table of contents should do. They could not easily put it in a side bar for instance. I was experimenting with using the onOutputPageParserOutput hook [1] (running based on the current skin) and think it might be a better approach to run the transformations on smaller chunks of data. For instance the table of contents is known to be in the lead section so it seems like it would be more efficient to look for it there rather than throughout the entire document. The solution is not complete but provides an approach that I think would be more efficient on the long term. It seems like a good idea to experiment with this approach in MobileFrontend extension with the goal to upstream it to core. Would appreciate comments from people who know this area of code rather well - Max comes to mind :) Thoughts welcomed! [1] https://gist.github.com/jdlrobson/5439509 ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
>I was experimenting with using the onOutputPageParserOutput hook [1] > (running based on the current skin) and think it might be a better >approach to run the transformations on smaller chunks of data. For >instance the table of contents is known to be in the lead section so >it seems like it would be more efficient to look for it there rather >than throughout the entire document. The solution is not complete but >provides an approach that I think would be more efficient on the long >term. Not to nitpick, but in your particular example one can use the __TOC__ magic word you can place the table of contents wherever you want in the document.[0] At least in that case, parsing the entire document might be best. /me goes back to lurking. Thank you, Derric Atzrott [0]: https://www.mediawiki.org/wiki/Help:Magic_words ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
On Tue, 23 Apr 2013 11:06:13 -0700, Yuvi Panda wrote: For wider distribution! -- Forwarded message -- From: Jon Robson Date: Tue, Apr 23, 2013 at 5:13 AM Subject: [WikimediaMobile] Rethinking MobileFormatter / Skins To: mobile-l I've been playing around with skins a lot recently. The MobileFrontend extension has had to do various transformations to the content pre-rendering to ensure certain things do not get rendered on mobile (for example table of contents) as well as allow us to do collapsible sections. When rendering content skins are currently limited to rendering the 'bodytext' key. They cannot retrieve the underlying content. I would like to remove restrictions to skin designers - for instance currently a skin designer has no control over where the table of contents should do. They could not easily put it in a side bar for instance. I was experimenting with using the onOutputPageParserOutput hook [1] (running based on the current skin) and think it might be a better approach to run the transformations on smaller chunks of data. For instance the table of contents is known to be in the lead section so it seems like it would be more efficient to look for it there rather than throughout the entire document. The solution is not complete but provides an approach that I think would be more efficient on the long term. Partially for other reasons I have contemplated making the TOC a post-parse task. A placeholder gets put into the skin where the TOC goes. Then the TOC is inserted afterwards. Though 'when' is a little different in the situation I'm thinking of. In that situation I'm just thinking of deferring it to ParserOutput::getText. The same way we defer the editsection link. It seems like a good idea to experiment with this approach in MobileFrontend extension with the goal to upstream it to core. Would appreciate comments from people who know this area of code rather well - Max comes to mind :) I haven't given that much thought to it as a part of core. But the idea of marking off various parts of the page content as components that can be considered separate from the content and removed is an interesting idea. Both TOC and parts of the content. I've actually hacked things like that into live sites. Blocks of mainpage content moved to the sidebar: http://www.dragonballencyclopedia.com/wiki/Dragon_Ball_Encyclopedia Infoboxes moved to the sidebar: http://www.dragonballencyclopedia.com/wiki/Son_Goku_%28anime_character%29 I also did it fairly recently for a client's (EAW's) wiki. But they don't appear to have updated their content to make it work yet. Thoughts welcomed! [1] https://gist.github.com/jdlrobson/5439509 It's not directly related but in my plins to rewrite the skin system I have considered something relevant. A little stale but somewhat readable. https://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Regions https://www.mediawiki.org/wiki/User:Dantman/Skinning_system/New_skin_layout -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
Thanks for pointing out the __TOC__ magic word. Out of interest - for what reason do we support this? It seems like a bad thing to allow inconsistencies between page content on the same wiki. If a table of contents is in the lead section for one article but in the third section for another article this is bad from a user experience point of view. One of my main pain points I have been experiencing in skin development is the 'bodytext' data value - it makes far too many assumptions about how the content should be rendered. On Tue, Apr 23, 2013 at 11:21 AM, Derric Atzrott wrote: >>I was experimenting with using the onOutputPageParserOutput hook [1] >> (running based on the current skin) and think it might be a better >>approach to run the transformations on smaller chunks of data. For >>instance the table of contents is known to be in the lead section so >>it seems like it would be more efficient to look for it there rather >>than throughout the entire document. The solution is not complete but >>provides an approach that I think would be more efficient on the long >>term. > > Not to nitpick, but in your particular example one can use the __TOC__ magic > word you can place the table of contents wherever you want in the document.[0] > > At least in that case, parsing the entire document might be best. > > /me goes back to lurking. > > Thank you, > Derric Atzrott > > [0]: https://www.mediawiki.org/wiki/Help:Magic_words > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
On Tue, Apr 23, 2013 at 2:52 PM, Jon Robson wrote: > Thanks for pointing out the __TOC__ magic word. Out of interest - for > what reason do we support this? It seems like a bad thing to allow > inconsistencies between page content on the same wiki. If a table of > contents is in the lead section for one article but in the third > section for another article this is bad from a user experience point > of view. > I believe (anecdotally) that it's more often used on meta-style pages (policy and discussion) where you want a couple of sections before the TOC. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
Daniel Great to hear I'm not alone in my thoughts. Things like the edit section link shouldn't have to be hacked in at the parser level - if the parser returned the components of a page it would be trivial for the skin to add these itself. The fact you are resorting to hacks to do things which should be trivial (the infoboxes is a great example) suggest that this is a smell that would be good to fix. I can't help but think of Wikipedia redefined [1] which had some interesting ideas that alas would be very hard to try out in the current setup. Another example I can give is in mobile is we render cleanup templates as an overlay as these can fill an entire mobile screen on certain articles making the content unreadable (very much against "a world in which every single human being can freely share in the sum of all knowledge." :)). We have had to add some javascript which collapses them but it would be great to have a better solution for non-javascript users (maybe hide the cleanup templates or put them at the bottom of the page and create a link to that at the top for those who need them) as currently this "a world in which every single human being" ... with javascript .. " can freely share in the sum of all knowledge." :) [1] http://www.wikipediaredefined.com/ On Tue, Apr 23, 2013 at 11:52 AM, Daniel Friesen wrote: > On Tue, 23 Apr 2013 11:06:13 -0700, Yuvi Panda wrote: > >> For wider distribution! >> >> >> -- Forwarded message -- >> From: Jon Robson >> Date: Tue, Apr 23, 2013 at 5:13 AM >> Subject: [WikimediaMobile] Rethinking MobileFormatter / Skins >> To: mobile-l >> >> >> I've been playing around with skins a lot recently. The MobileFrontend >> extension has had to do various transformations to the content >> pre-rendering to ensure certain things do not get rendered on mobile >> (for example table of contents) as well as allow us to do collapsible >> sections. >> >> When rendering content skins are currently limited to rendering the >> 'bodytext' key. They cannot retrieve the underlying content. I would >> like to remove restrictions to skin designers - for instance currently >> a skin designer has no control over where the table of contents should >> do. They could not easily put it in a side bar for instance. >> >> I was experimenting with using the onOutputPageParserOutput hook [1] >> (running based on the current skin) and think it might be a better >> approach to run the transformations on smaller chunks of data. For >> instance the table of contents is known to be in the lead section so >> it seems like it would be more efficient to look for it there rather >> than throughout the entire document. The solution is not complete but >> provides an approach that I think would be more efficient on the long >> term. > > > Partially for other reasons I have contemplated making the TOC a post-parse > task. A placeholder gets put into the skin where the TOC goes. Then the TOC > is inserted afterwards. > Though 'when' is a little different in the situation I'm thinking of. In > that situation I'm just thinking of deferring it to ParserOutput::getText. > The same way we defer the editsection link. > > >> It seems like a good idea to experiment with this approach in >> MobileFrontend extension with the goal to upstream it to core. >> >> Would appreciate comments from people who know this area of code >> rather well - Max comes to mind :) > > > I haven't given that much thought to it as a part of core. But the idea of > marking off various parts of the page content as components that can be > considered separate from the content and removed is an interesting idea. > Both TOC and parts of the content. > > I've actually hacked things like that into live sites. > > Blocks of mainpage content moved to the sidebar: > http://www.dragonballencyclopedia.com/wiki/Dragon_Ball_Encyclopedia > > Infoboxes moved to the sidebar: > http://www.dragonballencyclopedia.com/wiki/Son_Goku_%28anime_character%29 > > I also did it fairly recently for a client's (EAW's) wiki. But they don't > appear to have updated their content to make it work yet. > > > >> Thoughts welcomed! >> >> [1] https://gist.github.com/jdlrobson/5439509 > > > It's not directly related but in my plins to rewrite the skin system I have > considered something relevant. > A little stale but somewhat readable. > https://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Regions > https://www.mediawiki.org/wiki/User:Dantman/Skinning_system/New_skin_layout > > -- > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] > > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
It's an interesting idea. Though it won't be trivial. But we could start to express the parser output of pages as high level components nested in each other. Like a document with a TOC nested in it, as well as high-level headers (or maybe sections), emeded image frames, etc... where things like the headers and image frames are components with their own rendering that the skin could create components to replace the rendering for. And even strip the component out of the page and put it somewhere else. Though it can't be a simple list of components since many of these things have specific locations inside the content to go in. Then again. Ideas like this may just make VisualEditor/Parsoid harder. We might want to come back to this once Parsoid is done with it's dom, etc... On Tue, 23 Apr 2013 12:01:00 -0700, Jon Robson wrote: Daniel Great to hear I'm not alone in my thoughts. Things like the edit section link shouldn't have to be hacked in at the parser level - if the parser returned the components of a page it would be trivial for the skin to add these itself. The fact you are resorting to hacks to do things which should be trivial (the infoboxes is a great example) suggest that this is a smell that would be good to fix. I can't help but think of Wikipedia redefined [1] which had some interesting ideas that alas would be very hard to try out in the current setup. Another example I can give is in mobile is we render cleanup templates as an overlay as these can fill an entire mobile screen on certain articles making the content unreadable (very much against "a world in which every single human being can freely share in the sum of all knowledge." :)). We have had to add some javascript which collapses them but it would be great to have a better solution for non-javascript users (maybe hide the cleanup templates or put them at the bottom of the page and create a link to that at the top for those who need them) as currently this "a world in which every single human being" ... with javascript .. " can freely share in the sum of all knowledge." :) [1] http://www.wikipediaredefined.com/ -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
The things that are not the most trivial are the most challenging and fun. I'd hate to wait for Parsoid - if anything this would help Parsoid by defining the needs of mediawiki's parser. I would suggest starting with just extracting table of contents and section data into individual components... On Tue, Apr 23, 2013 at 12:27 PM, Daniel Friesen wrote: > It's an interesting idea. Though it won't be trivial. But we could start to > express the parser output of pages as high level components nested in each > other. Like a document with a TOC nested in it, as well as high-level > headers (or maybe sections), emeded image frames, etc... where things like > the headers and image frames are components with their own rendering that > the skin could create components to replace the rendering for. And even > strip the component out of the page and put it somewhere else. > > Though it can't be a simple list of components since many of these things > have specific locations inside the content to go in. > > Then again. Ideas like this may just make VisualEditor/Parsoid harder. We > might want to come back to this once Parsoid is done with it's dom, etc... > > > On Tue, 23 Apr 2013 12:01:00 -0700, Jon Robson wrote: > >> Daniel >> Great to hear I'm not alone in my thoughts. Things like the edit >> section link shouldn't have to be hacked in at the parser level - if >> the parser returned the components of a page it would be trivial for >> the skin to add these itself. >> >> The fact you are resorting to hacks to do things which should be >> trivial (the infoboxes is a great example) suggest that this is a >> smell that would be good to fix. >> >> I can't help but think of Wikipedia redefined [1] which had some >> interesting ideas that alas would be very hard to try out in the >> current setup. >> >> Another example I can give is in mobile is we render cleanup templates >> as an overlay as these can fill an entire mobile screen on certain >> articles making the content unreadable (very much against "a world in >> which every single human being can freely share in the sum of all >> knowledge." :)). We have had to add some javascript which collapses >> them but it would be great to have a better solution for >> non-javascript users (maybe hide the cleanup templates or put them at >> the bottom of the page and create a link to that at the top for those >> who need them) as currently this "a world in which every single human >> being" ... with javascript .. " can freely share in the sum of all >> knowledge." :) >> >> [1] http://www.wikipediaredefined.com/ > > > -- > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
On 04/23/2013 08:52 PM, Jon Robson wrote:
Thanks for pointing out the __TOC__ magic word. Out of interest - for
what reason do we support this? It seems like a bad thing to allow
inconsistencies between page content on the same wiki.
In some list articles, where the TOC is long and where each
heading is short, it is useful to put the __TOC__ in a
right-floating table, so the user doesn't have to scroll very
long to find the first text:
{| align=right
|-
| __TOC__
|}
Here is one example,
https://en.wikipedia.org/wiki/1951_in_comics
--
Lars Aronsson (l...@aronsson.se)
Aronsson Datateknik - http://aronsson.se
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
