| | 1 | = Feature Flags |
| | 2 | |
| | 3 | WebKit provides a way to expose a feature flag to a client application at runtime, and have that application toggle the feature. This lets us to start work on experimental features without fully exposing them to the Web, but allows Web developers to turn them on and test. There are two types of exposed features: Experimental and Internal Debug. |
| | 4 | |
| | 5 | The configuration file `WebPreferences.yaml` controls these features. Just set the `category` value to `experimental` or `internal`. Note that you should also provide a nice human-understandable description and name. |
| | 6 | |
| | 7 | These are only exposed by WebKit2. If you want your feature to be toggled via WebKit1 you'll have to manually add more code. |
| | 8 | |
| | 9 | == Experimental Features |
| | 10 | |
| | 11 | These features are designed for Web developers, and are exposed via Safari's Develop menu as well as MiniBrowser. |
| | 12 | |
| | 13 | == Internal Debug Features |
| | 14 | |
| | 15 | These features are designed for WebKit developers, and are exposed via Safari's secret-but-not-really Debug menu. We do not expect Web developers to change their settings. They are also exposed by MiniBrowser. |
| | 16 | |
| | 17 | == Which should I use? |
| | 18 | |
| | 19 | If a Web developer wouldn't understand what the feature is by name, or it is just for internal testing, then you should use an `internal` feature. For example, we don't want users to disable Service Workers, and almost no one would know what MDSN ICE Candidates are. |
