fix(css): remove bloat from autoprefixing of unsupported browsers

[Splaktar]

PR Checklist

Please check that your PR fulfills the following requirements:

• The commit message follows our guidelines
• Tests for the changes have been added or this is not a bug fix / enhancement
• Docs have been added, updated, or were not required

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Enhancement
[x] Documentation content changes
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

We've long claimed support for n-1 browser versions, but that hasn't been kept up to date. As a result, we've got our autoprefixer settings generating CSS for Safari 8, 9, 10.0, and some dead browsers like Blackberry, Opera Mobile 12.1, and IE 10. This significantly bloats our CSS.
With our old settings we only supported 86.6% of the global browser market.

Issue Number:
Fixes #9396

What is the new behavior?

• Unminified CSS reduced by 135 KB
• We now support 90.93% of the global browser market
• use recommended configuration for autoprefix and browserslist
• use a more accurate screenshot of browser support
• update README with link to browserslist settings in package.json
• update README with link to browserl.ist page that shows our config
• add browser support info to AngularJS Material home page

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Users of Safari 8, 9, 10.0, Blackberry, Opera Mobile 12.1, and IE 10 may consider this a breaking change, but this follows our past browser support guidance so it should not be considered breaking. That said, I am still going to push this to 1.1.11 instead of putting it into 1.1.10 as we have some other significant CSS changes in that release that I don't want to mix with these.

[mgol]

If you expand the table to specific browser versions that will be constantly getting out of date and, in turn, confuse people. I'd collapse all "last 2 versions" browsers into one row and add a restriction that only ones with certain usage (> 0.5%) are included; "last 2 iOS versions" is different from "iOS 11 & 11.3" as the latter is fixed and the former changes over time.

[jelbourn]

I agree that it would be better to avoid using specific versions unless it's a special case (like IE11)

[Splaktar]

I want to include specific versions for certain browsers where their versioning strategy is inconsistent or odd. Many people ask for an actual translation of what our browser policy is in specific versions and in some cases, it's too confusing to explain it without just listing the version numbers. I've collapsed many of the browsers into shared rows as suggested.

[mgol]

@Splaktar In that case, perhaps it'd be nice to have the versions of those browsers generated in the build process? Then, once a new browserslist comes out and is included in AngularJS Material, the table would update automatically. Otherwise it will keep getting out of date.

[jelbourn]

LGTM, do you happen to know the total reduced size of the minified bundle?

[Splaktar]

angular-material.min.css

• Before 398 KB
• After 360 KB

Reduced size of the minified CSS - 38 KB

[Splaktar]

@mgol let's handle the automatic updates in a separate issue as I think that has a different priority than getting the initial documentation in place.

[mgol]

Cool, makes sense.