Tiered browser support policy for Rust's web content #1985

carols10cents · 2017-04-28T13:04:38Z

GuillaumeGomez · 2017-04-28T13:48:05Z

Seems like it's a bit short. Only newer versions (to put it simply) is a bit unrealistic for a lot of companies, which means we potentially exclude any new project in rust for these companies if they can't have access to documentation.

carols10cents · 2017-04-28T13:52:46Z

Seems like it's a bit short. Only newer versions (to put it simply) is a bit unrealistic for a lot of companies, which means we potentially exclude any new project in rust for these companies if they can't have access to documentation.

Yup, that's the downside. Which is why I think it's interesting that GitHub (who also sells GitHub Enterprise into large companies) only supports the current version of Chrome, Firefox, Safari, and Edge.

GuillaumeGomez · 2017-04-28T14:00:04Z

It's up to debate. I globally agree on the rest, just have a problem on this.

carols10cents · 2017-04-28T14:08:43Z

It's up to debate. I globally agree on the rest, just have a problem on this.

For the purposes of debating in one place (we've been discussing this in IRC), could you post the versions of browsers and which tiers of support that you'd propose that we use instead?

whitequark · 2017-04-28T14:18:07Z

crates.io is also completely unusable without JavaScript, which always struck me as a strange decision.

carols10cents · 2017-04-28T14:21:58Z

crates.io is also completely unusable without JavaScript, which always struck me as a strange decision.

Yup, I mention that under "unresolved questions".

carols10cents · 2017-04-28T17:28:07Z

Hi @kennytm, I see your "confused" reaction, what's confusing?

nagisa · 2017-04-28T19:41:38Z

text/0000-tiered-browser-support.md

+
+[Rust FAQ]: https://www.rust-lang.org/en-US/faq.html
+
+# Drawbacks


Should mention that it is unknown what portion of users are unaccounted for by the tracking we use due to e.g. having disabled javascript, using privacy addons etc.

I do mention that under the analytics section, do you think it should be repeated here?

aturon · 2017-04-29T03:43:38Z

I'm assigning to the core team, since this is a cross-cutting policy issue.

kennytm · 2017-04-29T04:13:18Z

@carols10cents Hi sorry I'm just confused why this even needs to go through the RFC process, seems very bureaucratic for me 😄.

I think making sure it works on the current Chrome (Desktop + Mobile), Firefox, Safari (Desktop + Mobile) and IE 11, and avoid abusing fancy stuff (graceful degradation), should be enough to be portable in most places.

dlight · 2017-04-29T07:24:23Z

Regarding crates.io needing Javascript: I'm uncomfortable with any site that needs Javascript merely to display static data. This also happens with Google Groups and a lot of other sites.

It's okay to require Javascript for user interaction, even though it's preferably to have a fallback like plain HTML forms, if at all possible.

What happened to progressive enhancement?

GuillaumeGomez · 2017-04-29T08:59:49Z

So for the web browser versions I was speaking of, it's as follow:

firefox 24
chrome 30
IE 11

steveklabnik · 2017-04-29T09:12:40Z

@kennytm:

@carols10cents Hi sorry I'm just confused why this even needs to go through the RFC process, seems very bureaucratic for me 😄.

So, stuff like this might not have to, but the RFC process is how we build community consensus; with something that affects everyone broadly like this, it's better safe than sorry, basically.

steveklabnik · 2017-04-29T09:13:52Z

@dlight @whitequark see rust-lang/crates.io#204

bluetech · 2017-04-30T19:21:41Z

A small suggestion: it might be nice to specify the tiers in terms of browserslist queries.

nrc

I think this is great!

nrc · 2017-04-30T23:11:45Z

text/0000-tiered-browser-support.md

+[ESR](https://www.mozilla.org/en-US/firefox/organizations/all/) (Firefox 52
+will also be an ESR but it was just released). Firefox 52 was the current major
+version for most of this past month; I'm guessing the early adopters of 53 and
+54 are likely Mozilla employees.


iirc, Firefox nightly has ~1 million users, so more than just employees, but still kind of a niche interest

nrc · 2017-04-30T23:13:39Z

text/0000-tiered-browser-support.md

+| UC Browser      | 11              | 530      | 1.02          | 77.40        |
+| Chrome          | 58              | 520      | 1.00          | 78.40        |
+| Safari (in-app) | (not set) (ios) | 500      | 0.97          | 79.37        |
+| Firefox         | 54              | 472      | 0.91          | 80.28        |


Perhaps it is worth looking at some more generic measure of market share as well - we want to optimise for the users we want to have, not just the users we already have

Caniuse has global browser usage stats, but I still think there's going to be large differences between the general population and a population of developers. I'm not sure where to find browser stats for developers rather than browser stats for rust developers; I'll do some investigating but if anyone knows of any resources I'd love to hear about them!

nrc · 2017-04-30T23:17:43Z

text/0000-tiered-browser-support.md

+- Safari current stable, one previous minor release, and the current version on
+  iOS
+- UC Browser current stable
+


I think we should include Edge on this list - MS has big market share and we want to expand on Windows. Currently this feels like more of treating windows users second class.

I'd be up for adding Edge to tier 1, especially if we drop the concept of tier 2 entirely.

nrc · 2017-04-30T23:18:34Z

text/0000-tiered-browser-support.md

+- Bug reports for these browsers are left open but given a low priority, and
+  closed if they are still open when a browser is old enough to drop out of
+  this tier.
+- Pull requests to fix functionality for these browsers are accepted.


IMO we should not have this tier - I don't see a meaningful difference between this and tier 9999

If we drop tier 2, I might change the labels to be "Supported browsers" and "Unsupported browsers" then. I'd like to see what people think though, I'd be fine with a simpler policy but I added tier 2 to add some definition around whether we'd accept patches for a particular version or not.

nrc · 2017-04-30T23:19:31Z

text/0000-tiered-browser-support.md

+
+- Follow best practices for accessibilty, fix bug reports from blind users,
+  reach out to blind users in the community about how the accessibility of the
+  web content could be improved.


100 - I think making screen reader support (and other accessibility issues) a tier 1 (or possibly tier 1.5) issue is more important than supporting any particular browser.

nrc · 2017-04-30T23:21:12Z

text/0000-tiered-browser-support.md

+- Follow best practices for colorblindness, such as have information conveyed
+  through color also conveyed through an icon or text.
+- Follow best practices for making content usable from mobile devices with a
+  variety of screen sizes.


This seems like a big thing to me - supporting a browser is one thing, supporting it on every possible form factor is another. We should probably be explicit about this - while I think it is worth making r-l.o and the blog mobile friendly, we shouldn't commit to making rustdoc 100% mobile friendly for now (I'd like this as a goal, but not as a promise right now).

Most of these are goals rather than promises at the moment-- such as automated testing of rustdoc :)

carols10cents · 2017-05-01T15:44:02Z

small suggestion: it might be nice to specify the tiers in terms of browserslist queries.

Neat! I didn't know that existed! I will update soon :)

clarfonthey · 2017-05-02T04:40:22Z

Adding a bit from the original thread about removing the jQuery dependency, which I brought up: my main justification was that jQuery is a very large library that shouldn't be included statically with every generated rustdoc. It's around 2 MiB minimised, and because it's copied every time that rustdoc is rendered, it can potentially take up a lot of space if you have a lot of crates that use it. This is especially important because rustdoc doesn't actually make use of jQuery a lot, and almost all of the stuff in it could be replaced with a modern equivalent (as @GuillaumeGomez did).

I agree that there becomes a point where you have to stop caring about really old implementations (does anyone remember how IE6 couldn't even display transparent PNGs?) but also I think that documentation size should also be taken into account when making decisions on what platforms to support.

Also huge thumbs up to @carols10cents for making this RFC because while I believe that this is a decision that could easily be done without an RFC, I do really appreciate the community discussion. :)

(This isn't actually going against anything said here, I'm just adding my probably-more-than-two-cents)

o01eg · 2017-05-03T12:03:52Z

