Affordances template and instructions Last updated April 27, 2018 First there is the empty template followed by the instructions below. begin emtpy template Affordance name: 1. Short description: 2. Dependencies: 3. Use case Reference: 4. Examples: 5. Testing: End template*** ***begin instructions Affordance name: A few words that identifies the name of the affordance which allows us to easily talk about the feature 1. Short Description: Short description of what the features means. This should be precise and, as much as possible, exhaustive, provide information for example "UA must do xxx if support this feature". If this affordance is a MUST, i.e., we require a conforming user agent to implement it, then this description is normative, otherwise it is informative. 2. Dependencies: If the affordance depends on the manifest/infoset then those items should be clearly defined in the manifest/infoset. If there is a dependence on other WG-s output, provide reference. If this affordance is a MUST, i.e., we require a conforming user agent to implement it, then these manifest/infoset items are labeled as REQUIRED, otherwise they may be optional. If this affordance is a MUST, i.e., we require a conforming user agent to implement it, then the external reference must be normative, otherwise it is informative. 3. Use case referencies: Reference to the use case(s) in the Use Case document. (Informative) 4. Examples: Provide example for recommendation of the feature (for example https://www.w3.org/TR/css-regions-1/images/menu-wide.png from css-rigions-1) even though it is not supported yet. (Informative) 5. Testing: (Informative, and may not be part of the final text) What does it mean to test this feature. Both from the point of view of a general W3C test, as well as for the purpose of an eventual epubcheck-like service. For the affordance item which can be break into low-level spec maybe provide low-level spec test would be useful? How can we say UA can support this feature (to let this spec move forward to CR?)? list end