Tracking issue for RFC 1985: Tiered browser support

[aturon]

RFC

• Document our tiered browser support policy as agreed upon in the RFC
  • In the forge - should "browser support" get a different page or should it be added to the platform support page?
  • In crates.io/cargo's docs (faq? policies? contributing.md? all of the above? somewhere else?)
  • Somewhere for rustdoc (this is sort of in flux right now)
  • rust-lang.org's README
  • blog.rust-lang.org's README
  • the playground's README (this is sort of in flux right now)
  • thanks.rust-lang.org's README
• Should we add a note about this to these repos' issue templates?
• Add automated testing using BrowserStack to start testing some functionality in each of the the supported browsers. The following sites are complex enough that they deserve testing IMO, the rest are mostly static content and we can rely on bug reports:
  • For crates.io
  • For rustdoc
  • For the playground
• Close any issues in repos that only apply to browsers that we've decided are unsupported

[aturon]

I'm not entirely sure what the implementation steps are here -- certainly, they involve some documentation. @carols10cents, can you comment further?

[carols10cents]

I've added a bunch of tasks-- it's mostly documentation, testing, and issue cleanup :)

[Boscop]

The search in Rust docs is not working in IE11. Entering a query and hitting Enter does nothing, it shows no search results etc. which makes the navigation difficult.

IE11 is still used in many educational institutions around the world (and often the only installed browser) and since Rust is striving for accessibility and inclusiveness, the search functionality should also work in IE11.

EDIT: Btw, crates.io only shows a totally green page (only the background), no UI elements in IE11.

[QuietMisdreavus]

The error i get when running the nightly docs in the IE11 debugger is

Object doesn't support property or method 'startsWith'

According to MDN it's possible to create a stopgap implementation for browsers without the String.prototype methods, which might help out. I'm not sure how many other things the search functionality requires that IE11 doesn't have, though.

cc @GuillaumeGomez

[steveklabnik]

@Boscop this policy doesn't mean that we will not accept PRs to make things compatible; it's a statement about what we have the time, energy, and power to support as a project. In general, we're quite happy to merge things for broader compatibility, but it's up to the people who care about those platforms to help out. This is similar to the tier system for platform support generally.

[GuillaumeGomez]

Damn, I'll need to grab a windows...

[QuietMisdreavus]

For those without an installation of Internet Explorer available, Microsoft makes virtual machine images available with various versions of IE and Edge, for browser testing.

[apiraino]

Visited during T-compiler cleanup of open tracking issues (on Zulip).

We think that this now can be closed, we never really needed something like that, all of our websites need only basic features like HTML5+CSS and a sprinkle of JS where necessary - and we like to keep it like that.

[carols10cents]

Visited during T-compiler cleanup of open tracking issues (on Zulip).

We think that this now can be closed, we never really needed something like that, all of our websites need only basic features like HTML5+CSS and a sprinkle of JS where necessary - and we like to keep it like that.

Just for historical documentation, crates.io was the main driver of this RFC and definitely needed a browser support policy.

I agree with the closing of this issue though; we have had our browser support codified for quite some time so this issue is moot.

Although I see now the playground is mentioned, and that also might be relevant -- @shepmaster has the playground documented its supported browsers?

[shepmaster]

has the playground documented its supported browsers?

Not in a public fashion, but we make use of a .browserslistrc that follows / links to this RFC.