On Sat, Jun 2, 2012 at 1:03 AM, Arthur Richards <arichards(a)wikimedia.org>wrote;wrote:
*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