MobileFrontend/Dynamic Sections

This puts down some ideas on how we could reduce the page size we serve to mobile users.

Problem
Large pages are a problem on mobile devices for several reasons.
 * On older devices they can cause slowdown (for example Bugzilla::32773
 * Network connectivity can heavily impact download speed and ability, and it is extremely variable
 * Evidence (citation needed) suggests that many users on mobile get the answer they are looking for in the first section - thus we are loading lots of unnecessary content on initial load see Bugzilla::31011

Proposed Solution

 * When accessing a page on the mobile site (e.g. http://m.wikipedia.org/wiki/San%20Francisco) we load the summary of the article and the headings of the sections in that article.
 * Section headings for non javascript enabled devices would link to a dedicated section page

For pages with javascript

 * Devices with javascript would enhance these links so that when clicked they load sections dynamically. YuviPanda has done some work on this in the Mobile App so it would be a case of refactoring and reusing that code.
 * On unfolding a section the address bar would be update with a hash - refreshing a page with javascript and this hash would load that section

For pages without javascript

 * Without javascript these links would render only that section e.g http://en.m.wikipedia.org/wiki/San_Francisco/Section:History would load a page with just the history section.
 * Clicking the title of the article (San Francisco) in any given section (e.g. the history section) or pressing the back button would return a user to the main page

Working with the API
I would appreciate some feedback from MaxSem.

Section headings would need to annotate themselves with their section id to assist in the usage of the api. Currently section ids on a given page are based on their position in the document. The 10th heading in a page will have id 10 however than 10th heading might be a h4 tag hidden within the second h2 tag. With the above proposal the page will only know its top level sections so it will be difficult to know what id to pass to the api without assistance from the server. I suggest this is done by annotating h2 tags with a 'data-section' attribute which contains the id of that section needed to look it up in the api.

One concern I have is whether the id's are reliable. For example take a page with 3 headings 'A', 'B' and 'C'. Imagine content of those sections is only clicked when I load those headings. If I click 'B' a request to the api is made to grab section with id 2. However between me loading the page and clicking 'B' another user might add a new section above 'A' called 'Z'. My worry is that when clicking 'B' it actually grabs section 'A' as the id's have now changed with respect to the document.

Implementation
A first stab at it can be found here: https://gist.github.com/2428322


 * Currently this uses javascript to simulate what the server should do
 * the section id's are wrong and do not correspond to the ones required by the api
 * no styling has been done

Future enhancements
This would pave the way to make even more radical changes to the mobile site, including using the HTML5 history api to dynamically load pages navigated to via search or links.

To think about

 * How would saving pages would where a page has not been completely downloaded?
 * How would this effect a find on page function?