Update browser compat docs. #2583
Conversation
app/3.0/docs/es6.md
Outdated
|
|
||
| ### Module specifiers | ||
|
|
||
| The browser only accepts on kind of module specifier in an `import` statement: a URL, which must |
app/3.0/docs/es6.md
Outdated
|
|
||
| ### Dynamic imports | ||
|
|
||
| Dynamic imports is a language feature that enables lazy-loading of resources, replacing the functionality |
There was a problem hiding this comment.
"Dynamic imports is a language feature"
is -> are? & if so, enables -> enable.
If not, maybe "Dynamic import() is a ..."
app/3.0/docs/es6.md
Outdated
| The latest versions of Chrome and Safari support dynamic imports. For other browsers, the Polymer build tools can transform | ||
| dynamic imports into AMD modules. The Polymer development server can do this transformation on the fly. | ||
|
|
||
| More on dyanmic import, see: |
There was a problem hiding this comment.
More -> For more
"dyanmic" -> "dynamic"
"import" -> "imports" or "import()"
| compiled and uncompiled code in its cache, resulting in errors. To avoid this problem, run | ||
| `polymer serve` with the `--compile never` option when testing with device emulation. | ||
| {.alert .alert info} | ||
| While the Polymer library doesn't depend on any features from newer JavaScript standards, |
app/3.0/docs/polyfills.md
Outdated
| @@ -32,7 +28,7 @@ There are a couple of other related polyfill files that you may need: | |||
| on browsers that support native custom elements. This is useful in static serving environments | |||
| where you need to serve a single app version to all browsers. The adapter is discussed in more | |||
| detail in [ES6](es6) and in [Build for production](/{{{polymer_version_dir}}}/toolbox/build-for-production). | |||
| * `apply-shim.html`. A polyfill for CSS mixins. Unlike the other polyfills, it should be included | |||
| * `apply-shim.j`. A polyfill for CSS mixins. Unlike the other polyfills, it should be imported | |||
app/3.0/docs/polyfills.md
Outdated
| for custom elements and shadow DOM. You can test Polymer 2.x by using the latest 1.0 version of | ||
| `webcomponentsjs`, which is included as a bower dependency to Polymer 2.x. (`webcomponentsjs` | ||
| Polymer 3.x has been developed alongside and tested with a new suite of v1-spec compatible polyfills | ||
| for custom elements and shadow DOM. You can test Polymer 3.x using the latest 2.0 version of |
There was a problem hiding this comment.
should we mention explicitly that the HTML Imports polyfill has been removed from v2.0 & there is no webcomponents-lite.js?
|
i like the idea of a table showing exactly what polyfills & build transforms each browser requires, provided it wouldn't require too much maintenance for it to stay accurate. |
ghost
mentioned this pull request
|
@katejeffreys if it works for you, I was thinking of doing something like that:
Right now it's not very nice haha BTW, tomorrow Mozilla release Firefox 60 with ES Modules, so... One more green box! :) |
|
BTW the relevant quote from Polymer/tools#191
|
Take 1, updating all this stuff.
Staged here: https://3-0-polyfills-dot-polymer-project.appspot.com/3.0/docs/browsers
Most of the volume here is in my stab at adding info on modules.
Already really good stuff in Dan's README for the polyfills, unsure of whether to pull some of that in here, or to just point to it.
Also, it's still really hard to tell what browser needs what.
I wonder if it'd be better to just have a table like:
Browser & version range | ES6/ES5 | ES Modules/AMD | Polyfills Req'd | Module name transform
Where we'd have multiple lines for a browser if the values were different.
(And yes, all browsers (currently) require the name=>path transform, but at least it makes it clear that some transform is always required.)
LMK what you think.