Merge pull request #6323 from hdsnet/master

Fix typo in Introduction
This commit is contained in:
Andreas Hocevar
2017-01-03 20:38:16 +01:00
committed by GitHub

View File

@@ -13,7 +13,7 @@ The initial release aims to support much of the functionality provided by versio
It is also designed such that major new features, such as displaying 3D maps, or using WebGL to quickly display large vector data sets, can be added in later releases.
## Google Closure
OpenLayers was written in a way s it can be compiled with [__Closure Compiler__](https://developers.google.com/closure/compiler/). Its 'advanced' compilation mode offers a level of compression that exceeds anything else available.
OpenLayers was written in a way so it can be compiled with [__Closure Compiler__](https://developers.google.com/closure/compiler/). Its 'advanced' compilation mode offers a level of compression that exceeds anything else available.
## Public API
Using the advanced optimizations of the Closure Compiler means that properties and methods are renamed – `longMeaningfulName` might become `xB` – and so are effectively unusable in applications using the library. To be usable, they have to be explicitly `exported`. This means the exported names, those not renamed, effectively become the public API of the library. These __exportable__ properties and methods are marked in the source, and documented in the [API docs](../../apidoc). This is the officially supported API of the library. A build containing all these exportable names is known as a __full build__. A hosted version of this is available, which can be used by any application.
@@ -22,7 +22,7 @@ Using the advanced optimizations of the Closure Compiler means that properties a
Unlike in, say, Node, where a module's exports are fixed in the source, with Closure Compiler, exports can be defined at compile time. This makes it easy to create builds that are customized to the needs of a particular site or application: a __custom build__ only exports those properties and methods needed by the site or application. As the full build is large, and will probably become larger as new features are added to the API, it's recommended that sites create a custom build for production software.
## Renderers and Browser Support
The library currently includes two renderers: Canvas and WebGL. All three support both raster data from tile/image servers, and vector data; WebGL however does not support labels. Clearly only those browsers that [support Canvas](http://caniuse.com/canvas) can use the Canvas renderer. Equally, the WebGL renderer can only be used on those devices and [browsers](http://caniuse.com/webgl) that support WebGL.
The library currently includes two renderers: Canvas and WebGL. Both of them support both raster data from tile/image servers, and vector data; WebGL however does not support labels. Clearly only those browsers that [support Canvas](http://caniuse.com/canvas) can use the Canvas renderer. Equally, the WebGL renderer can only be used on those devices and [browsers](http://caniuse.com/webgl) that support WebGL.
OpenLayers runs on all modern browsers that support [HTML5](https://html.spec.whatwg.org/multipage/) and [ECMAScript 5](http://www.ecma-international.org/ecma-262/5.1/). This includes Chrome, Firefox, Safari and Edge. For older browsers and platforms like Internet Explorer (down to version 9) and Android 4.x, [polyfills](http://polyfill.io) for `requestAnimationFrame` and `Element.prototype.classList` are required, and using the KML format requires a polyfill for `URL`.