Replace collapse.js with a proper polyfill for <details>

I'm looking for input from @mbrett5062 on this. Really great the things that a modern browser and HTML5 is taking care of.

Just some quick thoughts/ideas.

I see that Mathias Bynens feature detection that is used by @sun is now in 'modernizer', and also that they are getting close to releasing version 3 which breaks it all up into a pluggable system.

Meanwhile, I have looked over his latest version, and it is much improved, taking the whole thing (detection and polyfill) will be a benefit to us. I commented over on #1168246: Freedom For Fieldsets! Long Live The DETAILS. (Inappropriately).

The new script works better across browsers, and I notice that he no longer tries to add a link because Chrome now supports this element. Instead his script now makes all browsers look and work the same. Then just style in CSS as you wish.
I.E. change cursor to pointer and text color to blue on 'summary' element to emulate a link and give user feedback.

He also includes new aria roles for accessibility.

Here is the link to his code. jquery-details

@sun the one you copied into collapse.js, was that not from Mathias Bynens? If so that is the one included in modernizer, so your could be removed. I really don't care were it lives, but 1 only is a good idea I think.

Also as I mentioned before, currently in Google Chrome the summary element looks horrible. I know it is browser default styling, but no visual clue that this is clickable is a UX regression for our users, IMHO. If as I stated (and Mathius has done) we do not add the summary as a link, instead just as plane text, that is clickable. Then style all with the same text color as a link and change the cursor to a pointer, this will make all browsers, regardless of support for details, look and feel the same.

Just like to weigh in that I support styling the details summary to improve affordances. I see no problem modifying the browser default appearance; we do this all the time with CSS on links, buttons, inputs and more, all to improve the experience for users, and <details> is no different. It makes sense to me to add the cursor: pointer and make native details consistent across all browsers.

The default <details> on browsers that support it is collapsed; when it is expanded it becomes <details open>. The only potential problem I see here (from an extremely quick review of a jsbin test) is that with javascript turned off on a browser that doesnt support the details tag, it is just rendered as a paragraph or div or something, so no collapsing. This could present issues for people that need to style things based on whether something is collapsed or expanded. Any CSS styles that target the default details { /*presume collapsed */ } will be wrongly styled, and the details[open] { /*style expanded */ } would never be triggered.

The issue boils down to whether Drupal 8 still claim to "work" with javascript disabled?

@jwilson We can build the CSS up from the expanded state, like so:

details {
  /* expanded styles */
}

/* Assume the polyfill adds the 'collapsed' class */
details:not([open]),
details.collapsed {
  /* collapsed styles */
}

In browsers that don't understand <details>, with JS off, this should still work. I’m pretty sure this is how it’s done in core ATM.

Updated issue summary.

I'm not sure if this can be solved with the polyfill that will be created, but states.js also has a regression for browsers that support the details element.

I found this when I was updating the testswarm module:

$form['details2'] = array(
    '#type' => 'details',
    '#title' => t('Details2'),
    '#collapsible' => TRUE,
    '#collapsed' => TRUE,
    '#states' => array(
      'expanded' => array(
        ':input[name="expanddetails2"]' => array('value' => 'expand'),
      ),
    ),
  );
  $form['details2']['item'] = array(
    '#type' => 'item',
    '#title' => t('Do you seee me?'),
    '#markup' => t('If you can see me the details is not collapsed!'),
  );
  $form['expanddetails2'] = array(
    '#type' => 'textfield',
    '#title' => t('Change details state'),
    '#description' => t("Type 'expand' to expand Details2."),
  );

In browsers that do not support the details element, typing 'expand' in to the textfield, will expand the "details" element, in browsers that do support the details element, nothing will happen.

EDIT:
Same story for #collapsible => FALSE: Works in browsers that don't support the details element, doesn't work in browsers that do support it.

EDIT:
never mind: #1852104: #type details: Remove #collapsible property

Because everything except chrome.

Because everything except chrome.

Yeah, but #1252178: Add Modernizr to core is in, so we can use if (Modernizr.details) and attach a polyfill to a .no-details class. No? What is our policy on using polyfills?

;)

Nice, but that that important.

s/that that/not that/? :)

There is also this link here that should be considered when we write this polyfill:
http://accessibleculture.org/articles/2012/03/screen-readers-and-details...

^ The author of that post claims that he himself cannot find a use case for having a link nested inside a summary. I would be of a mind to just allow it (since the html5 spec currently does) but not to take any opinion on it, or to go out of our way to write or customize our own polyfill that somehow handles the special case. Basically, take the stance of "you're shooting yourself in the foot if you do this, so if you're sure you want to do that, you can also handle the consequences".

So at most, this concern becomes a candidate documentation issue, something as simple as a note along the lines of:

Though the HTML5 spec allows links inside the <summary> tag, browsers, polyfills, and screen readers don't support this consistently. If you absolutely need to put a link inside a summary tag, follow the recommendations here (insert link from previous comment here).

That sounds very sensible.

Agreed, thanks @jwilson3.

Looking through the list in #17, I found a lot to recommend https://github.com/kapitancho/logifill-details. Since we our Modernizer script already tests for details support, I tweaked Marian's script to use Modernizr, and it's working well supporting a D8 custom template in FireFox, IE 11 and Edge: https://github.com/FatherShawn/logifill-details

I don't think we should always push Drupal to an area that looks like more HTML5 friendly but actually it's not. Drupal is going to be a bigger boat. Details even not supporting by 2 big brother. Firefox is the one we all known they always does good things. But they didn't on the list.
http://caniuse.com/#search=details

