8
0
Эх сурвалжийг харах

Docs: Added Browser compatibility guide.

Piotrek Koszuliński 8 жил өмнө
parent
commit
5d3747aa71

+ 51 - 0
docs/builds/guides/browser-compatibility.md

@@ -0,0 +1,51 @@
+---
+title: Browser compatibility
+category: builds-guides
+order: 310
+---
+
+## Desktop environment
+
+CKEditor 5 is currently supported on the following desktop browsers:
+
+* Close to full support (see [notes below](#notes)):
+	* Chrome (latest stable release).
+	* Firefox (latest stable release).
+	* Safari (latest stable release).
+	* Opera (latest stable release).
+* Good support:
+	* Edge (latest stable release).
+
+		Known issues:
+
+		* Minor issues with selection: [1](https://github.com/ckeditor/ckeditor5-engine/issues/974), [2](https://github.com/ckeditor/ckeditor5-engine/issues/928).
+		* The editor becomes unstable when F12 tools are enabled.
+
+Not yet supported:
+
+* Internet Explorer 11 is not yet supported. See the [Compatibility with IE11](https://github.com/ckeditor/ckeditor5/issues/330) ticket.
+
+### Notes
+
+Features known to not be fully supported yet:
+
+* Text composition (IME) – Input Method Engine is a mechanism which allows inputting text in languages such as Japanese and Chinese. It's so called "text composition". This mechanism is not yet fully supported and we'll be polishing that feature after 1.0.0.
+* Drag and drop inside editor doesn't work yet. It is possible to drop images from your system if the {@link module:upload/imageupload~ImageUpload} feature is enabled.
+
+## Mobile environment
+
+Although CKEditor 5 works on Safari for iOS and Chrome for Android it has not been fully tested yet and there are known bugs and inconveniences. Full support for mobile browsers will be our goal after releasing 1.0.0.
+
+When working on mobile support we need to consider two complex aspects:
+
+* **Special UI, designed for mobile.**
+
+	During the design phase we understood that creating a responsive and touch-friendly UI will not guarantee a desired UX level by itself. Also, that the "mobile first" approach has no application in this case due to constraints of the mobile environment and specific editing method. Therefore, we plan to introduce a completely customized, mobile-oriented UI.
+
+	We begun research on how to display necessary UI controls on the screen and, sadly, it turned out that mobile Safari's viewport mechanics makes it extremely complicated to display the UI in a reliable way. You can read more in the [UX: Mobile editing](https://github.com/ckeditor/ckeditor5-design/issues/149) ticket.
+
+* **Handling mobile browsers' quirks.**
+
+	Mobile browsers (especially mobile Safari) work differently than their desktop equivalents. [Chrome's incomplete `keydown` event](https://bugs.chromium.org/p/chromium/issues/detail?id=118639) is just one of issues with which we need to deal with.
+
+	For several years we've worked with W3C on [fixing contentEditable](https://medium.com/content-uneditable/fixing-contenteditable-1a9a5073c35d) – a technology on which the entire browser-based editing is based. Recently, browser vendors started implementing the core part of [the new specifications](http://w3c.github.io/editing/) – the `beforeinput` event which has a chance to improve the situation. CKEditor 5's architecture was designed with this event in mind, so we will start taking advantage of it as soon as it proves to be stable enough.

+ 6 - 6
docs/builds/guides/development/custom-builds.md

@@ -35,9 +35,9 @@ To make updating easier you may optionally add the original build repository to
 git remote add upstream https://github.com/ckeditor/ckeditor5-build-classic.git
 ```
 
-<side-box tip>
+<info-box hint>
 	If you do not want to fork the official build, you can just clone it. However, you will not be able to commit and push your customizations back to [GitHub](https://github.com).
-</side-box>
+</info-box>
 
 ## Build anatomy
 
@@ -68,11 +68,11 @@ npm install --save <package-name>
 
 This will install the package and add it to `package.json`. You can also edit `package.json` manually.
 
-<side-box tip>
+<info-box hint>
 	Due to a non-deterministic way how npm installs packages, it is recommended to run `rm -rf node_modules && npm install` when in doubt. This will prevent some packages from getting installed more than once in `node_modules/` (which might lead to broken builds).
 
 	You can also give [Yarn](https://yarnpkg.com/lang/en/) a try.
-</side-box>
+</info-box>
 
 ### Updating build configuration
 
@@ -136,9 +136,9 @@ git merge upstream/master
 
 You should handle eventual conflicts and verify the merged changes. After that, just follow the previous instructions for creating your build and test it.
 
-<side-box tip>
+<info-box hint>
 	It is recommended to run `rm -rf node_modules && npm install` after you fetched changes from the upstream or updated versions of dependencies in `package.json` manually. This will prevent npm from installing packages more than once (which may lead to broken builds).
-</side-box>
+</info-box>
 
 ## Publishing your builds
 

+ 3 - 3
docs/builds/guides/integration/basic-api.md

@@ -9,7 +9,7 @@ order: 20
 
 ## Creators
 
-Each CKEditor 5 build provides a class that handles the creation of editor instances inside a page. For this reason they are called "creators". Every creator comes with a static `create()` method.
+Each CKEditor 5 build provides a class that handles the creation of editor instances ininfo a page. For this reason they are called "creators". Every creator comes with a static `create()` method.
 
 The following are creator class names for each build:
 
@@ -65,11 +65,11 @@ ClassicEditor.create( document.querySelector( '#text-editor' ) )
 
 In the above case, the `<textarea>` element is hidden and replaced with an editor. The `<textarea>` data is used to initialize the editor content. A `<div>` element can be used in the same fashion.
 
-<side-box info>
+<info-box info>
 	Every creator may accept different parameters and handle initialization differently. For instance, the classic editor will replace a given element with an editor, while the inline editor will use the given element to initialize the editor on it. See each editor's documentation to learn the details.
 
 	The interface of the editor class is not enforced either. Since different implementations of editors may vary heavily in terms of functionality, the editor class implementers have full freedom regarding the API. Therefore, the examples in this guide may not work with some editor classes.
-</side-box>
+</info-box>
 
 ## Interacting with the editor
 

+ 4 - 4
docs/builds/guides/integration/configuration.md

@@ -52,9 +52,9 @@ ClassicEditor
 	} );
 ```
 
-<side-box tip>
+<info-box hint>
 	If a build contains too many or too few features, the best approach is to create a custom build instead of simply using configurations.
-</side-box>
+</info-box>
 
 ### List of plugins
 
@@ -80,9 +80,9 @@ ClassicEditor
 	} );
 ```
 
-<side-box tip>
+<info-box hint>
 	The above is a strict UI-related configuration. Removing a toolbar item does not remove the feature from the editor internals. If your goal with the toolbar configuration is to remove features, the right solution is to remove their relative plugins. Check [Enabling features](#Enabling-features) above for more information.
-</side-box>
+</info-box>
 
 ## Other configuration options
 

+ 1 - 1
docs/builds/guides/license-and-legal.md

@@ -4,7 +4,7 @@
 
 title: License and legal
 category: builds-guides
-order: 310
+order: 320
 ---
 
 The following legal notices apply to CKEditor 5 Builds and all software from the CKEditor 5 Ecosystem included with it.

+ 1 - 1
docs/builds/guides/reporting-issues.md

@@ -6,7 +6,7 @@
 
 title: Reporting issues
 category: builds-guides
-order: 320
+order: 330
 ---
 
 If you feel you found an issue in CKEditor, we will be grateful for letting us know. Before you create a bug report, however, please read our guidelines on how to do it properly and most efficiently.