Page MenuHomePhabricator

[2hr] Can section collapsing be done via CSS
Closed, ResolvedPublic

Description

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:

  1. could we do this via css only.
  2. What is the browser coverage of such a solution? e.g. any browsers such a solution would not work on

Event Timeline

Jdlrobson created this task.Sep 8 2016, 6:37 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task from To Triage to 2016-17 Q2 on the Readers-Web-Backlog board.

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:

  1. Using the not-so-well supported detail/summary.
  2. Using the checkbox hack.

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.

Jdlrobson added subscribers: phuedx, Jhernandez, jhobs.

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.

phuedx added a comment.EditedSep 13 2016, 8:04 AM

Alternatives maybe:

  1. Using the not-so-well supported detail/summary.
  2. Using the checkbox hack.

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.

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?

@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.

@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).

bmansurov removed bmansurov as the assignee of this task.Sep 16 2016, 5:14 PM
Jhernandez closed this task as Resolved.Sep 19 2016, 11:02 AM
Jhernandez claimed this task.

Any other followups that should come from this spike?

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.

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:

  1. could we do this via css only.

Yes. We could either details and summary elements or the checkbox hack

  1. 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?

  • If the CSS were inlined, a CSS-only solution could work without the ResourceLoader being loaded
  • Smaller perceived time to interactive (TTI) as section toggling is available after DOMComplete – I think…
  • A lot of the mobile.toggle module could be removed

What are the drawbacks of using a CSS-only solution:

  • The current JS-only implementation also stores whether a section has been collapsed on a page. Obviously, a CSS-only solution can't do this
  • We'd marginally increase the payload size by adding extra markup to every section – we already add extra markup but we'd need to add more
  • Rolling back after discovering a critical bug would involve invalidating cached markup
Krinkle reopened this task as Open.Nov 1 2016, 11:07 PM

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 :)

jhobs closed this task as Resolved.Nov 2 2016, 3:07 PM

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.