Mobile support in MediaWiki core

About

By default, MediaWiki does not offer mobile device-specific support, making MediaWiki sites very difficult to use on mobile devices. This has been mitigated in many ways by Extension:MobileFrontend, however there is much to be gained by building native mobile support into MediaWiki core. Such as:

Increased performance
A better framework for other extensions to make mobile-specific features
Out-of-the-box mobile support for MediaWiki sites
A present and future-ready device-agnostic core that can display data in a multitude of different ways, increasing MediaWiki's flexibility
Greater developer and end-user support by increasing exposure to mobile-specific issues

Candidates for upstreaming

includes/DeviceDetection.php

This code is a candidate for upstreaming to core.

The move to core

Changes to MobileFrontend

Use of css_file_name should be deprecated.

Once we remove them, what will remain? Max Semenik (talk) 21:39, 2 July 2013 (UTC)[reply]

Changes in core

Core should be able to detect a mobile device and determine whether to render in HTML or WAP mode (or other)

WML/HTML/other is a very subjective, implementation-specific thing. For example, while a device might claim HTML support, it may be so horrible for out SkinMobile purpose that we prefer to feed it with WML. Other implementations might decide otherwise.

includes/MobileContext.php

This is probably not in a state where it could be moved to core.

includes/formatters/

MobileFrontend currently takes the result of the parser output and runs a regex on the result to split pages into their corresponding sections.

It does this for several reasons:

To mark up each individual section in such a way that a section can be tied to its heading and the heading can toggle it open.
JavaScript can identify sections. For example it can use css selectors to find all the images/cleanup templates within the lead section ( $( '#content_0 img' ) )

The move to core

Changes to ParserOutput

ParserOutput::getSections altered such that each section also contains the text of that section.
When an article has sections the value returned by getSections is passed to all skins alongside bodytext. Skins can choose to use this for rendering. In WML for instance the output uses card markup - the Parser should not make assumptions on how rendering will happen. A skin may also want to make use of HTML5 section tags.
ParserOutput needs several configuration options:
1. It should be possible to remove the table of contents from the output so that skins can have more control over its rendering. A table of contents can be determined from the output of getSections if necessary.
2. It should be possible to disable red links. Rationale: Currently it is very hard to create an article on mobile. Mobile currently strips out red links from the outpu
3. Ability to request the parser doesn't render images. Rationale: Phones with expensive data costs or slow connections should be able to toggle on/off images. Mobile currently has support for this but to provide this service it must parse the parser output and remove all images from the output. When images are disabled instead of rendering an image a span tag is rendered with the alt tag.

Changes to MobileFrontend

$defaultItemsToRemove should be done in css. In theory this should be possible once table of contents has been separated from the output.
See User:MaxSem/Mobile HTML transformations for my analysis. Max Semenik (talk) 21:39, 2 July 2013 (UTC)[reply]

includes/MobileFrontend.body.php

This file will be gone soon. Max Semenik (talk) 21:39, 2 July 2013 (UTC)[reply]

OutputPage.php has a function output() which sets various headers. In MobileFrontend we send various additional headers for mobile devices. These should be sent conditionally in core.

This is dependant on DeviceDetection.php being moved to core.

The function DOMParse would be made unnecessary by killing MobileFormatter.php in MobileFrontend.

includes/skins

The mobile skin is very complex from the standard desktop skin. It is tied to various of the components above - mainly MobileContext.php and MobileFormatter.php.

Support for anonymous urls: Currently in desktop skins if a user is not logged in a url is not generated and the link to a feature requiring a login is not needed. Instead it should be possible to generate a url to the login form that redirects to this feature.
Url rewriting: In various places urls must be rewritten for mobile to include the en.m domain name and force https. It would be useful for a generic way for a skin to have a little more control over this.