See minutes online for a more detailed record of the discussions.
Issues to solve before next draft publication
There has been a long Github discussion on the nature of cover: should the respective resource be restricted to an image (leaving the reading system to generate something if it is not) or can it be any resource, e.g., an HTML file provided by the author? Although the discussion raised a number of issues related to usability, accessibility, etc, the issue for now is what should be in the draft.
The decision was to modify the draft to include a more permissive version for cover, and seek feedbacks from the community.
This is a long standing issue, which has several facets, most issues have lead to a consensus on the issue.
- for the directionality, the only fallback at this point is to rely on the Unicode directionality markers
- for language, the language provided in the manifest is also defined to be the language of the publication. The question is whether that language value is inherited (or not) in the case the manifest is embedded (via a
<script>tag) into the primary entry page. The case when it is raises issues of differentiating between manifests expressed differently.
The decision was to modify the draft to include inheritance, and seek feedbacks from the community.
There is a call for experimental implementations once the draft is published. Just a minimal version that
- interprets the manifest to provide an internal representation of the data
- provide a minimal set of features: read through all resources and provide some sort of an offline access to the content
Such a minimal (and not necessary polished) implementation should reveal problems, missing features, etc.
The UCR document has been reorganized, and we are now looking at updating it, with the goal of linking it closer to the affordances’ section of the WP draft. A new version should be published in about a month…