1. Do Drupal really needed Details tag? Or Details like features only. If latter, we do it in CORE already.
2. Do Drupal going to support fully Details tag ? Or part of features drupal needed only. If latter, we do it in CORE already.
3. Elevate the lib we going to be picked is really fully support Details. If there's one, let's move on. If no one, I think we should consider what features in Details we really needed for CORE now and do it.

Details was needed for accessibility. That's not the only reason it was done, but fieldsets can't be nested and despite Firefox's failure to get onboard with this, it is the right pattern.

Here's the firefox bug. Would be good for folks here to +1 this getting into this popular browser:
https://bugzilla.mozilla.org/show_bug.cgi?id=591737

Reading that issue, support is already in the firefox codebase, but it's not enabled yet (has to be enabled with a preference explicitly):
https://bugzilla.mozilla.org/show_bug.cgi?id=591737#c265

So potentially not too far off

@mgifford,

Thanks for the info. I'm not familiar with accessibility. But when I working on #2493957: Add back errors support to native HTML5 details tag, I found current CORE (non-patch) provided more info than native Details tag. eg. it added Show/Hide:

   $('<span class="details-summary-prefix visually-hidden"></span>')
        .append(this.$node.attr('open') ? Drupal.t('Hide') : Drupal.t('Show'))

Will screen reader given extra hints on native Details automatically ?

https://html.spec.whatwg.org/multipage/forms.html#the-details-element
Reading this ref, there's 1 thing missing in Drupal:
- a `toggle` event.

I don't see any ref in SPEC but Chrome does it:
- handle SPACE key

Our collapse.js is a Polyfill lib already. We can do it further to move main code out of Drupal.behaviors.

(Noted that: No libs in above list supporting `toggle` event)

Thanks @droplet - I've been looking for time to dig into this and just not finding it.

From what I recall, we did test this behavior to verify that it was read out properly by a screen reader, but don't have the issue handy.

There are other docs on other approaches:
http://html5doctor.com/the-details-and-summary-elements/
https://mathiasbynens.be/notes/html5-details-jquery

I'm not a JS guy, so not sure what our options are. We can also leverage Drupal.announce() to announce this information.

Native support for details-summary in FireFox is slated for v.49 - September 2016: https://bugzilla.mozilla.org/show_bug.cgi?id=591737#c275

Native support for details/summary was indeed turned on by default in Firefox 49, and I've confirmed it works when JS is disabled.

The native Firefox 49 <details> seems to be implemented using ARIA roles, states and properties; just like Chrome/Opera (and Safari? I think it was introduced before the Blink fork).

The native Firefox behaviour matches our own collapse.js:
- The <summary> element has a role=button attribute (and is announced as such).
- When focussed, the summary element responds to enter and spacebar key presses.
- aria-collapsed AND aria-pressed state attributes are present on the element, and are updated when the <details open> state changes.
- The <summary> element has an aria-controls attribute, pointing at the parent <details> element.

This leaves IE and Edge as the only major browsers which don't support <details>. It's currently "under consideration" for Edge, but I don't think we can expect it in any version of IE.

details element is now "in development" for Edge.

Soon it will just be legacy Microsoft & Opera-mini bucking this whole HTML5 fad http://caniuse.com/#feat=details

:)

Something I discovered while working on #3037121: Disclosure triangle is missing in details/summary groups in off-canvas dialog in Firefox. Due to collapse.js using an indifferent-to-font-color .png for the disclosure triangle, there are contrast issues with <details> on dark backgrounds.

This issue is very outdated, and has a lot of points which need to be verified again. I'll go through it in detail later, but here's a quick brain-dump of some things that need to be clarified....

• Other issues have changed the collapse.js code since some of these comments were written. Need to see if they still apply.
• Importantly, we DO use feature detection, via modernizr.
• There are actually TWO polyfills being used by Drupal core:
  • collapse.js is a polyfill for the open/close behaviour from HTML5.1+ recommendation. Modernizr tests the behaviour of the open attribute by looking for a dimension change, IIRC.
  • details-aria.js is a polyfill for the HTML-AAM recomendation (working draft, still). Note this does not involve any feature detection; we apply this in all cases. At the time we added this, NO browsers addressed the accessibilty API semantics. Since then, some of them do. However, it is currently not feasible to do feature detection for the browser's output to the host accessibility APIs. A feature-detection approach may be possible in future, for browsers which support the AOM, which is currently none of them.

From #3037121-10: Disclosure triangle is missing in details/summary groups in off-canvas dialog in Firefox:

It's a failure of 2 WCAG success criterion at level AA:

3.2.4 Consistent Identification - details groups are indicated with a triangle in all Bartik/Seven/Stark pages, but details groups do not have a triangle in the off-canvas dialog. This applies to IE, Edge, and Firefox.
1.4.11 Non-text Contrast - you can't see the triangle due to poor contrast. This applies to IE and Edge.
Another WCAG criterion worth mentioning is "1.3.1 Info and Relationships". It requires that information conveyed visually is also conveyed programmatically. The missing triangle bug is essentially the opposite of that - screen reader users are told about the collapsible behaviour, but sighted users aren't. This isn't technically a failure of this criterion (because of the WCAG wording) but it is a similar level of impact IMO.

Not sure if we can close this quite yet, but I just opened up #3272425: Remove Details Aria Polyfill for Drupal 10 to remove all of this stuff.

Collapse.js was removed in Drupal 10 #3269082: Remove HTML5 details collapse polyfill, so this is only relevant to Drupal 9.

Technically this is a valid issue until Drupal 9 hits EOL 6 months from now in November 2023, although I have my doubuts keeping it open will result in much. It would mean devoting energy towards finding a better alternative for a not-ideal-but-toally-fine polyfill that only impacts IE11 users... for a version that will be EOL in half a year.

But perhaps my outlook will inspire some heroism.

Drupal 9 is EOL and all supported browsers support the details element natively now.