All of GitHub's menus & dialogs work without JavaScript. The brilliant @muanchiou figured out that `<details>` elements could make popover menus work without JS github.com/muan/details-o…! We've got open source helpers too: github.com/github/details… github.com/github/details…

Why is “without JavaScript” even a goal though? Is this like demoscene? Neat because of challenge but not of practical import? (Yes, I think so).

It’s a goal because it means we get to ship less bytes to the browser by relying on native functionality. It’s a goal because it goes a long way for accessibility gains. It’s a goal because it means we can aggressively drop older browsers while still retaining good functionality

Fewer bytes is the only one of those that is remotely valid. And with minification/ compression/ code splitting, I seriously doubt it matters. Accessibility should be solved once for all (if Google can crawl JS, then it’s possible). JS does not prevent aggressive deprecation.

Serving JS (that works) to older browsers is maintenance overhead that we can forgo by using progressive enhancement (of which this is part of). WRT accessibility being solved, “should” and “is” are two very different things.

Sorry, not trying to be difficult here, just curious; you mentioned older browsers, but <detail> isn't supported by IE, I thought? How does this help there?

Great question! We serve a handful of polyfills to older browsers to ensure stuff like <details> works. Dropping IE from our main scripts allows us to ship things like native async/await to other browsers.

Gotcha, thanks!

Wow, that's incredible. Github making sure to not compromise on accessibility is seriously impressive.

We’re not trying to enforce things here btw. We’re just saying “hey, this solved us time and effort. Here’s our research if you think it would help, cool!” If you don’t think this will help you, well, that’s cool too.

Yea, don’t get me wrong. It’s definitely cool. Certainly in the demoscene sense and perhaps there’s some practical situations where it makes sense. I’m just not convinced those are widespread.

Couple of points to consider here: • Slower devices with slower CPU’s take longer to parse/compile/execute every byte of script. This is by far the largest reason the web is slow. • Accessibility in JS is a job to be done, and is most often not.

Re: if Google can crawl JS, then it’s possible It's a common misconception that assistive technologies do not process JS, when in fact they will notice changes in the DOM. The gains for accessibility are that `details` handles many of the roles you'd need to implement yourself

Also, resilience to JS going down *is* accessibility as well :) Between connection flakiness and other conditions, it is bound to happen, and the more resilient, the better!

One significant benefit is that you can get the full functionality without waiting on all JS to finish loading, which can be a big deal on slower connections.

js takes much more resources to execute, add all these event listeners and you get a bloat... small things add up

I’ve been working on the biggest news site of Belgium, and you would be surprised what we encountered during test sessions with real users and their own devices. JS not loading (bad connection), malicious plugins in their browsers, .. but our non-js dropdown menu always worked

noting though that without JS, some aspects (like maintaining/cycling keyboard focus inside the dialog) don't work...but still

IE11 / Edge polyfill?

Not to mention all content outside this "modal" is not hidden from assistive technologies. Lack of aria-modal=true or other techniques. Also, role=dialog is not labelled.

(No comment)

This is super cool

I don't understand , Why , "without Javascript" , when in the code need and use Javascript?

Creo que se refiere mas a la falta de JS del lado del cliente.

The code doesn't need JS, though. GitHub (as most apps, IMO), should be built for robustness. When a flaky internet connection causes a JS file to fail, or a coffeeshop's or biz firewall decides to block a particular file as malware, the site should still have base functionality

said better here:

Oh, thanks ... CC: @AlvaroFelipe , esta tecnología es bastante bueno investigarla ..

I'm wondering why this is not used for tooltips or popovers based on styleguide.github.com/primer/

Reading the thread I can see that more than a couple ask “Y THO”. And the real answer here is: Because this is how we, as engineers, push for adoption of new browsers and push the envelope. GitHub doing this is good for all of us engineers. As a whole.

😍

🤯

It's also about robustness. GitHub is mission critical for many businesses, big and small, around the world. The core functionality shouldn't fail when some corporate malware filter decides to block a JS file, or a poor network connection causes that JS file to be interrupted.

Woo html works without js!

Woah

How is this not common knowledge?? IWe've been applying these kinds of simple html/css combo's to create this kind of basic interactions for YEARS! People tend to use JS for a lot these days; even when it's completely unnecessary...

Dumb question ... I get how it opens without JS, but how does it close? Do <details> elements get a :before pseudoelement that can then be styled as the background scrim?

I believe the entire `summary` element is clickable to toggle it open and closed

(that’s not a dumb question at all!)

Ahhh nice, so that entire <summary> element gets styled as the scrim? Briliant! I need to try this out on something I'm making. 😺 (Thanks! It was a dumb question in that, were I sitting at a computer rather than on my phone, I could have inspected it to find out.)

Thinking further, I don't think I said that quite accurately. I'll still have to inspect when I get the chance.

Upon testing this it was a very good question, as closing the dialog does not work when JavaScript is disabled. Wonder if it could be fixed—still a great feature though.

IIRC clicking the "X" doesn't close it but you can click the overlay to close. Overlay is part of "<summary>" element. Not perfect but pretty darn close.

Wow, awesome! So maybe just remove that X until JS loads 👍🏻

Good idea! Another idea is to make the whole header dismissible by adding something like `margin-top:-40px; pointer-events:none`

I think that’t pretty damn perfect for what it does in relation to what it costs.

At least in the "Clone or Download" button, the <summary> element gets a full-screen :before pseudoelement that makes clicking in the background close the rest of the <details>. I didn't try without JS, though.

at a glance I thought of context menus and got curious, though js-less modals sound good too! thanks for sharing

This is awesome!!! Thanks for pushing the envelope!

*sighs* caniuse.com/#search=details

Polyfills exist for it!

How’s this for a11y?

#Accessibility support for <summary> and <details> is not bad - just a couple of gotchas, with bugs raised. See hassellinclusion.com/blog/accessibl…

#FFingOut #GoldDust

I think it’s fun to try and do things without JavaScript.

Loving <details> we just need @Microsoft to pull their finger out.