Should we support CodePen and JSFiddle buttons for live examples?

[escattone]

cc @chrisdavidmills @peterbe @ddbeck

Live examples on the Wiki pages (e.g., https://wiki.developer.mozilla.org/en-US/docs/Web/CSS/:active) (but not the main site -- https://developer.mozilla.org/en-US/docs/Web/CSS/:active) show Open in CodePen and Open in JSFiddle buttons:

Like https://developer.mozilla.org, we don't support them on our Yari pages:

Should we? I can't remember if this was a deliberate product decision or something we missed on https://developer.mozilla.org.

[chrisdavidmills]

I don't really remember the history of these buttons; they've been around for as long as I can remember. I've certainly never used one, and I don't know if our users use them much? I wonder if we are able to get any telemetry on this?

The only time I've ever had any interaction with them is when hacking the macro call to turn them off, because certain examples don't work with them very well.

[peterbe]

We actually do keep analytics on those button clicks.
See https://github.com/mdn/kuma/blob/ab5e687f2df75e6466c32068a686158a2dfe37a1/kuma/javascript/src/live-examples.js#L119-L123 for the Codepen button.

If this link works you'll see that in the past ~30 days there has been:

• 36,704 clicks on open-codepen
• 10,032 clicks on open-jsfiddle

Combined, let's say that's 40k. In the same window of time, we've had 42M pageviews. So that's 0.1% of pageviews leads to a click on one of those buttons.

[peterbe]

Here's the code that injects the buttons: https://github.com/mdn/kuma/blob/master/kuma/javascript/src/live-examples.js

[peterbe]

But wait a minute! It's supposed to work on the read-only site.
You might have found a URL where it's breaking.

On the read-only site we have this code: https://github.com/mdn/kuma/blob/ab5e687f2df75e6466c32068a686158a2dfe37a1/kuma/javascript/src/article.jsx#L70-L80
And as you can see, that code is wrapped with a piece code that sends an event to GA if it fails for any reason.
You can see it here: https://analytics.google.com/analytics/web/#/report/content-event-events/a36116321w64965862p66726481/explorer-table.plotKeys=%5B%5D&_r.drilldown=analytics.eventCategory:article-effect-error
It has triggered ~19k in the last month.
So it's definitely a bug that https://developer.mozilla.org/en-US/docs/Web/CSS/:active doesn't have the buttons.
But that code that sends the error to GA, if it fails to inject the buttons, also does a console.error(error) but I don't see that when I view that page. In either Chrome or in Firefox.
What's going on!?

[peterbe]

Oh. I can totally reproduce the bug now. On http://localhost.org:8000/en-US/docs/Web/HTML/Element/progress
There is no JS error thrown. It's finding the section alright.
The reasons it's failing is that it's looking for a section.querySelectorAll('pre[class*=html]') (same for =css and =js) but that's never a thing because section is a <h2> element and that will not have the <pre> tag in it.
I.e.

<h2 id="Examples">Examples</h2>
<pre class="brush: html">...</pre>

and the code does the equivalent of this pseudo code:

var section = document.getElementById('#Examples')
var htmlCode = section.querySelectorAll('pre[class*=html]')
if (htmlCode) {
  ...proceed to inject the Codepen button...
}

In other words, I don't think this has worked for ages.
That 0.1% of pageviews that lead to a click on either of these buttons must be entirely traffic over on wiki.developer.mozilla.org where JS code works.

[peterbe]

1. Let's not fix the Kuma read-only site code. Just because of reasons. Good reasons.
2. Remarkably few users have brought this to our attention. Amirait?
3. Irrespective of the past, is this a feature something web developers consuming MDN are genuinely enjoying?
4. Depending on point 3, I don't think it would be that hard to add this into Yari.
5. Irrespective of the past, what is the ideal thing we can do for people who read the code samples?

[Ryuno-Ki]

For 3: Do you track interaction with Mozilla Demos?
For 5: I can see people putting CodePen on their blogs (Medium, dev.to, I think even on Google's web docs).

It allows to explore a new API right away.
That being said, I dislike the feature (personally). You are basically depend on another provider to guarantee a (core?) feature of MDN. I assume, there's no SLA in place. If you would „fix” it, could CodePen handle 42m visitors?

The alternative could be a link out to CodePen / JSFiddle / other interactive REPLs.

[ghost]

Regarding this I have nothing against CodePen and the possibility to edit the code but I would really like to see them in a new card without frames as editor made them

[Ryuno-Ki]

Since it bit me a few times in recent days …
How do you guard against link rot?
That is, CodePen/JSFiddle demos, that get deleted.

[chrisdavidmills]

@Ryuno-Ki these buttons take the live examples and dynamically inject them into anonymous CodePen/JSFiddle instances, so that's not a problem. We don't maintain those separately.

[ghost]

I like a lot as a developer what GitHub's RAW button is. I don't like BLAME instead, it creates too many assumptions.

---

In view of receiving credit as a developer having commits on GitHub, I would prefer, if I were to modify those codes, to do it directly in a PR and not on CodePen which does not give me credit.

[schalkneethling]

@escattone @chrisdavidmills Have we reached a decision on this one? I guess we still do not support them and we have not had any issues asking about them so, perhaps we can just close this one?

[chrisdavidmills]

@schalkneethling I think we can close this, yes.