Right now we have JavaScript (mobile.toggle) to handle section collapsing. Let's explore whether this can be done with CSS to avoid the issues with a JS only implementation.
Questions to answer:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T125920 [EPIC] Future exciting reading web performance endeavours | |||
| Resolved | ovasileva | T126825 Sections on mobile views jumps around after load (FOUC) | |||
| Resolved | • Jhernandez | T145106 [2hr] Can section collapsing be done via CSS | |||
| Resolved | ssastry | T114072 <section> tags for MediaWiki sections | |||
| Resolved | • bearND | T178705 Prepare MCS for Parsoid section tags | |||
| Resolved | • bearND | T178706 Improve section parsing in mobile-sections endpoint | |||
| Resolved | • bearND | T178707 Create script to compare old and new sectioning code | |||
| Resolved | • bearND | T178708 Update Wiktionary definition parsing to account for new (possibly nested) section tags |
Purse CSS solution doesn't seem to be possible. We may try re-structuring the HTML and styling with :focus and :active, but that would only toggle a single section. Showing another section would hide the previously shown section.
Alternatives maybe:
Neither option seems worth pursuing. Bad browser support and non-semantic HTML (not to mention the mixing of presentation and functional behavior) are deal breakers.
Yet another alternative is to go for the suggestion at T126825#2586807 while addressing the issues raised. The suggestion is:
Using CSS and JS collapse all sections by default when client-js class is present.
The issues are:
on slow connections it will not be possible to open a heading until JS finishes loading
This can be addressed by creating minimal JS (that may optionally not depend on jQuery) to toggle sections and loading this code in the head of the document.
If a JS error is encountered it will never be possible to open the heading.
This is an indication of a bigger problem. If JS error occurs, other important parts of the page including search and language switching won't work either. Even in that case, because of the alternative toggling code in the head of the document, toggling may still keep working.
Using the not-so-well supported detail/summary.
Support doesn't seem them bad when you consider our browser matrix. Certainly something to consider as part of a solution. It would at least fix for most browsers outside Firefox/IE, but it might be useful as part of a solution to ensuring backwards compatibility.
I agree we should consider semantic HTML however.
@bmansurov probably worth pinging @Volker_E he seemed to have some ideas how this might be possible.
This can be addressed by creating minimal JS (that may optionally not depend on jQuery) to toggle sections and loading this code in the head of the document.
I'm pretty sure this will not work... Even if the code is in the head it will have to wait until the document ready event. The code would have to be injected after every single section to ensure the section can be collapsed as well as seen. We could however add a timeout that toggles sections open after some time or a button that opens sections - but this would require design input.
If a JS error is encountered it will never be possible to open the heading.
This is somewhat fair, but search and language switching are progressively enhanced and will/should degrade to a form/button. Regardless the consequences of not being able to view content are more higher than if search or toggle doesn't work.
Ping @phuedx @Jhernandez @jhobs let's continue the conversation here, but it doesn't seem we have a clear tangible path forward yet based on Baha's analysis so far.
The checkbox hack uses the :checked and ~ CSS3 selectors. These selectors are supported by all Grade A browsers and very nearly all Grade C browsers – not IE6/7/8 and not Opera 10.0..
Having non-semantic (solecistic?) HTML might be an acceptable tradeoff to a solution that can compressed into a small-ish number of bytes, inlined, and made to work without the Resource Loader.
@Jhernandez and @jhobs would you please chime in? @Volker_E we'd appreciate your input too.
Sorry, I forgot to submit my comments yesterday.
I don't think either of the proposed solutions are worth implementing given the minimal support and/or debt introduced. Out of the options, I'd go with (1), but it still probably wouldn't solve the collapsing problem for most non-js browsers given the lack of support. The checkbox hack seems like it would introduce more debt than good.
Thus, my vote is for "leave as-is."
AFAIK one feature of expanding collapsing is that if you refresh the page or come back it remembers the sections you had opened before.
How would we do the storing/restoring of that state if we use CSS? Doesn't seem doable so we'd have to drop that feature if so.
@Jhernandez could make section headings links and allow changing hashes in the URL so that when the user comes back we could use the :target selector to collapse the section?
Messing with hashes means messing with sharable links. This doesn't seem like a good route to go down IMHO.
Care to elaborate? What is wrong with being able to share a link that points to a section? Isn't that the desired behavior?
You can already share a link that points to a section. I'm saying we should avoid changing links whenever a user toggles a section. For example, say I read an article called "Share" with 5 sections, each titled the english word for a number. I expand each section as I go, which modifies the URL hash. I then decide to share that article with a friend, not specifically referencing any specific section. If I copy the URL from my address bar, (or share from the phone's browser's overflow menu) it'll read something like this:
https://en.m.wikipedia.org/wiki/Share#Five
Which would link directly to the 5th section, which could be external links or references. This is not the desired behavior.
Additionally, I don't see how that would solve Joaquin's original issue, which is referring to saving the expanded sections in LocalStorage for when a user returns to the same article (but not necessarily using the back button, meaning they might not have the URL hash). That being said, if we wanted to keep that feature we could still do it more or less the same way we do now (with Javascript), so I don't think it's too big of a concern.
Fair points. I don't think we should aim for feature parity with the JS version. More capable browsers get a better experience.
Looks like we're agreeing on not using the CSS only or other alternative approaches mentioned at T145106#2630311 given the concerns from some developers (including me).
Right now we have JavaScript (mobile.toggle) to handle section collapsing. Let's explore whether this can be done with CSS to avoid the issues with a JS only implementation.
Could someone clarify what the issues are with the JS-only implementation.
If you're referring to mobile.toggle then one of the issues is that it loads late for slow connections, which makes toggling impossible until it's done loaded.
If you're referring to a general JS solution, I don't think there are any issues even after reading T145106#2631326. Everything mentioned there can be solved in some way or another without affecting performance.
Questions to answer:
- could we do this via css only.
Yes. We could either details and summary elements or the checkbox hack
- What is the browser coverage of such a solution? e.g. any browsers such a solution would not work on
Details and summary elements are supported by fewer browsers but they are supported by most of our Grade A mobile browsers.
The checkbox hack uses the :checked and ~ CSS3 selectors. These selectors are supported by all Grade A browsers and very nearly all Grade C browsers – not IE6/7/8 and not Opera 10.0..
What are the benefits of using a CSS-only solution?
What are the drawbacks of using a CSS-only solution:
Hey @Krinkle . I saw that you reopened the task. Mind specifying why? It's still currently assigned to @Jhernandez , too, but he's about to go on vacation. Thanks :)
This task was a spike and should probably not have been reopened. Discussion on this topic has moved to T148591: Evaluate providing section collapsing to older browsers where we do not run JS.