Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check the plugin size #202

Open
fredck opened this issue May 24, 2016 · 4 comments
Open

Check the plugin size #202

fredck opened this issue May 24, 2016 · 4 comments

Comments

@fredck
Copy link
Contributor

fredck commented May 24, 2016

I've just made two builds in the online builder, one with A11y Checker and another without it. The following is the size of ckeditor.js in both cases:

  • Without A11y Checker: 518 KB
  • With A11y Checker: 701 KB (+193 KB)

In theory, QUAIL and tests should be loaded on demand when clicking on the A11y Checker button. Therefore, almost 200 KB on the plugin size seems to be a bit too excessive. It should be checked what is ending up in the plugin file and if the loading on demand mechanism is working properly.

@mlewand
Copy link
Contributor

mlewand commented May 24, 2016

Yea, I can see Quail is inlined. Without Quail built plugin.js is 43KB compared to 175KB when Quail is added.

@mlewand mlewand added this to the 1.0.1 milestone May 24, 2016
@wimleers
Copy link

wimleers commented Jun 1, 2016

As https://www.drupal.org/node/2731373#comment-11243745 explains, we'd love to include the a11ychecker plugin, but we'd need quail to be loaded separately.

So, when you implement this on-demand loading, can you please also make it possible to let the site specify the location of the quail library? Otherwise sites that have other uses for quail will need to ship it twice: once as part of a11ychecker, once independently.

@mlewand
Copy link
Contributor

mlewand commented Jun 2, 2016

So, when you implement this on-demand loading, can you please also make it possible to let the site specify the location of the quail library?

Yes, it makes a perfect sense. We were thinking about this at the beginning, but for some reason this has slipped out. I've extracted this request to #204.

@mgifford
Copy link

Looking forward to this! So good to be able to bring accessibility right to the content editors. Big step towards ATAG 2.0 compliance too.

@f1ames f1ames modified the milestones: 1.0.1, 1.1.1 Nov 17, 2016
@mlewand mlewand modified the milestones: 1.1.1, 1.1.2 Mar 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants