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

What does our browser support matrix look like? #1180

Closed
jdlrobson opened this issue Sep 26, 2018 · 10 comments
Closed

What does our browser support matrix look like? #1180

jdlrobson opened this issue Sep 26, 2018 · 10 comments
Assignees
Labels
Needs: Feedback A proposed feature or bug resolution needs community feedback prior to forging ahead. [managed]

Comments

@jdlrobson
Copy link
Collaborator

jdlrobson commented Sep 26, 2018

It's unclear which browsers we need to support.
Ideally, we should base this on data showing what browsers are users are using. Do we have this information?

If not, we should probably follow a browser matrix similar to other projects e.g. MediaWiki

Once defined we can likely through away a lot of CSS code (and maybe JS).

@jdlrobson
Copy link
Collaborator Author

Looks like json2 is probably not needed for example

@jdlrobson
Copy link
Collaborator Author

This may also help #1054.

@jdlrobson
Copy link
Collaborator Author

@mekarpeles any ideas on how to think about this?

@mekarpeles
Copy link
Member

Ideas but will need some time to gather; thx for reminder!

@jdlrobson jdlrobson added question Needs: Feedback A proposed feature or bug resolution needs community feedback prior to forging ahead. [managed] labels Oct 19, 2018
jdlrobson added a commit to jdlrobson/openlibrary that referenced this issue Nov 8, 2018
Most modern browsers have JSON support, so thus do not
run JavaScript on browsers which do not have JSON support.

This begins attempt to define and limit our JavaScript to browsers
we can reliably run JS on.

Fixes: internetarchive#1180
jdlrobson added a commit to jdlrobson/openlibrary that referenced this issue Nov 8, 2018
Most modern browsers have JSON support, so thus do not
run JavaScript on browsers which do not have JSON support.

This begins attempt to define and limit our JavaScript to browsers
we can reliably run JS on.

Fixes: internetarchive#1180
@jdlrobson jdlrobson self-assigned this Dec 30, 2018
@jdlrobson
Copy link
Collaborator Author

jdlrobson commented Dec 30, 2018

@mekarpeles i plan to drop support for any browser with less than 1-5% traffic. Can you get that information?

@shaneriley
Copy link
Contributor

I typically drop browsers with < 2% traffic, but in the case of this project's global scope that may be difficult. I'd be interested to know how many versions back we're seeing used and filtered by country.

@mekarpeles
Copy link
Member

@bfalling or @rchrd2 can one of you please weigh in here re: archive.org's browser support matrix? We'd love to add this to our Open Library wiki. Is this documented somewhere for IA?

@shaneriley
Copy link
Contributor

In scanning through the JS, I noticed an Array.prototype.filter method call, which made me think we're not supporting IE too many versions back. If we are, there's probably a few spots in the JS that need to be downgraded to IE7 style solutions.

@jdlrobson
Copy link
Collaborator Author

In scanning through the JS, I noticed an Array.prototype.filter method call,

Yeh this is one of the reasons why I brought this up. There is modern JS, strict JS, old JS... vendor prefixes galore and even IE5 hacks! Thus knowing this will help drive a bunch of things.

@jdlrobson
Copy link
Collaborator Author

Okay.. I want to make progress on this, so in lieu of traffic information I'm going to propose we follow Wikipedia's browser support matrix: https://www.mediawiki.org/wiki/Compatibility#Modern_(Grade_A)

Patch to follow.

jdlrobson added a commit to jdlrobson/openlibrary that referenced this issue Mar 1, 2019
We will use Wikipedia's browser support matrix as it is based
on traffic for Wikipedia. Given Wikipedia's traffic, I think we
can be confident this will also be suitable for OpenLibrary.

Add a transpiler to allow us to adopt ES6 syntax in the codebase.
The addition of the babel loader and browserslistrc ensures that the
code we ship to end users will always be suitable syntax for those
users. Note we must still be careful when adopting ES6/7/8 functions
as no polyfills are provided, so care must still be taken by frontend
developers working with this codebase. We can add protection via
eslint later if that becomes a problem.

A single variable is changed to a `const` which does not appear
in the built assets in static/build to demonstrate this is working.

note the minor bundlesize update (but remember we just shaved 5kb off!)

Fixes: internetarchive#1180
jdlrobson added a commit to jdlrobson/openlibrary that referenced this issue Mar 20, 2019
We will use Wikipedia's browser support matrix as it is based
on traffic for Wikipedia. Given Wikipedia's traffic, I think we
can be confident this will also be suitable for OpenLibrary.

Add a transpiler to allow us to adopt ES6 syntax in the codebase.
The addition of the babel loader and browserslistrc ensures that the
code we ship to end users will always be suitable syntax for those
users. Note we must still be careful when adopting ES6/7/8 functions
as no polyfills are provided, so care must still be taken by frontend
developers working with this codebase. We can add protection via
eslint later if that becomes a problem.

A single variable is changed to a `const` which does not appear
in the built assets in static/build to demonstrate this is working.

note the minor bundlesize update (but remember we just shaved 5kb off!)

Fixes: internetarchive#1180
Modernizing Open Library's JavaScript automation moved this from In progress to Done Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs: Feedback A proposed feature or bug resolution needs community feedback prior to forging ahead. [managed]
Development

No branches or pull requests

3 participants