Peter Bengtsson

@a2sheppy My example is interesting in that it *produces* `` HTML in the final (MDN) product (a.k.a. the rendered HTML). Also, if you, independent of philosophy and strategy, you *can*...

...if there are more specific problems later where neither of the above mentioned ideas work, then we can file up a new specific issue.

:+1: on having to log in each time instead of using a nasty plain text cookie.

> But how do you mean to provide the assets to stumptown consumers? Stumptown-rendered gets the stumptown content via a git submodule. Then we execute that thing in stumptown-content that...

By the way, Lighthouse demonstrates an opportunity to post-process the images a bit better:

Mind you, it might be dangerous to assume that JPEG is the better format just because it becomes smaller. What if the page is about rendering PNGs or something?? And...

Gotcha! And I don't have an answer. But it's not unrealistic to include assets in an npm package or for a consumer to look them up via git raw usercontent....

Note-to-self; if we do decide to include images here with the Markdown content, perhaps an app like [ImgBot](https://github.com/marketplace/imgbot) might be a good idea.

I don't think it matters for the mdn scraper script but it might matter on the build-json script once we have loooots of snippets of HTML that needs to be...

Another big difference between the two is that JSDOM is a lot less forgiving than Cheerio. Cheerio uses the htmlparser2 parser which very forgiving. Not sure if that matters until...