GitHub HTML preview fails with rmarkdown (ioslides)

From time to time, I make workshops and I have been using rmarkdown to create ioslides presentations. The generated HTML files, I have then put on GitHub and prepended

to e.g.

resulting in the link

Where the participants could then view the slides directly and easily in their browser. In the past this has worked very nicely, but alas no longer, which is quite frustrating.

Has anybody experienced this and fixed it I wonder?


Anyone has an idea of what is going on?

The html preview page is running properly in general - you can see it if you try f.e. this link:

What it does is: load HTML using CORS proxy, then process all links, frames, scripts and styles, and load each of them using CORS proxy, so they can be displayed by the browser.
So it seems something in your html-file avoids the preview running as expected. As I've opened the raw-html in github the most html was somehow encrypted...

Can you see the rendered html-page in case you're running the html locally after it was produced (before uploaded to github)?

The weird thing is, that this used to work and now it does not anymore.

I'm using ioslides to create a presentation with HTML output, which I then link to in the github-repo.

The HTML file looks just fine, if I download it and view it using e.g. Chrome.


I've just checked the http-header and found 2 404 errors - one of it could explain the empty page (the first 404 below). Do you understanding why your HTML was sending a request onto atarget which is not existing? Did you've changed anything?

That's what I did
Sent a http-request to the URL and measure what happens from sending the request until receiving the result.

That's what I've found
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

GET: HTTP/2.0 404 Not Found
date: Mon, 26 Aug 2019 16:40:54 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d19f370fe7519b1a498c156c32b5fc6b31566837654; expires=Tue, 25-Aug-20 16:40:54 GMT; path=/;; HttpOnly; Secure
cache-control: no-cache, no-store
expect-ct: max-age=604800, report-uri=""
server: cloudflare
cf-ray: 50c7400bfe00d6e9-FRA
content-encoding: br
X-Firefox-Spdy: h2
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: image/webp,*/*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

GET: HTTP/1.1 404 Not Found
Content-Type: text/html; charset=utf-8
ETag: W/"5c1d106f-247b"
Access-Control-Allow-Origin: *
Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; img-src data:; connect-src 'self'
Content-Encoding: gzip
X-Proxy-Cache: MISS
X-GitHub-Request-Id: 1AC2:62C2:7A058A:A906E1:5D64018F
Content-Length: 5232
Accept-Ranges: bytes
Date: Mon, 26 Aug 2019 16:40:54 GMT
Via: 1.1 varnish
Age: 2567
Connection: keep-alive
X-Served-By: cache-hhn4073-HHN
X-Cache: HIT
X-Cache-Hits: 1
X-Timer: S1566837654.294923,VS0,VE0
Vary: Accept-Encoding
X-Fastly-Request-ID: 2c0042552a9e66ba8cb42d55711045d285f90626

I'm having the exact same problem as OP. Did you ever get it resolved?

I figured it out with some help from a friend. If you create a branch of your repository called gh-pages, you can link to those versions. For example, here's my original repository:

I created a branch called gh-pages which automatically populates

Then I can link to and it works just fine.

If you're working on your master branch you just need to merge it into gh-pages every once in a while to keep it up to date.

Hope that helps!

@Leon maybe this issue is related to your issue :thinking:

Might be @cderv... I tested using Chrome, Safari and Firefox, but none do the trick.

Politely summoning @yihui, is the broken rendering of ioslides in GitHub using a known rmarkdown issue?

E.g. no longer works

You should looked into rmarkdown issues and try to come with a reproducible example to open a new issue if you found the problem reproducible.

Following the hint of the issue I linked , can you try an earlier version of pandoc to see if that is not the culprit ? It could be a pandoc issue related to self contained document.

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.