H5P is a very open standard. This is positive for flexibility. Most content may be produced as H5P. But this also allows for bad code, security weaknesses and code that may be difficult to reuse. Therefore, the best practices listed below should be followed to get the most from H5P.
Think reusability when creating a library. H5P support dependencies between libraries, so the same small quiz-library may be used in various larger packages or libraries.
H5P support library updates. This enables all content using a common library to be updated at once. This must be accounted for when writing new libraries. A library should be as general as possible. The content format should be well planned so there are no changes to the required content data when a library is updated. Note: It is possible to change the content structure in new minor or major versions of a library.Multiple versions of a library may exist at the same time, only patch level updates will be automatically installed.
An H5P should not interact directly with the containing website. It shall only affect elements within its own generated DOM tree. Elements shall also only be injected within the target defined on initialization. This is to avoid dependencies to a specific platform or web page.
Prefix objects, global functions, etc with h5p to minimize the chance of namespace conflicts with the rest of the web page. Remember that there may also be multiple H5P objects inserted on a page, so plan ahead to avoid conflicts.
H5P supplies its own copy of jQuery as H5P.jQuery. Use this rather than assuming $ is defined.
Content should be responsive and adapt to various screen sizes.
Content should be WCAG 2.1 AA compliant.
- All generated HTML should validate.
- All CSS should validate (some browser specific non-standard CSS may at times be required)
- Follow the H5P coding style by verifying your code using eslint, and the config found here