To move this along the developers of the team got together and brainstormed possible solutions. We are going to prototype all solutions. We will demo these prototypes to @nirzar and @ovasileva on the Donald Trump article on a mobile device (emulated in Chrome).
The prototypes are:
= Adding click handlers
Will be added to all headers to allow sections to be expanded (which will be removed when the toggle code loads)
Owner: @Jdlrobson
Link: https://gerrit.wikimedia.org/r/314210
Pros:
* Solves the goal - Removes the flash of unstyled content with no impact on no JS or printed experience
* Minimal bloat to HTML
* Simple solution that is shippable in a sprint:
** No input needed from design research given that we've shown the value of collapsing sections to users
** Minor input needed from design team. The only decision necessary would be whether we need to show the collapse arrow icon in this intermediate state.
** From technical side, we'd need to add/update some tests and ensure the inline script does not leak into API results. We may want to shift the code in the prototype from the MobileFormatter into the skin.
** No changes in accessibility from normal - open sections still can happen with tab and enter key.
Cons:
* Minor maintenance cost
** Inline JavaScript is difficult to invalidate if we hit any issues, but given we are doing the same for lazy loading image we have set a precedent.
** We will have to be careful to keep inline script in sync with the toggle code
* Sections cannot be reopened until the page JavaScript has fully loaded. If the JS fails to load for any reason, due to a JS error, it will never be possible to close them but it will also not be clear that they need to be closed
= Checkbox hack
Owner: @phuedx
Link: https://gerrit.wikimedia.org/r/#/c/315512/
Pros:
* No FOUC
* CSS-only
** Can be progressively enhanced to include remembering whether a section was toggled
* Trivially simple to style, minimising the hit to top-loaded styles.
* Toggling JavaScript code can be removed or drastically simplified.
* [Supports all Grade A and C browsers](http://caniuse.com/#feat=css-sel3).
Cons:
* A dramatic DOM structure change – we'll need to move section headings inside of section containers.
* The simplicity of the styles comes at the cost of additional complexity in constructing the page.
* As the name implies, it's a hack…
= Sections expanded by default with table of contents
Owner: @bmansurov
Link: https://gerrit.wikimedia.org/r/#/c/313874/
Pros:
* ToC after lead section for all types of browsers: JS/non-JS, mobile/tablet.
* Less tech debt as we won't be rendering MF version of ToC and as we'll be removing the section collapsing code
* No FOUC.
* Progressively enhanced ToC, viewable in an overlay for easy navigation without leaving the read position.
* Allows easy searching on the page as there are no collapsed sections.
* Consistent look and feel across form factors as opposed the current situation where ToC is visible on tablet-sized devices only.
* Printing styles don't need special treatment as sections are expanded.
* No need to worry if JS fails rendering collapsed sections useless as there is no collapsing at all.
Cons:
* Non-JS users have to scroll to the top of the page to see the ToC.
* On articles with many headings, the HTML size may get bigger a little bit. But, this increase may also be offset by the decrease in the modules we ship as we'd be removing `mobile.toggle` related code.
= Details / section tags ( as suggested by @Yair_rand )
Owner: @Jdlrobson
Link: http://jdlrobson.com/tmp/Trump.html
Caveats: The prototype collapses all section headings / not just the highest level one (easily fixed but something to be aware of)
Pros:
* Section collapsing becomes available for certain non-JavaScript users (any which have intentionally disabled JS) and grade C browsers (potentially UC Mini running extreme mode)
* Limited styling needed
* JavaScript code for toggling JavaScript can be removed (unless we want to support mobile options open by default)
* Gracefully degrades
* IE6 will render the content with the HTML5 shim.
* This is mostly accessible - in Chrome for example you can expand with enter key. Older versions however may [[ http://accessibleculture.org/articles/2012/03/screen-readers-and-details-summary/ | experience issues ]].
* Section collapsing is instantly available and usable even on 2G connections as no JS is required.
Cons:
* Complex change in MobileFormatter - we'd need to wrap all sections and headings in a container
* IE6 without JS will not render any content due to the way it handles new HTML5 elements.
* Section collapsing will disappear for certain browsers that support JS. [[ http://caniuse.com/#feat=details | most notably Internet Explorer/Edge based phones ]].
** another way at looking at this is we exert pressure on IE to adopt this standard. We are a big website. We have a chance to make the web better.
* Some people may not like the markup
The owners of each should be prepared for the meeting to be able to list pros and cons of each approach.