Why not Swap IFRAME for DIV?

stopbit's picture

Hi,

I've been thinking about this since I first discovered H5P.

"Why is it that H5P relies entirely on iframes to show content" - This appears to be true on Wordpress, Drupal and Moodle.

Now, if you're a developer or familar with SEO or indeed any web work, I'm sure I don't have to explain the inherent negatives associated with the use of iframes these days. To name just one issue - Google (and other search engines) will not crawl iframe content if embedded on a page - that's not so nice.... and sometimes iframes are hard to work with in other ways too.

Is it therefore feasible to change the way the content is called for, so it is not using an iframe?

If so, why are we using iframes, what's the benefit over using a DIV for example? I'm guessing using iframes made it easier to develop in the first place when the technology was first emerging.

So today, can we replace iframes with a more modern alternative to display the content? I think so, it's probably not that difficult. This statement alone is probably not true however. Some things are easy to say in words, but very hard to acheive in code.

And so where are we at with iframes? Is there change on the horizon I wonder....

I hope someone from the H5P team can shed some light on the use of iframes and if we'll see H5P without barriers soon ;-)

Thanks

Summary: 
Swap iframe for div when displaying content
fnoks's picture

Hi,

H5P supports two insertion modes, div and iframe, but most of the content types use iframe. The main reason for that is the way CSS works. 

When H5P inserted as DIV, all other CSS on the page may potentially affect the behavior & look of the H5P, we've seen a lot of examples of this. Unfortunately, there is no way to stop the cascading at a certain DOM element, and therefore a CSS selector with a higher weight/specificity will override H5Ps CSS. Other JavaScript on the page may also conflict with H5P.

Iframes, on the other hand, is not affected by the CSS or JavaScript in the main/parent page, but have some other drawbacks:

  • An iframe has a static size and is not able to resize itself. This is solved in H5P by triggering an event to the parent page each time size is changed.
  • Communication between iframe and parent is not as straight forward. This is solved using postMessage().

In the future, when all the relevant browsers support Web Components (especially Shadow DOM), I think we can move away from using iframes.

PS: Google does index the content of iframes. Try this search.

Best,
Pål

 

Hi,

I have noticed in recent weeks that using iFrames to integrate exernal web pages within our Canvas VLE, no longer display content in Google or Firefox browsers. It appears this has to do with something called x-Frame options policy, designed to combat something else called click-jacking. As this appears to only have manefested within the last month or so, have you encountered this? If so, does the H5P iFrame embedder take this into account?

otacke's picture

Hi H5Pman!

The X-Frame-Options allow site owners to control where their content is allowed to be embedded to using iframes. If the site owner doesn't allow embedding to other sites (or your site in particular), there's nothing you or H5P (iframe embedder) can do.

Best,

Oliver 

Thankyou for your response Oliver, we learn new things every day!

otacke's picture

I hope so! If I don't learn something new a day, I call it a bad day.

Further to the X-frames debacle, I recived a comment back from the Instructure community. 

"This seems like it's the 3rd party site (unifrog) that's setting the x-frame response header so it's not something that is changeable by Canvas's codebase. Probably for good reasons like the ones you describe. If they have any desire to have their content be embedded within pages hosted by major LMS providers like Instructure, they should probably establish an LTI deep-link embed option. "

 

So the suggestion is a systemic moving away from iframe embedding to an Lti solution for the sake of safety. This points, furthermore, to the days of the H5P iframe embedder, as a viable solution for displaying third party web content, being numbered. I would be interested to read your thoughts on that?

stopbit's picture

Hi Pål,

Thank you for the great explanation, this is exactly what I wanted to know.

If CSS is the primary issue, which I can understand a fix could be to explicitly provide CSS for all types i.e. h1-6, p, span, div, etc. But I can see this is also quite the task and not without conflicts as you describe.

You say there are two insertion methods - DIV & iframe, can you outline / list which content types use DIV and which use iframes. Obviously the 'Course Presentation' activity uses iframes and I've found that 'Question Set' uses iframes too, but what about the other content types?

Google and iframes

For the most part when researching iframes + google I see lots of discouragement from using iframes. I understand that some pages do appear to be getting picked up. Perhaps this is because the page contents was indexed a long time ago, before google modified their algorithm (they've been busy recently!). I really do hope all iframes are indexed and crawled by google, it's pointless in my mind to not do so.

Iframes and google may be a little contentious right now, although for me, questions within a 'question set' are not being indexed by, however other details (any phrase) outside the iframe area on a page are all being picked up. This being said I'm only using a few pages  with H5P content and I was hoping to embark on including a lot more H5P contents.

I've been testing and monitoring these pages which include H5Ps, to see what their impact on serp results, visitor interactions, time on page, etc. So far I'm seeing an increase in time on site and drop in bounce rate.

During writing my response here I've just realised a rather large hickup I've made. When first using H5P I decided to include an url path in robots.txt to disallow google from crawling.

The line(s) in my robots.txt was:

User-agent:*
Disallow: /wp-content/uploads/h5p/*

This would mean, for any user agent, disallow url: /wp-content/uploads/h5p/ recursively.

Looking at the question set iframe I see this url is used in three places for my site:

  • <link rel="stylesheet" href="/wp-content/uploads/h5p/cachedassets/7ac68a2151643bd882a03c53ae3b0eb1fe9038ce.css">
  • <link rel="stylesheet" href="/wp-content/uploads/h5p/css/h5p-custom.css?ver=1.3.7">
  • script src="/wp-content/uploads/h5p/cachedassets/7ac68a2151643bd882a03c53ae3b0eb1fe9038ce.js"></script>

That would probably explain the crawl/index issue with google and other search engines in my case.

I'm glad I posted this question, otherwise it would have taken me longer to remember about the robots.txt I changed back in 2015.

Again thank you for the explanation and I hope we see a gradual progression towards swapping iframes for divs in the future.

 

fnoks's picture

Hi,

Regarding which content types are using DIV/IFRAME, I don't have a list. This is set in each content type's library.json, using the embedTypes property. If this property is not set, it defaults to DIV. Source code for all content types are available on github, here's an example from Course Presentation: github.com/h5p/h5p-course-presentation/blob/master/library.json#L10

stopbit's picture

Thanks for the info.

Please find a list (image attached), which I hope assists with identifying which activities use iframes and which use divs to embed content.

I got this list using a linux grep command and then comparing this to the list of activites on the H5P site.

I have included the path to the latest libraries for each activity type which uses iframes to embed content.