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

Add browser JS capability test #302

Open
macburgee1 opened this issue Oct 23, 2019 · 3 comments
Open

Add browser JS capability test #302

macburgee1 opened this issue Oct 23, 2019 · 3 comments
Assignees
Labels

Comments

@macburgee1
Copy link
Contributor

We want to test two for scenarios:

  1. Is Javascript enabled for the browser
  2. If yes, does the browser support ES6.

This JS code will be included inline near the top of <HEAD>. It will enable themes to react to serve JS files accordingly. It will also be used to support CSS in situations where CSS needs to know if JS is enabled or not.

Consider calling this "DCF init" as other tests may be added in the future.

@macburgee1
Copy link
Contributor Author

We should consider adding testing for WebP support.

@skoolbus39 skoolbus39 mentioned this issue Oct 24, 2019
@skoolbus39
Copy link
Member

We should also include the object-fit-images polyfill in this test.

@macburgee1
Copy link
Contributor Author

In discussion with @skoolbus39, we identified an issue that will need resolved in conjunction with this task. Primarily, should the proposed JS code be 1) included inline in a template file or 2) loaded as a separate file, blocking file?

The issue with placing this JS code in a template is that our template file is only a suggestion for themers and application developers to follow and reference. Their CMS or application will have its own template system. As a result, we won't be able to deploy updates to the proposed JS directly. We'll have to document in release notes and rely on themers and application developers to update their template file(s).

Alternatively, we could put the proposed JS in a file (e.g. dcf-init.js), which is called early and blocks other JS. The benefit here is that when we want to change the proposed JS, the updated code is deployed when the themer or application developer updates DCF core in their node.js project. No template changes are required.

We'll want to consider the technical and performance implications of each option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants