On Sat, Jun 2, 2012 at 1:03 AM, Arthur Richards arichards@wikimedia.orgwrote:
*View-specific functionality* Different view types will likely have different bits of functionality that they require, separate from the rest of MW, that may not make sense to exist in a Skin. We could allow different view types the opportunity to bootstrap view-specific functionality when appropriate. If we segment this functionality to only load for a specific view-type, we can prevent unnecessary components from loading if they are not appropriate for a specific view. I haven't yet really flushed this concept out, and am very open to suggestions on implementation.
I think there's two main parts to this: chrome and content.
Chrome is usually skin-provided stuff like the menus, sidebars, etc -- and we rearrange that dramatically for mobile, hide it for print, etc. The existing skin system seems to be able to handle this as we're seeing with the migration of MobileFrontend to using skins. Yay!
Content would cover things like numbered [1] links being expanded in a list in print mode -- we accomplish this today by hiding the list of links via CSS in non-print views.
For example, references should really be similarly treated: on desktop/tablet and mobile views they should pop up inline when you click them, while for print we really do want the big lists of refs so they make it to output. Potentially we can also have smarts for dealing with video or animated content with "flat" alternate content for print -- such as separating an animated diagram into multiple diagrams in print version.
This sort of thing can be accomplished by pure CSS -- having standard classes that hide things on mobile or on print -- or slightly more complicatedly with more parser fun having output format knowledge or replacement chunks... I think I recommend using CSS to avoid complicating things. ;)
Potentially hidden items could also be stripped from view to avoid transferring extra data, though...
I started hacking a bit at a few core files to give a code example of how
this might be implemented, at least for dynamically loading view-specific skins: http://pastie.org/4010775
Probably the most important thing is having smart fallbacks; if there's a customized desktop skin, but no mobile or print version of it, then on print or mobile view we should fall back to the default mobile or print skin rather than getting stuck on the preferred desktop skin. This'd make it easy to customize the desktop view while still having things work sanely in other views -- and having standard naming makes it easy to then go ahead and customize the mobile view too.
-- brion