Do not explicitly write the browsers which are supported, but just enumerate the browser features required

[KOLANICH]

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/supported-browsers.md

5. Why do you think this section or language needs improvement?

Because there are tons of browsers and in the ideal world any webpage using certain standardized features must work in any browser complying with the standards. So I think you should just specify the features needed by this website in order to work. I insist on multitier-support.

Tier 0 is the minimal set of features needed to have this website fully functional. I mean that users should be able to login, clone, make commits through web interface, discuiss issues, adjust settings, download zips, watch network graph (server-rendered into svg or even png+<map>, it is even possible to make it interactive with help of CSS), etc but may encounter not the best UX: some characters (emoji) may look like squares or non-githubish (using the fonts available), svg may not be displayed, pdf or 3d models may not be rendered, text recovery may not work, but all the critical features must work.
I insist on non-inclusion of fonts, svg and the most importantly JavaScript into the feature set of this tier. I mean that the website should work in TorBrowser when the security slider is set to maximum security and there are no whitelisted sites in NoScript addon settings.

Tier N is the set of features for the best UX.

[tkw1536]

Some users might not be familiar with which browser has which features (not every GitHub user is a web developer), so it might actually be useful to do a combination of both: Explain the tiers model as suggested, and additionally list for the most common browsers along with corresponding tiers.

[Blaisorblade]

I mean that the website should work in TorBrowser when the security slider is set to maximum security and there are no whitelisted sites in NoScript addon settings.

That seems orthogonal (and more practical) than your stated issue, so I'd file it separately.

Why more practical? Because "supporting a browser", IIUC, does NOT (only) mean "only use features documented by that browser". It also means TEST the website under that browser. (Otherwise, they might have written "any HTML5-compliant browser"). I'm not sure how related the two things are nowadays.

[KOLANICH]

(Otherwise, they might have written "any HTML5-compliant browser")

There is no such a thing as HTML5. But there are W3C documents and there are features proposed in these documents. And in fact web developers use not "HTML5", but input type="color", not "webrtc", but RTCPeerConnection API, not "ECMAScript 2015", but Proxyes feature, not "ECMAScript 2017", but "modules feature", not just canvas, but HitRegions API, not just "WebAudio", but "PannerNode". Differrent browsers implement differrent subsets of API, but these subsets are standardized. This means that in an ideal world any website using some standardized subset of API must work in any web browser supporting this subset. Of course testing is needed for the most of major browsers (fortunately this testing is done by users, so no additionall effort to test the browsers used by noone), but if the website doesn't work, there is only 1 significant case: the subset of API used on website doesn't match the subset of API available in the browser (with respect to addons) and there is only 2 solutions: either declare the correct (complying with the standards) impl of the features required (automatically dropping support of that browser, and automatically reaquiring it when the browser is fixed), or make the website work without these features (bringing support to any browser which implement the standards correctly). In the quoted piece I've proposed to fix GH to make it not to require the features disabled in the latest Tor Browser. It will automatically mean that the website will work in any other standard-complying web browser without that features, for example in a regular Firefox with JS disabled.

so

they might have written "any web browser supporting <this>, <that>, ... and <that>"

IMHO is completely OK and even how this should be done in the ideal world world where major browsers able to run any code complaining with the specs as it was intended.

[bean5]

I think that listing functional requirements is okay, but sometime should maintain a concordance of which browsers support each feature. That enables anyone to see whether their browser supports the feature. However, if their browser does not support linking or interacting with the concordance (hyperlinks), they will be stuck.

Alternatively, instead of listing required browsers or functions, listing advised/generally supported ones might be better. Perhaps indicate that if a browser fails to work, try another. We want to include and enable, not block, right?

[wokste]

In my opinion it is better to describe the browsers it works under. Supporting a browser is more than supporting all features of said browser. It means testing the website in the browser. Since testing should be limited to the major browsers, GitHub needs to describe where it is testing for. (Hence the support)

That said, I agree that if a non-obscure browser or settings renders the pages incorrectly, that it would be good if it is fixed.

[b264]

Have we all as a species not learned to standardize yet? All of this is still unfixed from the 1990s.

[Blaisorblade]

I apologize for starting this subdebate—github's repo is not the right place to discuss whether browsers follow standards.

I don't know if browsers are standardized enough that listing features is sufficient—@KOLANICH implies yes, others disagree, but this is not the place to figure this out, but to post an authoritative link to some other place (at least, StackOverflow, Wikipedia, or something even more authoritative).

I insist on non-inclusion of fonts, svg and the most importantly JavaScript into the feature set of this tier. I mean that the website should work in TorBrowser

Making the website accessible with Tor should probably be a separate issue rather than hidden under this title (I'd say it belongs to a separate repo, not to the site policies, but it's not there). It sounds desirable to some, but that's a technical question.
(Also, since GitHub is a de facto standard hosting and wants to be community-friendly, it arguably should be as accessible as possible even when profit-wise it's not a priority—but GitHub's is a private company giving us a free service).

[b264]

Nothing is free except bad advice. They want us to subscribe to paid features. 😛 They are banking that at some point, you will need to store closed-source code and you'll pay them instead of a competitor or using your own server. Presumably, folks using github with TOR will only consider paying if it's with bitcoin. So unless github accepts bitcoin, spending money to maintain compatibility with TOR browsers is likely not economically sound for them, even if it would be an awesome thing for them to do.

[Blaisorblade]

@b264 To be sure, I know well they're not a charity: I just mention there's some limit to how much non-paying users can ask/demand/"insist" from a company.

[KOLANICH]

Making the website accessible with Tor should probably be a separate issue

This issue is not about accessibility through Tor (which is The Onion Router). TorBrowser is just an example of the browser which, I note, can be used without Tor itself, which implements a very limited subset of features in the way as described in the standards. It breaks lots of sites relying on that features, so in order not to break the website GH can just stop to rely entirely on that features. I also wanna note that some features of TorBrowser are to be uplifed into the regular Firefox.

[KOLANICH]

@b264, your concerns make sense, but only GH staff can clarify if they are going to implement this proposal. But the first thing needed to be done is just to enumerate all the API they use. I can make this myself (the JS sources are publicly available, you know), but it'd take some time and effort to write the and debug the code scanning the JS files for API calls (btw, it can be a curious research to crawl the web and find out which percent of websites uses which new API, find the websites which use the most of new API and show the results in a website called areweecmascriptyet, but I'm not going to do this). I assume that the devs already have some documents describing which API they are free to use in order not to break the compatibility, and that the devs remember the API they have used, so it's much easier to ask them to spend a minute and enumerate what they remember.

[nsqe]

This has been a really interesting discussion. Seriously, thank you all for it.

We agree with a lot of the points raised, and ultimately, what it has brought to light is that the "Supported Browsers" page doesn't really belong in our site-policy repository, because it isn't a policy document.

We're going to find a new home for it, and we hope we're going to be able to address some of these concerns once we get it some better maintenance.

For now, I'm closing this, but we've got links to the issue so we can get the page tidied up in the near future. Again, thank you!

[grahamperrin]

Orientation: 65f5cae#diff-9e476387322a5c250893cf9c5c4ce78c (file deleted)

help.github.com/articles/supported-browsers is part of setup, not site-policy

▶ https://help.github.com/articles/supported-browsers/