5 thoughts on “Introducing iframe elements on v2

  1. @heruan v2 is adding an iframe. The reason an iframe is added is to detect when the canvas container resizes. There is a window resize event, which was used by v1, but it only detects when the entire window resized and not a specific element. This led to the problems of charts not displaying correctly when their container was initially display: none; and then displayed (See #762 ).

    I investigated a number of solutions for implementing better resize behaviour. Almost all of the available solutions use some combination of a timer / requestAnimationFrame. Unfortunately, this is bad for mobile battery life since we have to poll the size of the container continuously and check for a change.

    The iframe solution works because it is set to be the same size as the canvas container node. Since the iframe is a window, the window resize event can be listened to and then passed up out of the iframe to the chart to tell it when the container node resized.

    There is some other discussion on this topic in #2024

  2. Just to add my $0.02 on this: The hidden iframe causes some issues for me when integrating Chart.js v2 into my Echo 3-based client-side application. Specifically, the insertion of the hidden iframe just before my canvas node prevents the canvas element from rendering properly (its height and width are left unset). My workaround is to disable resize listening:

    Chart.defaults.global.responsive = false;
  3. I’m traveling right now; but will look at my laptop next time i get a
    chance. I ran across this while putting together an accessibility report.
    There may have been specific context or tooling involved.

    On Sep 4, 2016 11:42 AM, “Simon Brunel” notifications@github.com wrote:

    I can’t reproduce the accessibility issue, maybe it needs some specific
    context:

    [image: image]
    https://cloud.githubusercontent.com/assets/3874900/18233169/013d46e0-72e0-11e6-96f5-7f409afb57c9.png


    You are receiving this because you were mentioned.
    Reply to this email directly, view it on GitHub
    #2210 (comment),
    or mute the thread
    https://github.com/notifications/unsubscribe-auth/AFAjfOhMSogtM-r6m-N2eSfe2blmrq3Uks5qmxEVgaJpZM4H-k2J
    .

  4. I’m reopening this since the use of an iframe to get responsiveness is semantically wrong and it’s resulting in more than one side effect. I understand @etimberg reasons, but in my opinion a library well-written like chart.js should respect standards and accessibility and have tricks to enable some extra functionality available as an opt-in (e.g. enabled by an option).

    By default, there should be no wild iframes nor listeners since the developer have many ways to keep track of the canvas size and decide what to do and when.

  5. Agree with you @heruan, but the default behavior can’t be changed because it would break too many projects (at least for version 2.x).

    However, we are working on 2 main changes about chart responsiveness: at very short term (certainly v2.3.1), the iframe will not be injected anymore if responsive: false (not the default config, but will solve your issue). We are also investigating a method to replace the troublesome iframe by a group of div to detected size changes (probably v2.4), so most of issues related to performance, accessibility, standards, ad blockers, etc., because of the iframe, should disappear.

Comments are closed.