Update: field research will be testing an expanded sections view relatively soon, which will inform whether we take that relatively simpler approach to addressing the flash of unstyled content instead of, for example, applying a norlq approach or its like. The practical ramification of that the remediation probably starts a sprint later.

The field research suggests users prefer the collapsed ("closed") sections to all sections expanded ("open").

Okay so with that constraint a solution would look like the following:

• Using CSS and JS collapse all sections by default when client-js class is present.

There are a couple of problems with this:

1. on slow connections it will not be possible to open a heading until JS finishes loading
2. If a JS error is encountered it will never be possible to open the heading.

To counter these 2 cases we'd need to add an inline script that either opens sections after a certain period of time has elapsed or an inline script after every heading which makes the previous heading clickable.

@ovasileva please sync with @Jdlrobson on this (per prioritization meeting)

@Jdlrobson There are also all kinds of CSS-only collapse/expand (“accordion”) solutions that might be worth considering as fallback solutions.

If it turns out to be technically infeasible to collapse the sections ahead of time, is there a way to at least avoid the autocollapsing when the reader is in an expanded, pre-collapsed section?

@Jdlrobson, I believe what you're saying is domContentLoaded can and does perceptibly come after a user has
(a) as of today, scrolled past the first section
(b) supposing sections were collapsed by default (not the current behavior), tapped on a section heading to expand it
and therefore JS execution necessarily would be blocked from expanding a section.

Do I understand correctly?

The CSS spike concluded we can't do this in CSS so this means we have to do this in JS.
@dr0ptp4kt you do understand correctly.

It's not impossible to do this in a nice way but it's tricky.
Options include

1. Only loading the lead by default, loading all sections content with JS and creating a suitable fallback for viewing those sections without JS
2. Inserting JS after every single section heading to add event handlers to them
3. Accepting the trade off

This feels like it would benefit from some exploratory work. #3 could easily be tested in a prototype.

@Jdlrobson - sounds like we should have another spike looking at JS options

Option #3 is really a design/product decision, so I think we can rule that out as an option pretty quickly.

#1 is a large architectural decision which could easily be turned into a long term project. #2 is actionable, although is likely to be tricky.

I'd suggest starting with whether #3 is an option. I'd suggest no as on 2G it's a pretty terrible experience:

and if not we repurpose this card as #2 on the short term. This would look something like this - a script tag after every single section:

		$id = 'section-script-' . $sectionNumber;
		$js = 'console.log(document.getElementById("' . $id . '").previousSibling.previousSibling.onclick=function(ev) {var n = ev.currentTarget.nextSibling; if ( n.className.indexOf( "open-block" ) === -1) { n.className += " open-block"; n.onclick = null; }});';
		$script = $doc->createElement( 'script', $js );
		$script->setAttribute( 'id', $id );
		$el->appendChild( $script );

Option #4: Don't collapse sections. Bring back the ToC (styled in a useful way). This is what the apps do and with lazy loaded images being enabled now, I think it's worth it.

Edit: To clarify, keep sections collapsable, but leave them expanded by default. Flip the usage of the "expandedSections" LocalStorage feature to track which sections where collapsed instead.

Suggestion: Use <details> and <summary> elements to have native no-javascript collapsing of sections (avoiding FOUC), and then add a JS fallback for the few non-supporting browsers (Opera mini, IE mobile). This reduces the problem to a much smaller set of users.

Thanks @Yair_rand for the suggestion. Certain browsers do not render HTML5 elements without JS (e.g. IE6). @bmansurov previously dismissed this https://phabricator.wikimedia.org/T145106#2630311 but I'd love to see a prototype of that if anyone is willing to have a go....

Change 319067 had a related patch set uploaded (by Jdlrobson):
Collapse sections by default

https://gerrit.wikimedia.org/r/319067

Update: Two hygiene patches are long and tedious but ready for review: rEMFR9efeaab8c068: Hygiene: Make use of makeSectionHtml helper and rEMFRe9e74eee19ba: Hygiene: Tests should make use of helpers

• There is a minor issue with which someone should feel free to fix otherwise I will pick rEMFR14adf55512ad: Section blocks should have id attribute up in the morning. @pmiazga

said he might be able to have a look

• Once that is fixed rEMFR80cb07e58587: Collapse sections by default should pass Jenkins on a rebase, so please do take a look since that is the patch that fixes this problem.

In T126825#2695487, @Jdlrobson wrote:

Thanks @Yair_rand for the suggestion. Certain browsers do not render HTML5 elements without JS (e.g. IE6).

No, this is not true. In IE6 unknown elements (e.g. HTML5 tags) do render. They just can't be the target of custom CSS styles. The contents within render fine.

Working example without any JS (note that parent A and child C render fine, including styles):

The IE6 bug with styles for B can be trivially worked around by creating a wrapper and styling the parent instead. Or shim the element by having JavaScript no-op "create" 1 instance of that element (e.g. document.createElement('summary'); in <head>).

More importantly I don't we should worry about IE6 for the mobile site. It's of minor concern as Grade C for the desktop site, but is it of concern for mobile web?

And even if you'd want things to render nicely there, as indicated above, it would fallback fine in IE6. The interactive collapse/expand wouldn't work in IE6, but that is already the case as IE6 is a Grade C browser where we don't run JavaScript - sections are expanded by default there, which would continue to be the case.

@Krinkle do you want to add those comments to T148591. They are likely to get lost here since we decided css only solutions were too complex to achieve at this time.

The two hygiene patches are merged.
rEMFR14adf55512ad: is +1ed from me after Piotr's change.
rEMFR80cb07e58587: is verified by Jenkins and needs review.

Change 319067 merged by jenkins-bot:
Collapse sections by default

https://gerrit.wikimedia.org/r/319067

I believe all of the associated patches have been merged!
/cc @bmansurov

let me add one more hygiene task

In T126825#2777719, @pmiazga wrote:

let me add one more hygiene task

The patch @pmiazga mentioned does not block signoff of this task, to be clear.

Is this not an important thing to QA more thoroughly via the specialist guild? I found T150237 while testing.

Also did someone confirm how it behaves on cached HTML..? I think the worse case would be sections are collapsed and cannot be expanded, which may be a necessary penalty on the long term.

This is still an issue on Android as seen in two videos I've attached for different browsers,

Web Browser for Android (globe)

and

Chrome on Android

This as far as I've noticed was an Android-specific situation and I haven't noticed it in Safari or Chrome on iOS 10.0.2 (iPhone).

collapsing seems to be unavailable for first section - arrow disappears

This was merged on Monday so should be live on English Wikipedia on Thursday. It can be tested in the meantime on https://en.m.wikipedia.beta.wmflabs.org (which is why this appears to still be an issue).
@ovasileva the bug you refer to is captured in T150237

sorry - that was my (early morning) fault - I forgot to add reproduction steps - moving back to QA

I've noticed on Web Browser for Android (globe)

T126825#2784553 was half the work. We should have tested if sections would expand upon tapping on a slow network while the page is still loading.