What about console text-mode browsers like lynx, links?

GuillaumeGomez · 2017-05-04T08:37:58Z

That's not even part of the supported browsers in the RFC.

carols10cents · 2017-05-04T20:14:58Z

What about console text-mode browsers like lynx, links?

That's not even part of the supported browsers in the RFC.

Right, I'm proposing that we don't make an effort to support lynx/links. Do you disagree @o01eg ?

mgattozzi · 2017-05-04T20:39:00Z

I was at RustFest this pass weekend and there was a blind Rust Developer there and he uses lynx/links in order to access many of the sites. I think from an accessibility point of view it might be a good idea to support them, even if it's a bit harder compared to the rest of them.

clarfonthey · 2017-05-05T05:13:49Z

I think that screen reader support is something we should definitely comment on at the very least. Ideally, all of Rust's content would be accessible as possible.

carols10cents · 2017-05-05T15:01:58Z

I was at RustFest this pass weekend and there was a blind Rust Developer there and he uses lynx/links in order to access many of the sites. I think from an accessibility point of view it might be a good idea to support them, even if it's a bit harder compared to the rest of them.

I think that screen reader support is something we should definitely comment on at the very least. Ideally, all of Rust's content would be accessible as possible.

Screen reader support is addressed in the Orthogonal but related non-proposals section of the RFC. TL;DR screen reader support/accessibility is an important thing we should definitely be working on. If lynx/links is one of the ways people do that, we should support those browsers, I didn't know about that and I will edit the RFC to add lynx/links under this section.

carols10cents · 2017-05-06T14:20:31Z

Does anyone have any thoughts on @nrc's suggestion that tier 2 be removed? 👍 / 👎 on this comment if you don't have any thoughts beyond general in favor/not in favor?

wesleywiser · 2017-05-16T20:21:03Z

I agree, the line must be drawn somewhere but I think it would unfortunate for it not to include some version of Internet Explorer. It seems to me that it would be easiest to support IE 11. The linked pull request in this RFC even mentions that IE 11 would support the native browser APIs used.

According to html5test.com, supporting IE 11 doesn't seem much harder to me than supporting the latest version of Safari. Most of the differences seem to me to be things that we don't need. The biggest difference is ES6 support, but we aren't currently using ES6 anyway.

GuillaumeGomez · 2017-05-17T08:11:36Z

Also, we're talking docs rendering in here mainly. We don't need any fancy CSS feature, just a nice rendering, easy to read and interact with. This is why I think we're focusing way too much on too recent web browsers.

carols10cents · 2017-05-17T13:22:35Z

Also, we're talking docs rendering in here mainly.

Actually, I'm trying to talk about testing resources in here mainly.

wesleywiser · 2017-05-17T14:07:00Z

If we don't have the resources to test IE 11, then I can accept that. However, the RFC as currently written goes further than simply stating that unsupported browsers will be untested; it says that any bugs for unsupported browsers will be WONTFIX'd and closed. While it's not explicitly stated, I think a safe assumption is that a PR which introduces known regressions in an unsupported browser will still be accepted. The net result is that our web content will stop working in unsupported browsers very quickly.

I would much prefer something like the original version of this RFC which had different tiers of support:

"Gold" tier browsers
- Modern browsers (the "Supported Browsers" list in this RFC)
- Tested
- Rust's web content is designed for these browsers
"Bronze" tier browsers
- Older browsers
  - IE 11
  - Perhaps older versions of the Android browser?
  - Perhaps lynx?
- Not tested, we rely on bug reports from users
- PRs are not allowed to cause known regressions to these browsers
- Rust's web content should be functional but may have a degraded experience or small visual glitches
Unsupported browsers
- All other browsers
- Bug reports will be closed as WONTFIX
- PRs to fix issues can be accepted provided they don't impose a significant maintenance burden

