Change Details

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. 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 experience * Minimal bloat to HTML * Simple solution that is shippable in a sprint: ** Minimal input needed from design research and design team given that we've shown the value of collapsing sections to users. 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. Cons: * 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: Pros: Cons: = 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. The owners of each should be prepared for the meeting to be able to list pros and cons of each approach.

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. 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 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. Cons: * 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: Pros: Cons: = 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. The owners of each should be prepared for the meeting to be able to list pros and cons of each approach.

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. 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 experience * Minimal bloat to HTML * Simple solution that is shippable in a sprint: ** Minimal** No input needed from design research and design team 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. Cons: * 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: Pros: Cons: = 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. The owners of each should be prepared for the meeting to be able to list pros and cons of each approach.