Do we need {{EmbedGHLiveSample}} macro now that we have playable {{EmbedLiveSample}} macro?

[OnkarRuikar]

The {{EmbedGHLiveSample}} macro embeds interactive demos from https://mdn.github.io website using <iframe> tag. E.g. Playing with box model demo.

Now the other macro {{EmbedLiveSample}} has been made playable it is way better than the EmbedGHLiveSample. E.g. Box shadow example.

The EmbedGHLiveSample requires to create example in other repos. So it is hard to implement and maintain such content. On the other hand the EmbedLiveSample macro is more versatile and more prevalent.

My questions are:

1. Should we explicitly deprecate EmbedGHLiveSample macro in yari?
2. Can we make sure in reviews that while adding new live samples, in learn pages, stop using EmbedGHLiveSample macro?
3. For simple examples, can we make a community project on GitHub to start migrating examples to EmbedLiveSample? This will help in other aspect that we've been eyeing on merging examples repos in mdn/content repo since long time.

[Rumyra]

Hey @OnkarRuikar I'm pretty much on board with this, however I think we'll find some examples that are going to be hard to migrate to EmbedLiveSample at this time due to the nature of some of the larger ones held in other repos.

The long term goal would be to find a way to do this, but initially point 3. is a big yes - if we could move anything that can be moved to EmbedLiveSample I think we should 👍 (and not just from a technical stand point - that it makes sense for the content as well)

[wbamberg]

Although they have drawbacks, there are various reasons people have opted to use EmbedGHLiveSample over the years.

• some examples didn't/don't work with the in-page system, due to things like CSPs. Some of these issues have been fixed but there might be some more left.
• the Learn area, especially the CSS bits, implements its own editable playground thing in pages like https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Grid_skills, and uses EmbedGHLiveSample to be able to share the editor code so it's not duplicated in 50 different content pages. I'm not saying this is a good situation, but it is a situation that would need to be addressed (there are also other interactive editors in Learn that don't use GHLiveSample, and embed the editor code in the page, and they are a total nightmare to maintain/update)
• for examples that are long and complex, where we don't by default want to show the code in the page, it's nice to be able to show the result of the code, without showing the code in the page, but also make the code available to browse if people want to look at it. I don't think massive code listings in MDN content pages is a great UX, GitHub is a better code browser than MDN.
• for examples that are long and complex, it's easier to develop/maintain/debug them as GitHub pages than inside MDN content pages. This is less of an issue since the Wiki went away and MDN migrated to Markdown, but still an issue.
• people want to share an example across multiple pages, or make it a standalone demo.

Should we explicitly deprecate EmbedGHLiveSample macro in yari?

I agree that EmbedLiveSample should be the default tool people reach for in most cases, but at the moment, there are a few reasons people might want to use EmbedGHLiveSample. So it seems premature to deprecate it.

Can we make sure in reviews that while adding new live samples, in learn pages, stop using EmbedGHLiveSample macro?

Are there lots of cases where people add new GHLiveSamples that could easily have been LiveSamples? I mean, is this a real problem?

For simple examples, can we make a community project on GitHub to start migrating examples to EmbedLiveSample? This will help in other aspect that we've been eyeing on merging examples repos in mdn/content repo since long time.

If there are examples that would fit better as live samples, moving them seems fine. But it's a project to assess which ones they are.

[OnkarRuikar]

some examples didn't/don't work with the in-page system, due to things like CSPs.

Technically both the macro outputs are rendered in <iframe> so they should be interchangeable. We'll get to know specific ones once we start moving GH code to inline.

EmbedGHLiveSample to be able to share the editor code so it's not duplicated in 50

Yes EmbedGHLiveSample does avoid some duplication.

for examples that are long and complex, where we don't by default want to show the code in the page, it's nice to be able to show the result of the code, without showing the code in the page, but also make the code available to browse if people want to look at it.

We do have ```html hidden to hide boilerplate code. And the code is visible if you click on 'play' button and enter playground.

for examples that are long and complex, it's easier to develop/maintain/debug them as GitHub pages than inside MDN content pages. This is less of an issue since the Wiki went away and MDN migrated to Markdown, but still an issue.

If we strip playground infra code from EmbedGHLiveSamples then most of the samples will become super short. For example we repeat code in playable and editable tags.

people want ... or make it a standalone demo

We are not getting rid of mdn/xxx-examples repos. Only the live GH macro.

Are there lots of cases where people add new GHLiveSamples that could easily have been LiveSamples? I mean, is this a real problem?

While editing learn pages people, looking at reset of the page, mostly opt for GHLiveSamples. I am asking to change the practice like I've done here: mdn/content#33998

If there are examples that would fit better as live samples, moving them seems fine. But it's a project to assess which ones they are.

We don't necessarily have to asses everything before hand. We could simply ask people if it works with EmbedLiveSample then only move. And they need to make sure there isn't any PR moving the same example. A spreadsheet could be maintained to record troublesome cases.