carols10cents · 2017-05-17T14:39:01Z

I'm interested to hear what the rest of @rust-lang/core thinks; this commit shows the diff of the two versions that have been proposed.

GuillaumeGomez · 2017-05-17T15:04:20Z

Actually, I'm trying to talk about testing resources in here mainly.

That's not as I understood it. :-/

alexcrichton · 2017-05-17T15:37:53Z

I'm personally ok with the RFC as-written, without a second tier of support. Would we still accept PRs to increase compatibility? If we did then I imagine that the process of having and not having a second tier would look very similar, modulo whether bugs are left open.

aturon · 2017-05-17T15:47:10Z

@carols10cents I could go either way on this question, but like @nrc I suspect that in practice they'll work out roughly the same. That is, closing as WONTFIX in this case means we're not committing to fixing the issue, but would be open to a PR that does.

I think I prefer to start with the RFC as it stands now, and see how it shakes out in practice (i.e., how often we see such issues).

I think the most important step here is getting any testing and assurance. I think that alone is going to make our web presence of higher quality across the board.

steveklabnik · 2017-05-17T16:17:52Z

@carols10cents I could go either way on this question, but like @nrc I suspect that in practice they'll work out roughly the same. That is, closing as WONTFIX in this case means we're not committing to fixing the issue, but would be open to a PR that does.

Seconded.

I think the most important step here is getting any testing and assurance. I think that alone is going to make our web presence of higher quality across the board.

Yup, exactly: we can always add more support later. I think of this RFC as being going from nothing to something at all, not "what is the perfect set of things to test." If it turns out a lot of people need something we don't support, it's easy enough to modify the guarantees later, and by the same token, I'm sure we'll eventually drop support for browsers after a few years.

carols10cents · 2017-05-17T19:09:49Z

@GuillaumeGomez

Actually, I'm trying to talk about testing resources in here mainly.

That's not as I understood it. :-/

Can you suggest improvements to the summary to make it clearer?

carols10cents · 2017-05-17T19:10:47Z

@alexcrichton

Would we still accept PRs to increase compatibility? If we did then I imagine that the process of having and not having a second tier would look very similar, modulo whether bugs are left open.

It would depend on the complexity/maintenance burden of what the PRs were adding :-/

GuillaumeGomez · 2017-05-17T19:44:21Z

The feature name is literally : tiered_browser_support. It's not much about testing but about web browsers support, which aren't the same thing at all. ;)

carols10cents · 2017-05-17T19:46:52Z

The feature name is literally : tiered_browser_support. It's not much about testing but about web browsers support, which aren't the same thing at all. ;)

What about the summary is unclear though? Also, tiered_browser_support doesn't say anything about docs rendering, and testing is literally about ensuring we actually have browser support, so it is the same thing....

steveklabnik · 2017-05-17T19:57:54Z

@GuillaumeGomez I think you're really nitpicking here; "support" in this context means "things we guarantee support for", and the mechanism by which we do that is through tests.

rfcbot · 2017-06-06T22:09:15Z

🔔 This is now entering its final comment period, as per the review above. 🔔

buosseph · 2017-06-14T14:19:17Z

This may be nitpicky, but I feel Chrome for Android should be included in the browserlist. While I'm not aware of any major differences between the desktop and Android versions of Chrome, it would be good to be explicit and catch any cases where there are differences.

Edit:
Additionally, I'd make the same argument for Firefox for Android, but that's another third-party mobile browser to support and doesn't seem like a high priority based on the data (at 0.66% of session traffic).

rfcbot · 2017-06-16T23:06:22Z

The final comment period is now complete.

aturon · 2017-07-03T18:34:19Z

Huzzah! This RFC has now been merged. Follow up, e.g. regarding Chrome for Android, should go on the tracking issue.

Proposal for a tiered browser support policy for Rust's web content

c32ce88

Fix link to metrics

9b8a6a3

Add thanks.rust-lang.org, thanks snorge!!!

19dba38

nagisa reviewed Apr 28, 2017

View reviewed changes

aturon added the T-core Relevant to the core team, which will review and decide on the RFC. label Apr 29, 2017

nrc approved these changes Apr 30, 2017

View reviewed changes

nrc assigned carols10cents Apr 30, 2017

est31 mentioned this pull request May 18, 2017

Nightly documentation is broken rust-lang/rust#42078

Closed

This was referenced May 28, 2017

nagbot is nagging me and I don't think it should be :-/ rust-lang/rfcbot-rs#144

Closed

nagbot is nagging me and I don't think it should be :-/ aturon/nag-rs#2

Open

rfcbot added the final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. label Jun 6, 2017

locks mentioned this pull request Jun 8, 2017

Upgrade to Ember v2.13 rust-lang/crates.io#760

Merged

carols10cents mentioned this pull request Jun 17, 2017

Update to Babel 6 rust-lang/crates.io#778

Merged

aturon mentioned this pull request Jul 3, 2017

Tracking issue for RFC 1985: Tiered browser support rust-lang/rust#43035

Open

14 tasks

RFC 1985 is Tiered browser support

797e109

aturon merged commit acb75a7 into rust-lang:master Jul 3, 2017

carols10cents deleted the tiered-browser-support branch July 5, 2017 15:05

QuietMisdreavus mentioned this pull request Aug 14, 2017

Rustdoc issue backlog rust-dev-tools/dev-tools-team#23

Open

Centril added the A-web-presence Marketing / web presence / PSA related proposals & ideas label Nov 23, 2018


		[Rust FAQ]: https://www.rust-lang.org/en-US/faq.html

		# Drawbacks

Tiered browser support policy for Rust's web content #1985

Tiered browser support policy for Rust's web content #1985

Conversation

carols10cents commented Apr 28, 2017 • edited Loading

GuillaumeGomez commented Apr 28, 2017

carols10cents commented Apr 28, 2017

GuillaumeGomez commented Apr 28, 2017

carols10cents commented Apr 28, 2017

whitequark commented Apr 28, 2017

carols10cents commented Apr 28, 2017

carols10cents commented Apr 28, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aturon commented Apr 29, 2017

kennytm commented Apr 29, 2017

dlight commented Apr 29, 2017

GuillaumeGomez commented Apr 29, 2017

steveklabnik commented Apr 29, 2017

steveklabnik commented Apr 29, 2017

bluetech commented Apr 30, 2017

nrc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carols10cents May 1, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carols10cents commented May 1, 2017

clarfonthey commented May 2, 2017 • edited Loading

o01eg commented May 3, 2017

GuillaumeGomez commented May 4, 2017

carols10cents commented May 4, 2017

mgattozzi commented May 4, 2017

clarfonthey commented May 5, 2017

carols10cents commented May 5, 2017

carols10cents commented May 6, 2017

wesleywiser commented May 16, 2017

GuillaumeGomez commented May 17, 2017

carols10cents commented May 17, 2017

wesleywiser commented May 17, 2017

carols10cents commented May 17, 2017

GuillaumeGomez commented May 17, 2017

alexcrichton commented May 17, 2017

aturon commented May 17, 2017

steveklabnik commented May 17, 2017

carols10cents commented May 17, 2017 • edited Loading

carols10cents commented May 17, 2017

GuillaumeGomez commented May 17, 2017

carols10cents commented May 17, 2017 • edited Loading

steveklabnik commented May 17, 2017

rfcbot commented Jun 6, 2017

buosseph commented Jun 14, 2017 • edited Loading

rfcbot commented Jun 16, 2017

aturon commented Jul 3, 2017

carols10cents commented Apr 28, 2017 •

edited

Loading

carols10cents May 1, 2017 •

edited

Loading

clarfonthey commented May 2, 2017 •

edited

Loading

carols10cents commented May 17, 2017 •

edited

Loading

carols10cents commented May 17, 2017 •

edited

Loading

buosseph commented Jun 14, 2017 •

edited

Loading