Input: [Requirement] Use valid (X)HTML [Details] Using valid HTML means having an HTML code that follows one of the DTDs of the HTML specification. Your best choice is valid XHTML strict markup: XHTML means that the code will benefit from all the XML power, and strict ensures your site won't mix presentation markup with the structure. [Rationale] Valid HTML code is a first step toward more compatibility with browsers and better rendering on the latest ones. Using only strict HTML (that is, the Strict HTML DTD) makes the site easier to maintain and evolve. [Test tool]

Output: The W3C HTML Validator is one of the many options available. The LogValidator is especially helpful in maintaining a valid Web site.

Buy standards compliant Web sites — W3C QA


Input: [Requirement] Use extensively valid CSS [Details] Avoid any presentational markup and keep all the layout features in well-defined CSS style sheets. [Rationale] Linked style sheets allow presentation to be decoupled completely from the page structure of your site, and lets you quickly change its layout and rendering. It also guarantees that everybody can adjust the rendering to their needs and tastes. [Test tool]

Output: The CSS Validator detects any non-compliant use of the CSS technologies.

Buy standards compliant Web sites — W3C QA


Input: [Requirement] Use HTTP properly [Details] Make sure that each page of your site is accessible with a stable address (URL) and that the HTTP caching properties are set correctly. Make sure if you migrate to a new site version that the URLs are either kept as is or at least redirected to the new ones. [Rationale] HTTP is a very powerful protocol and you get most of its power with stable URLs and an efficient caching system: bookmarks and links don't break, network access is faster, users are happy! [Test tool]

Output: The W3C Link Checker can provide some help. Besides, the advices given in the Common HTTP Implementation Problems Note can help assess what needs to be respected.

Buy standards compliant Web sites — W3C QA


Input: [Requirement] Use SVG and PNG for graphics [Details] Use PNG for raster images, and SVG for all others. [Rationale] PNG is a much more capable format than other binary formats for raster images because it provides better compression, more options, and it's free. The best format you should require is SVG: it's scalable, XML-based, very light, and has a lot of capabilities, for example, animation using SMIL, which is supported on cell phones, etc. [Test tool]

Buy standards compliant Web sites — W3C QA


Input: [Requirement] Use techniques to make your content accessible [Details] Details. [Rationale] Making a site accessible benefits all of your users, and broadens your current audience. This requirement may be required by law in some countries. [Test tool]

Output: See Evaluation Tools for Web Content Accessibility.

Buy standards compliant Web sites — W3C QA


Input: [Requirement] Use standards scripting languages [Details] Use the DOM API combined with Ecmascript (but don't make the use of scripts mandatory to navigate in the site!). [Rationale] DOM and Ecmascript (the common standard behind Javascript and JScript) are the best way to go to get interoperable scripts to create animations in your Web site. But do not forget your users that don't have these scripting capacities enabled. [Test tool]

Buy standards compliant Web sites — W3C QA


Input: [Keyword] hidden [State] Hidden [Control type] n/a [Data type]

Output: An arbitrary string

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] text [State] Text [Control type] Text field [Data type]

Output: Text with no line breaks

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] search [State] Search [Control type] Search field [Data type]

Output: Text with no line breaks

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] tel [State] Telephone [Control type] A text field [Data type]

Output: Text with no line breaks

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] url [State] URL [Control type] A text field [Data type]

Output: An absolute IRI

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] email [State] E-mail [Control type] A text field [Data type]

Output: An e-mail address or list of e-mail addresses

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] password [State] Password [Control type] Text field that obscures data entry [Data type]

Output: Text with no line breaks (sensitive information)

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] datetime [State] Date and Time [Control type] A date and time control [Data type]

Output: A date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] date [State] Date [Control type] A date control [Data type]

Output: A date (year, month, day) with no time zone

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] month [State] Month [Control type] A month control [Data type]

Output: A date consisting of a year and a month with no time zone

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] week [State] Week [Control type] A week control [Data type]

Output: A date consisting of a week-year number and a week number with no time zone

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] time [State] Time [Control type] A time control [Data type]

Output: A time (hour, minute, seconds, fractional seconds) with no time zone

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] datetime-local [State] Local Date and Time [Control type] A date and time control [Data type]

Output: A date and time (year, month, day, hour, minute, second, fraction of a second) with no time zone

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] number [State] Number [Control type] A text field or spinner control [Data type]

Output: A numerical value

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] range [State] Range [Control type] A slider control or similar [Data type]

Output: A numerical value, with the extra semantic that the exact value is not important

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] color [State] Color [Control type] A color well [Data type]

Output: An sRGB color with 8-bit red, green, and blue components

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] checkbox [State] Checkbox [Control type] A checkbox [Data type]

Output: A set of zero or more values from a predefined list

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] radio [State] Radio Button [Control type] A radio button [Data type]

Output: An enumerated value

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] file [State] File Upload [Control type] A label and a button [Data type]

Output: Zero or more files each with a MIME type and optionally a file name

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] submit [State] Submit Button [Control type] A button [Data type]

Output: An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] image [State] Image Button [Control type] Either a clickable image, or a button [Data type]

Output: A coordinate, relative to a particular image's size, with the extra semantic that it must be the last value selected and initiates form submission

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] reset [State] Reset Button [Control type] A button [Data type]

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] button [State] Button [Control type] A button [Data type]

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Description] Applications can create alarms, notifying users [Source] SysApps Charter [Requirement]

Output: Alarm API

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps can add, remove and edit contacts [Source] SysApps Charter [Requirement]

Output: Contacts API

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps can send, receive and view SMS [Source] SysApps Charter [Requirement]

Output: Messaging API

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps can access the telephony capabilities of the underlyling platform: dial a number, pick up a call, route to voicemail, access the call log [Source] SysApps Charter [Requirement]

Output: Telephony API

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps can create, manipulate and listen for low-level TCP and UDP connections [Source] SysApps Charter [Requirement]

Output: Raw Sockets API

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Supports a wide variety of devices including desktop & laptop computers, smart phones, tablets, TVs, cameras, and other connected devices [Source] SysApps Charter [Implications] The security model can make no assumptions about how the device will be used or shared between people and cannot assume a particular process model. [Requirement]

Output: Supports many device form factors

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] All APIs defined by DAP should be accessible to system applications [Source] SysApps Charter [Implications] Either DAP APIs will need to change slightly in the systems context or the security model must allow for API-specific access controls [Requirement]

Output: DAP API Support

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Problems such as 'double prompting' should be avoided when integrating other APIs [Source] SysApps Charter [Implications] Some details of the expected user interactions may need to be specified in the security model or APIs [Requirement]

Output: Minimal user prompting

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications consist of HTML, CSS and JavaScript [Requirement]

Output: HTML5

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications have access to geolocation data [Requirement]

Output: Location

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications can communicate with other applications [Implications] Some kind of messaging will be supported [Requirement]

Output: Communicate with other applications

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications can communicate with pre-defined web addresses [Implications] Access remote domains will be possible [Requirement]

Output: Communicate with pre-defined endpoints

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications can run on any conformant platform, potentially including any device form factor [Source] Compatibility of application packages [Requirement]

Output: Valid across multiple platforms

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Allow access control decisions to be logged. [Source] webinos [Requirement]

Output: Access control log

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications shall be able to explain why access to data or APIs is being requested. [Source] webinos [Requirement]

Output: API access rationale

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications shall access only its specified device features, extensions and content. [Source] webinos [Requirement]

Output: Application capability restriction

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications shall specify its required functionality at install time or during updates. [Source] webinos [Requirement]

Output: Application intent

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications shall be isolated from each other. [Source] webinos [Requirement]

Output: Application isolation

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Changes to existing application intentions and permissions shall be approved by the end user. [Source] webinos [Requirement]

Output: Application policy approval

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Before being installed or updated, origin authenticity and integrity checks shall be performed by the runtime [Source] webinos [Requirement]

Output: Authenticity check

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] The list of authorities that certified an application shall be viewable by end-users. [Source] webinos [Requirement]

Output: Certifier list

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] The webinos runtime shall support the confidential storage of user credentials. [Source] webinos [Requirement]

Output: Confidential credentials storage

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Access to credentials storage shall be limited to a specific user, a specific device and a set of applications. [Source] webinos [Requirement]

Output: Credentials access restriction

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] applications shall be able to explain how collected sensitive data will be managed. [Source] webinos [Requirement]

Output: Data management rationale

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] A default security and privacy policy shall exist an be enforced on each conformant runtime [Source] webinos [Requirement]

Output: Default policy

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Personal devices shall be bound to their owner's identities. [Source] webinos [Requirement]

Output: Device-identity binding

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] The binding between personal devices and owner's identity shall be revokable. [Source] webinos [Requirement]

Output: Device-identity binding revokation

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Runtimes can enforce multiple access control rules written by multiple stakeholders in a hierarchy. [Source] webinos [Requirement]

Output: Hierarchical policy enforcement

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Data cached by a runtime shall be securely stored to prevent disclosure and tampering by unauthorised entitites. [Source] webinos [Requirement]

Output: Secure cache

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Application data shall be securely stored to prevent disclosure and tampering by unauthorised entities. [Source] webinos [Requirement]

Output: Secure storage

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] When installing or using an application for the first time, the runtime shall establish that the user trusts the source of the application. [Source] webinos [Implications] Apps must have provenance data attached to them [Requirement]

Output: Trusted application source

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] "An app store needs to be able to approve an application, implying they can verify the permissions, integrity and authenticity of the app" [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] App permissions can be changed remotely [Requirement]

Output: App stores can revoke applications

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] B2G: "App store must be able to set the default permissions for an app". [Source] Extrapolated from B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] The user is not the only source of access control decisions. this also suggests a need for conflict resolution. [Requirement]

Output: External trusted party can set app default permissions

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications must be installed before executed [Source] B2G, webinos [Requirement]

Output: Installation

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] The device owner must be able to override app settings and permissions (this may not be the user, but a corporate, for example) [Source] B2G (user), webinos (user) [Implications] Access control settings must be changeable [Requirement]

Output: Owner override

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] There must be a standard way for applications to identify the permissions they have and lack [Requirement]

Output: App privilege visibility

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Requirement]

Output: Permission usability

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps should not be vulnerable to common web vulnerabilities when granted significant privileges [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] Non-browser security context: may be additional restrictions on HTML/JavaScript [Requirement]

Output: Immunity to browser-based threats

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Ability to grant trust for certain highly sensitive privileges (such as phone dialing) may be restricted at the OS level to specific trusted parties [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] Different 'levels' apply to SysApps - possibly 'roles' [Requirement]

Output: Pre-installed app permissions

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Ability for a system application to access (read and write) files outside of that application's sandboxed storage area. [Source] Mailing list: http://lists.w3.org/Archives/Public/public-sysapps/2012Nov/0003.html [Implications] Need to provide both sandboxed and non-sandboxed storage [Requirement]

Output: Access to files outside owned by the platform

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [State] Hidden [Data type] An arbitrary string [Control type] n/a [Keyword]

Output: hidden


Input: [State] Text [Data type] Text with no line breaks [Control type] Text field [Keyword]

Output: text


Input: [State] Search [Data type] Text with no line breaks [Control type] Search field [Keyword]

Output: search


Input: [State] Telephone [Data type] Text with no line breaks [Control type] A text field [Keyword]

Output: tel


Input: [State] URL [Data type] An absolute IRI [Control type] A text field [Keyword]

Output: url


Input: [State] E-mail [Data type] An e-mail address or list of e-mail addresses [Control type] A text field [Keyword]

Output: email


Input: [State] Password [Data type] Text with no line breaks (sensitive information) [Control type] Text field that obscures data entry [Keyword]

Output: password


Input: [State] Date and Time [Data type] A date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC [Control type] A date and time control [Keyword]

Output: datetime


Input: [State] Date [Data type] A date (year, month, day) with no time zone [Control type] A date control [Keyword]

Output: date


Input: [State] Month [Data type] A date consisting of a year and a month with no time zone [Control type] A month control [Keyword]

Output: month


Input: [State] Week [Data type] A date consisting of a week-year number and a week number with no time zone [Control type] A week control [Keyword]

Output: week


Input: [State] Time [Data type] A time (hour, minute, seconds, fractional seconds) with no time zone [Control type] A time control [Keyword]

Output: time


Input: [State] Local Date and Time [Data type] A date and time (year, month, day, hour, minute, second, fraction of a second) with no time zone [Control type] A date and time control [Keyword]

Output: datetime-local


Input: [State] Number [Data type] A numerical value [Control type] A text field or spinner control [Keyword]

Output: number


Input: [State] Range [Data type] A numerical value, with the extra semantic that the exact value is not important [Control type] A slider control or similar [Keyword]

Output: range


Input: [State] Color [Data type] An sRGB color with 8-bit red, green, and blue components [Control type] A color well [Keyword]

Output: color


Input: [State] Checkbox [Data type] A set of zero or more values from a predefined list [Control type] A checkbox [Keyword]

Output: checkbox


Input: [State] Radio Button [Data type] An enumerated value [Control type] A radio button [Keyword]

Output: radio


Input: [State] File Upload [Data type] Zero or more files each with a MIME type and optionally a file name [Control type] A label and a button [Keyword]

Output: file


Input: [State] Submit Button [Data type] An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission [Control type] A button [Keyword]

Output: submit


Input: [State] Image Button [Data type] A coordinate, relative to a particular image's size, with the extra semantic that it must be the last value selected and initiates form submission [Control type] Either a clickable image, or a button [Keyword]

Output: image


Input: [State] Reset Button [Data type] n/a [Control type] A button [Keyword]

Output: reset


Input: [State] Button [Data type] n/a [Control type] A button [Keyword]

Output: button


Input: [Scenario] When an accessibility subtree is hidden [Microsoft UIA event] AutomationElement..::.StructureChangedEvent [ATK/AT-SPI event] children_changed::remove [AXAPI Notification] AXUIElementDestroyed If in a live region, AXLiveRegionChanged [MSAA]

Output: EVENT_OBJECT_HIDE The MSAA event called EVENT_OBJECT_DESTROY is not used because this has a history of stability issues and assistive technology avoids it. In any case, from the user's point of view, there is no difference between something that is hidden or destroyed.

Table of document change scenarios and events to be fired in each API


Input: [Scenario] When an accessibility subtree is removed [Microsoft UIA event] AutomationElement..::.StructureChangedEvent [ATK/AT-SPI event] children_changed::remove [AXAPI Notification] AXUIElementDestroyed If in a live region, AXLiveRegionChanged [MSAA]

Output: EVENT_OBJECT_REORDER The MSAA event called EVENT_OBJECT_DESTROY is not used because this has a history of stability issues and assistive technology avoids it. In any case, from the user's point of view, there is no difference between something that is hidden or destroyed.


Input: [Scenario] When an accessibility subtree is shown [ATK/AT-SPI event] children_changed::add [AXAPI Notification] AXUIElementCreated If in a live region, AXLiveRegionChanged [MSAA]

Output: EVENT_OBJECT_SHOW


Input: [Scenario] When an accessibility subtree is inserted [ATK/AT-SPI event] children_changed::add [AXAPI Notification] AXUIElementCreated If in a live region, AXLiveRegionChanged [MSAA]

Output: EVENT_OBJECT_REORDER


Input: [Scenario] When an accessibility subtree is moved [Microsoft UIA event] Treat it as a removal from one place and insertion in another [ATK/AT-SPI event] Treat it as a removal from one place and insertion in another [AXAPI Notification] AXUIElementDestroyed/ AXUIElementCreated If in a live region, AXLiveRegionChanged [MSAA]

Output: Treat it as a removal from one place and insertion in another


Input: [Scenario] When an accessibility subtree is changed (e.g. replaceNode) [Microsoft UIA event] Treat it as a removal and insertion [ATK/AT-SPI event] Treat it as a removal and insertion [AXAPI Notification] AXUIElementDestroyed/ AXUIElementCreated If in a live region, AXLiveRegionChanged [MSAA]

Output: Treat it as a removal and insertion


Input: [Requirement] Use valid (X)HTML [Details] Using valid HTML means having an HTML code that follows one of the DTDs of the HTML specification. Your best choice is valid XHTML strict markup: XHTML means that the code will benefit from all the XML power, and strict ensures your site won't mix presentation markup with the structure. [Test tool] The W3C HTML Validator is one of the many options available. The LogValidator is especially helpful in maintaining a valid Web site. [Rationale]

Output: Valid HTML code is a first step toward more compatibility with browsers and better rendering on the latest ones. Using only strict HTML (that is, the Strict HTML DTD) makes the site easier to maintain and evolve.

Buy standards compliant Web sites — W3C QA


Input: [Requirement] Use extensively valid CSS [Details] Avoid any presentational markup and keep all the layout features in well-defined CSS style sheets. [Test tool] The CSS Validator detects any non-compliant use of the CSS technologies. [Rationale]

Output: Linked style sheets allow presentation to be decoupled completely from the page structure of your site, and lets you quickly change its layout and rendering. It also guarantees that everybody can adjust the rendering to their needs and tastes.

Buy standards compliant Web sites — W3C QA


Input: [Requirement] Use HTTP properly [Details] Make sure that each page of your site is accessible with a stable address (URL) and that the HTTP caching properties are set correctly. Make sure if you migrate to a new site version that the URLs are either kept as is or at least redirected to the new ones. [Test tool] The W3C Link Checker can provide some help. Besides, the advices given in the Common HTTP Implementation Problems Note can help assess what needs to be respected. [Rationale]

Output: HTTP is a very powerful protocol and you get most of its power with stable URLs and an efficient caching system: bookmarks and links don't break, network access is faster, users are happy!

Buy standards compliant Web sites — W3C QA


Input: [Requirement] Use SVG and PNG for graphics [Details] Use PNG for raster images, and SVG for all others. [Test tool] N/A [Rationale]

Output: PNG is a much more capable format than other binary formats for raster images because it provides better compression, more options, and it's free. The best format you should require is SVG: it's scalable, XML-based, very light, and has a lot of capabilities, for example, animation using SMIL, which is supported on cell phones, etc.

Buy standards compliant Web sites — W3C QA


Input: [Requirement] Use techniques to make your content accessible [Details] Details. [Test tool] See Evaluation Tools for Web Content Accessibility. [Rationale]

Output: Making a site accessible benefits all of your users, and broadens your current audience. This requirement may be required by law in some countries.

Buy standards compliant Web sites — W3C QA


Input: [Requirement] Use standards scripting languages [Details] Use the DOM API combined with Ecmascript (but don't make the use of scripts mandatory to navigate in the site!). [Test tool] N/A [Rationale]

Output: DOM and Ecmascript (the common standard behind Javascript and JScript) are the best way to go to get interoperable scripts to create animations in your Web site. But do not forget your users that don't have these scripting capacities enabled.

Buy standards compliant Web sites — W3C QA


Input: [Category] Hyperlink [Description] Gives alternate representations of the current document. [Link type]

Output: alternate


Input: [Category] Hyperlink [Description] Provides a link to a collection of records, documents, or other materials of historical interest. [Link type]

Output: archives


Input: [Category] Hyperlink [Description] Gives a link to the current document's author. [Link type]

Output: author


Input: [Category] Hyperlink [Description] Indicates that the current document is a part of a series, and that the first document in the series is the referenced document. [Link type]

Output: first


Input: [Category] Hyperlink [Description] Provides a link to context-sensitive help. [Link type]

Output: help


Input: [Category] External Resource [Description] Imports an icon to represent the current document. [Link type]

Output: icon


Input: [Category] Hyperlink [Description] Gives a link to the document that provides a table of contents or index listing the current document. [Link type]

Output: index


Input: [Category] Hyperlink [Description] Indicates that the current document is a part of a series, and that the last document in the series is the referenced document. [Link type]

Output: last


Input: [Category] Hyperlink [Description] Indicates that the main content of the current document is covered by the copyright license described by the referenced document. [Link type]

Output: license


Input: [Category] Hyperlink [Description] Indicates that the current document is a part of a series, and that the next document in the series is the referenced document. [Link type]

Output: next


Input: [Category] External Resource [Description] Gives the address of the pingback server that handles pingbacks to the current document. [Link type]

Output: pingback


Input: [Category] External Resource [Description] Specifies that the target resource should be preemptively cached. [Link type]

Output: prefetch


Input: [Category] Hyperlink [Description] Indicates that the current document is a part of a series, and that the previous document in the series is the referenced document. [Link type]

Output: prev


Input: [Category] Hyperlink [Description] Gives a link to a resource that can be used to search through the current document and its related pages. [Link type]

Output: search


Input: [Category] External Resource [Description] Imports a stylesheet. [Link type]

Output: stylesheet


Input: [Category] Hyperlink [Description] Specifies that the referenced document, if retrieved, is intended to be shown in the browser's sidebar (if it has one). [Link type]

Output: sidebar


Input: [Category] Hyperlink [Description] Gives a tag (identified by the given address) that applies to the current document. [Link type]

Output: tag


Input: [Category] Hyperlink [Description] Provides a link to a document giving the context for the current document. [Link type]

Output: up


Input: [Identifier] eq [Semantics]

Output: The “Equals” operator indicating that a given value equals the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.3.2: Terms for the attribute “operator” of the entity Constraint


Input: [Identifier] gt [Semantics]

Output: The “Greater Than” operator indicating that a given value is greater than the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] gteq [Semantics]

Output: The “Greater Than or Equal To” operator indicating that a given value is greater than or equal to the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] hasPart [Semantics]

Output: The “Has Part” operator indicating that a given value contains the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] isA [Semantics]

Output: The “Is A” operator indicating that a given value is an instance of the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] isAllOf [Semantics]

Output: The “Is All Of” operator indicating that a given value is all of the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] isAnyOf [Semantics]

Output: The “Is Any Of” operator indicating that a given value is any of the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] isNoneOf [Semantics]

Output: The “Is None Of” operator indicating that a given value is none of the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] isPartOf [Semantics]

Output: The “Is Part Of” operator indicating that a given value is contained by the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] lt [Semantics]

Output: The “Less Than” operator indicating that a given value is less than the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] lteq [Semantics]

Output: The “Less Than or Equal To” operator indicating that a given value is less than or equal to the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] neq [Semantics]

Output: The “Not Equal To” operator indicating that a given value is not equal to the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Type of information] Background colour [Description]

Output: Solid background colour to be used when presenting the image if no better option is available.

Portable Network Graphics (PNG) Specification (Second Edition)

Table 4.1 — Types of ancillary information


Input: [Type of information] Gamma and chromaticity [Description]

Output: Gamma characteristic of the image with respect to the desired output intensity, and chromaticity characteristics of the RGB values used in the image.

Portable Network Graphics (PNG) Specification (Second Edition)


Input: [Type of information] ICC profile [Description]

Output: Description of the colour space (in the form of an International Color Consortium (ICC) profile) to which the samples in the image conform.

Portable Network Graphics (PNG) Specification (Second Edition)


Input: [Type of information] Image histogram [Description]

Output: Estimates of how frequently the image uses each palette entry.

Portable Network Graphics (PNG) Specification (Second Edition)


Input: [Type of information] Physical pixel dimensions [Description]

Output: Intended pixel size and aspect ratio to be used in presenting the PNG image.

Portable Network Graphics (PNG) Specification (Second Edition)


Input: [Type of information] Significant bits [Description]

Output: The number of bits that are significant in the samples.

Portable Network Graphics (PNG) Specification (Second Edition)


Input: [Type of information] sRGB colour space [Description]

Output: A rendering intent (as defined by the International Color Consortium) and an indication that the image samples conform to this colour space.

Portable Network Graphics (PNG) Specification (Second Edition)


Input: [Type of information] Suggested palette [Description]

Output: A reduced palette that may be used when the display device is not capable of displaying the full range of colours in the image.

Portable Network Graphics (PNG) Specification (Second Edition)


Input: [Type of information] Textual data [Description]

Output: Textual information (which may be compressed) associated with the image.

Portable Network Graphics (PNG) Specification (Second Edition)


Input: [Type of information] Time [Description]

Output: The time when the PNG image was last modified.

Portable Network Graphics (PNG) Specification (Second Edition)


Input: [Type of information] Transparency [Description]

Output: Alpha information that allows the reference image to be reconstructed when the alpha channel is not retained in the PNG image.

Portable Network Graphics (PNG) Specification (Second Edition)


Input: [Identifier] Agreement [Semantics] Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved. [Comment]

Output: Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.1: Terms for the entity Type of the Policy Entity


Input: [Identifier] Offer [Semantics] Policy expressions that propose terms of usage from an Asset owner [Comment]

Output: Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Privacy [Semantics] Policy expressions that stipulate the terms of usage over personal information. [Comment]

Output: Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Request [Semantics] Policy expressions that propose terms of usage to an Asset owner [Comment]

Output: Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Set [Semantics] Policy expressions that consists of entities from the complete model [Comment]

Output: The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Ticket [Semantics] Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession [Comment]

Output: May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known).

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Notation] {$ rule text $} [Interpretation]

Output: Emit the rule text substituting any occurrence of variables from the binding map. The outer {$ $} can be omitted in cases where there is no ambiguity.


Input: [Notation] for(?elt in ?list) { template } [Interpretation]

Output: ?list is a variable in the pattern which is bound to an RDF List. The for operator iterates over each element of the ?list in turn replacing the binding map for the ?elt variable with the next list entry and processes the enclosed template in the context of that new binding map.


Input: [Notation] for(?elt in ?list, != ?other) { template } [Interpretation]

Output: ?list is a variable in the pattern which is bound to an RDF List. The for operator iterates over each element of the ?list in turn, skipping any element identical to ?other , replacing the binding map for the ?elt variable with the next list entry and processes the enclosed template in the context of that new binding map.


Input: [Notation] $length(?list)$ [Interpretation]

Output: Used within a template this will be replaced by the length the RDFList bound to ?list.


Input: [Notation] $i$ [Interpretation]

Output: Used within a for(?elt in ?list){ template } this will be replaced by the index of the current ?elt.


Input: [Notation] $i+1$ [Interpretation]

Output: Used within a for(?elt in ?list){ template } this will be replaced by the index of the current ?elt, plus 1.


Input: [State] Hidden [Data type] An arbitrary string [Control type] n/a [Keyword]

Output: hidden

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Text [Data type] Text with no line breaks [Control type] Text field [Keyword]

Output: text

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Search [Data type] Text with no line breaks [Control type] Search field [Keyword]

Output: search

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Telephone [Data type] Text with no line breaks [Control type] A text field [Keyword]

Output: tel

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] URL [Data type] An absolute IRI [Control type] A text field [Keyword]

Output: url

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] E-mail [Data type] An e-mail address or list of e-mail addresses [Control type] A text field [Keyword]

Output: email

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Password [Data type] Text with no line breaks (sensitive information) [Control type] Text field that obscures data entry [Keyword]

Output: password

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Date and Time [Data type] A date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC [Control type] A date and time control [Keyword]

Output: datetime

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Date [Data type] A date (year, month, day) with no time zone [Control type] A date control [Keyword]

Output: date

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Month [Data type] A date consisting of a year and a month with no time zone [Control type] A month control [Keyword]

Output: month

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Week [Data type] A date consisting of a week-year number and a week number with no time zone [Control type] A week control [Keyword]

Output: week

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Time [Data type] A time (hour, minute, seconds, fractional seconds) with no time zone [Control type] A time control [Keyword]

Output: time

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Local Date and Time [Data type] A date and time (year, month, day, hour, minute, second, fraction of a second) with no time zone [Control type] A date and time control [Keyword]

Output: datetime-local

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Number [Data type] A numerical value [Control type] A text field or spinner control [Keyword]

Output: number

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Range [Data type] A numerical value, with the extra semantic that the exact value is not important [Control type] A slider control or similar [Keyword]

Output: range

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Color [Data type] An sRGB color with 8-bit red, green, and blue components [Control type] A color well [Keyword]

Output: color

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Checkbox [Data type] A set of zero or more values from a predefined list [Control type] A checkbox [Keyword]

Output: checkbox

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Radio Button [Data type] An enumerated value [Control type] A radio button [Keyword]

Output: radio

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] File Upload [Data type] Zero or more files each with a MIME type and optionally a file name [Control type] A label and a button [Keyword]

Output: file

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Submit Button [Data type] An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission [Control type] A button [Keyword]

Output: submit

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Image Button [Data type] A coordinate, relative to a particular image's size, with the extra semantic that it must be the last value selected and initiates form submission [Control type] Either a clickable image, or a button [Keyword]

Output: image

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Reset Button [Data type] n/a [Control type] A button [Keyword]

Output: reset

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [State] Button [Data type] n/a [Control type] A button [Keyword]

Output: button

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Identifier] Individual [Comment] Must be supported. [Semantics]

Output: The Party is a single individual

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.4.2: Terms for the attribute “scope” of the entity Role


Input: [Identifier] Group [Comment] Must be supported. [Semantics]

Output: The Party represents a defined group with multiple individual members

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] All [Comment] For example, may be used to indicate all the users of a specific social network the party is a member of. Note that “group” scope is also assumed. [Semantics]

Output: All the collective individuals within a context

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] AllConnections [Comment] For example, may be used to indicate all “friends” of the Party. Note that “group” scope is also assumed. [Semantics]

Output: All the first-level connections of the Party

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] All2ndConnections [Comment] For example, may be used to indicate all “friends of friends” of the Party. Note that “group” scope is also assumed. [Semantics]

Output: All the second-level connections of the Party

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] AllGroups [Comment] For example, may be used to indicate all groups that the Party is a member of. Note that “group” scope is also assumed. [Semantics]

Output: All the group connections of the Party

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [dynamic.] clickstream.client [Category] Navigation and Click-stream Data [Type] text [Short display name]

Output: Click-stream collected on the client


Input: [dynamic.] clickstream.server [Category] Navigation and Click-stream Data [Type] text [Short display name]

Output: Click-stream collected on the server


Input: [dynamic.] cookies [Category] (variable-category) [Type] text [Short display name]

Output: Cookies are processed (read/write)


Input: [dynamic.] http.useragent [Category] Computer Information [Type] text [Short display name]

Output: User Agent information


Input: [dynamic.] http.referrer [Category] Navigation and Click-stream Data [Type] uri [Short display name]

Output: Last URI requested by the user


Input: [dynamic.] miscdata [Category] (variable-category) [Type] text [Short display name]

Output: Miscellaneous non-base data schema information


Input: [dynamic.] searchtext [Category] Interactive Data [Type] text [Short display name]

Output: Search terms


Input: [dynamic.] interactionrecord [Category] Interactive Data [Type] text [Short display name]

Output: Server stores the transaction history


Input: [user] name [Category] Physical Contact Information, Demographic and Socioeconomic Data [Short display name] User's Name [Structure]

Output: personname

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] bdate [Category] Demographic and Socioeconomic Data [Short display name] User's Birth Date [Structure]

Output: date

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] cert [Category] Unique Identifiers [Short display name] User's Identity Certificate [Structure]

Output: certificate

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] gender [Category] Demographic and Socioeconomic Data [Short display name] User's Gender (male or female) [Structure]

Output: unstructured

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] employer [Category] Demographic and Socioeconomic Data [Short display name] User's Employer [Structure]

Output: unstructured

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] department [Category] Demographic and Socioeconomic Data [Short display name] Department or division of organization where user is employed [Structure]

Output: unstructured

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] jobtitle [Category] Demographic and Socioeconomic Data [Short display name] User's Job Title [Structure]

Output: unstructured

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] home-info [Category] Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data [Short display name] User's Home Contact Information [Structure]

Output: contact

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] business-info [Category] Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data [Short display name] User's Business Contact Information [Structure]

Output: contact

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user.] name. [Category] Physical Contact Information, Demographic and Socioeconomic Data [Type] personname. [Short display name]

Output: User's Name


Input: [user.] bdate. [Category] Demographic and Socioeconomic Data [Type] date. [Short display name]

Output: User's Birth Date


Input: [user.] cert. [Category] Unique Identifiers [Type] certificate [Short display name]

Output: User's Identity Certificate


Input: [user.] gender [Category] Demographic and Socioeconomic Data [Type] gender [Short display name]

Output: User's Gender


Input: [user.] employer [Category] Demographic and Socioeconomic Data [Type] text [Short display name]

Output: User's Employer


Input: [user.] department [Category] Demographic and Socioeconomic Data [Type] text [Short display name]

Output: Department or division of organization where user is employed


Input: [user.] jobtitle [Category] Demographic and Socioeconomic Data [Type] text [Short display name]

Output: User's Job Title


Input: [user.] home. [Category] Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data [Type] contact. [Short display name]

Output: User's Home Contact Information


Input: [user.] business. [Category] Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data [Type] contact. [Short display name]

Output: User's Business Contact Information


Input: [Category] Navigation and click-stream data [Structure] uri [Short display name] URI of requested resource [loginfo]

Output: uri

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Category] Navigation and click-stream data [Structure] date [Short display name] Request timestamp [loginfo]

Output: timestamp

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Category] Computer Information [Structure] ipaddr [Short display name] Client's IP address or hostname [loginfo]

Output: clientip

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Category] Navigation and click-stream data [Structure] unstructured [Short display name] HTTP request method [loginfo]

Output: other.httpmethod

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Category] Navigation and click-stream data [Structure] unstructured [Short display name] Data bytes in response [loginfo]

Output: other.bytes

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Category] Navigation and click-stream data [Structure] unstructured [Short display name] Response status code [loginfo]

Output: other.statuscode

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Property] type [Type] xs:string [Value]

Output: The name of the event.


Input: [Property] bubbles [Type] xs:boolean [Value]

Output: Indicates whether or not an event is a bubbling event. If the event can bubble the value is true, else the value is false.


Input: [Property] cancelable [Type] xs:boolean [Value]

Output: Indicates whether or not an event can have its default action prevented. If the default action can be prevented the value is true, else the value is false.


Input: [Property] targetid [Type] xs:string? [Value]

Output: The id of the target to which the event was originally dispatched. If the target does not have an id an empty sequence is returned.


Input: [Property] current-targetid [Type] xs:string? [Value]

Output: The id of the target whose EventListeners are currently being processed. If that target does not have an id an empty sequence is returned.


Input: [Property] event-phase [Type] xs:string [Value]

Output: The current event phase: capture, target, or bubbling (When the event arrives at the target, the value is 'target'. Values capture and bubbling are as described in XML events)


Input: [Property] time-stamp [Type] xs:integer? [Value]

Output: The time (in milliseconds relative to the epoch) at which the event was created. Due to the fact that some systems may not provide this information the value of timeStamp may be not available for all events. When not available, an empty sequence will be returned. Examples of epoch time are the time of the system start or 0:0:0 UTC 1st January 1970.


Input: [Additive?] yes ['set'] yes ['animate Color'] no ['animate Transform'] no ['animate']

Output: yes


Input: [Additive?] yes ['set'] yes ['animate Color'] yes ['animate Transform'] no [Notes] Only RGB color values are additive. ['animate']

Output: yes


Input: [Additive?] no ['set'] no ['animate Color'] no ['animate Transform'] no ['animate']

Output: no


Input: [Additive?] no ['set'] yes ['animate Color'] no ['animate Transform'] no ['animate']

Output: yes


Input: [Additive?] yes ['set'] no ['animate Color'] no ['animate Transform'] yes [Notes] Additive means that a transformation is post-multiplied to the base set of transformations. ['animate']

Output: no


Input: [Data type] All other data types used in animatable attributes and properties [Additive?] no ['set'] yes ['animate Color'] no ['animate Transform'] no ['animate']

Output: yes


Input: [Details] Using valid HTML means having an HTML code that follows one of the DTDs of the HTML specification. Your best choice is valid XHTML strict markup: XHTML means that the code will benefit from all the XML power, and strict ensures your site won't mix presentation markup with the structure. [Rationale] Valid HTML code is a first step toward more compatibility with browsers and better rendering on the latest ones. Using only strict HTML (that is, the Strict HTML DTD) makes the site easier to maintain and evolve. [Test tool] The W3C HTML Validator is one of the many options available. The LogValidator is especially helpful in maintaining a valid Web site. [Requirement]

Output: Use valid (X)HTML

Buy standards compliant Web sites — W3C QA


Input: [Details] Avoid any presentational markup and keep all the layout features in well-defined CSS style sheets. [Rationale] Linked style sheets allow presentation to be decoupled completely from the page structure of your site, and lets you quickly change its layout and rendering. It also guarantees that everybody can adjust the rendering to their needs and tastes. [Test tool] The CSS Validator detects any non-compliant use of the CSS technologies. [Requirement]

Output: Use extensively valid CSS

Buy standards compliant Web sites — W3C QA


Input: [Details] Make sure that each page of your site is accessible with a stable address (URL) and that the HTTP caching properties are set correctly. Make sure if you migrate to a new site version that the URLs are either kept as is or at least redirected to the new ones. [Rationale] HTTP is a very powerful protocol and you get most of its power with stable URLs and an efficient caching system: bookmarks and links don't break, network access is faster, users are happy! [Test tool] The W3C Link Checker can provide some help. Besides, the advices given in the Common HTTP Implementation Problems Note can help assess what needs to be respected. [Requirement]

Output: Use HTTP properly

Buy standards compliant Web sites — W3C QA


Input: [Details] Use PNG for raster images, and SVG for all others. [Rationale] PNG is a much more capable format than other binary formats for raster images because it provides better compression, more options, and it's free. The best format you should require is SVG: it's scalable, XML-based, very light, and has a lot of capabilities, for example, animation using SMIL, which is supported on cell phones, etc. [Test tool] N/A [Requirement]

Output: Use SVG and PNG for graphics

Buy standards compliant Web sites — W3C QA


Input: [Details] Details. [Rationale] Making a site accessible benefits all of your users, and broadens your current audience. This requirement may be required by law in some countries. [Test tool] See Evaluation Tools for Web Content Accessibility. [Requirement]

Output: Use techniques to make your content accessible

Buy standards compliant Web sites — W3C QA


Input: [Details] Use the DOM API combined with Ecmascript (but don't make the use of scripts mandatory to navigate in the site!). [Rationale] DOM and Ecmascript (the common standard behind Javascript and JScript) are the best way to go to get interoperable scripts to create animations in your Web site. But do not forget your users that don't have these scripting capacities enabled. [Test tool] N/A [Requirement]

Output: Use standards scripting languages

Buy standards compliant Web sites — W3C QA


Input: [Identifier] Agreement [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former. [Semantics]

Output: Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Offer [Comment] Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party. [Semantics]

Output: Policy expressions that propose terms of usage from an Asset owner

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Privacy [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner. [Semantics]

Output: Policy expressions that stipulate the terms of usage over personal information.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Request [Comment] Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party. [Semantics]

Output: Policy expressions that propose terms of usage to an Asset owner

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Set [Comment] The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party. [Semantics]

Output: Policy expressions that consists of entities from the complete model

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Ticket [Comment] May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known). [Semantics]

Output: Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved. [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former. [Identifier]

Output: Agreement

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that propose terms of usage from an Asset owner [Comment] Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party. [Identifier]

Output: Offer

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that stipulate the terms of usage over personal information. [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner. [Identifier]

Output: Privacy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that propose terms of usage to an Asset owner [Comment] Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party. [Identifier]

Output: Request

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that consists of entities from the complete model [Comment] The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party. [Identifier]

Output: Set

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession [Comment] May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known). [Identifier]

Output: Ticket

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [user.] name. [Type] personname. [Short display name] User's Name [Category]

Output: Physical Contact Information, Demographic and Socioeconomic Data


Input: [user.] bdate. [Type] date. [Short display name] User's Birth Date [Category]

Output: Demographic and Socioeconomic Data


Input: [user.] cert. [Type] certificate [Short display name] User's Identity Certificate [Category]

Output: Unique Identifiers


Input: [user.] gender [Type] gender [Short display name] User's Gender [Category]

Output: Demographic and Socioeconomic Data


Input: [user.] employer [Type] text [Short display name] User's Employer [Category]

Output: Demographic and Socioeconomic Data


Input: [user.] department [Type] text [Short display name] Department or division of organization where user is employed [Category]

Output: Demographic and Socioeconomic Data


Input: [user.] jobtitle [Type] text [Short display name] User's Job Title [Category]

Output: Demographic and Socioeconomic Data


Input: [user.] home. [Type] contact. [Short display name] User's Home Contact Information [Category]

Output: Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data


Input: [user.] business. [Type] contact. [Short display name] User's Business Contact Information [Category]

Output: Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data


Input: [Semantics] The Assigner requires that the Assignee(s) accepts that the use of the Asset may be tracked [Comment] The collected information may be tracked by the Assigner, or may link to a Party with the role function “trackingParty”. [Identifier]

Output: acceptTracking

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.2.2: Terms for entity Action used with Duty


Input: [Semantics] The Assigner requires that the Assignee(s) attributes the Asset to the Assigner or an attributed Party. [Comment] May link to an Asset with the attribution information. May link to a Party with the role function “attributedParty”. [Identifier]

Output: attribute

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) compensates the Assigner (or other specified compensation Party) by some amount of value, if defined, for use of the Asset. [Comment] The compensation may use different types of things with a value: – the thing is expressed by the value (term) of the Constraint name – the value is expressed by operator, rightOperand, dataType and unit [Identifier]

Output: compensate

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) permanently removes all copies of the Asset. [Comment] Use a constraint to define under which conditions the Asset should be deleted. [Identifier]

Output: delete

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assignee requires that the Assigner(s) ensure(s) that the permission on the Asset is exclusive to the Assignee. [Identifier]

Output: ensureExclusivity

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) include(s) other related assets in the Asset. [Comment] For example; Bio picture must be included in the attribution. Use of the Asset relation attribute is required [Identifier]

Output: include

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) inform(s) the Assigner or an informed Party that an action has been performed on or in relation to the Asset. [Comment] May link to a Party with the role function “informedParty”. [Identifier]

Output: inform

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) grants the specified Policy to a third party for their use of the Asset. [Identifier]

Output: nextPolicy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) obtains explicit consent from the Assigner or a consenting Party to perform the requested action in relation to the Asset. [Comment] Used as a Duty to ensure that the Assigner or a Party is authorized to approve such actions on a case-by-case basis. May link to a Party with the role function “consentingParty”. [Identifier]

Output: obtainConsent

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) has(ve) a person review the Policy applicable to the Asset. [Comment] Used when human intervention is required to review the Policy. May link to an Asset which represents the full Policy information. [Identifier]

Output: reviewPolicy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) unload(s) and delete(s) the computer program Asset from a storage device and disable(s) its readiness for operation. [Comment] The Asset is no longer accessible to the Assignee(s). [Identifier]

Output: uninstall

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) apply(ies) a watermark as provided by the Assigner to the Asset. [Comment] It is recommended to embed a link to the watermark. [Identifier]

Output: watermark

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] acceptTracking [Semantics] The Assigner requires that the Assignee(s) accepts that the use of the Asset may be tracked [Comment]

Output: The collected information may be tracked by the Assigner, or may link to a Party with the role function “trackingParty”.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] attribute [Semantics] The Assigner requires that the Assignee(s) attributes the Asset to the Assigner or an attributed Party. [Comment]

Output: May link to an Asset with the attribution information. May link to a Party with the role function “attributedParty”.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] compensate [Semantics] The Assigner requires that the Assignee(s) compensates the Assigner (or other specified compensation Party) by some amount of value, if defined, for use of the Asset. [Comment]

Output: The compensation may use different types of things with a value: – the thing is expressed by the value (term) of the Constraint name – the value is expressed by operator, rightOperand, dataType and unit

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] delete [Semantics] The Assigner requires that the Assignee(s) permanently removes all copies of the Asset. [Comment]

Output: Use a constraint to define under which conditions the Asset should be deleted.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] include [Semantics] The Assigner requires that the Assignee(s) include(s) other related assets in the Asset. [Comment]

Output: For example; Bio picture must be included in the attribution. Use of the Asset relation attribute is required

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] inform [Semantics] The Assigner requires that the Assignee(s) inform(s) the Assigner or an informed Party that an action has been performed on or in relation to the Asset. [Comment]

Output: May link to a Party with the role function “informedParty”.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] obtainConsent [Semantics] The Assigner requires that the Assignee(s) obtains explicit consent from the Assigner or a consenting Party to perform the requested action in relation to the Asset. [Comment]

Output: Used as a Duty to ensure that the Assigner or a Party is authorized to approve such actions on a case-by-case basis. May link to a Party with the role function “consentingParty”.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] reviewPolicy [Semantics] The Assigner requires that the Assignee(s) has(ve) a person review the Policy applicable to the Asset. [Comment]

Output: Used when human intervention is required to review the Policy. May link to an Asset which represents the full Policy information.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] uninstall [Semantics] The Assigner requires that the Assignee(s) unload(s) and delete(s) the computer program Asset from a storage device and disable(s) its readiness for operation. [Comment]

Output: The Asset is no longer accessible to the Assignee(s).

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] watermark [Semantics] The Assigner requires that the Assignee(s) apply(ies) a watermark as provided by the Assigner to the Asset. [Comment]

Output: It is recommended to embed a link to the watermark.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Requirement] Alarm API [Source] SysApps Charter [Description]

Output: Applications can create alarms, notifying users

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Contacts API [Source] SysApps Charter [Description]

Output: Apps can add, remove and edit contacts

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Messaging API [Source] SysApps Charter [Description]

Output: Apps can send, receive and view SMS

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Telephony API [Source] SysApps Charter [Description]

Output: Apps can access the telephony capabilities of the underlyling platform: dial a number, pick up a call, route to voicemail, access the call log

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Raw Sockets API [Source] SysApps Charter [Description]

Output: Apps can create, manipulate and listen for low-level TCP and UDP connections

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Supports many device form factors [Source] SysApps Charter [Implications] The security model can make no assumptions about how the device will be used or shared between people and cannot assume a particular process model. [Description]

Output: Supports a wide variety of devices including desktop & laptop computers, smart phones, tablets, TVs, cameras, and other connected devices

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] DAP API Support [Source] SysApps Charter [Implications] Either DAP APIs will need to change slightly in the systems context or the security model must allow for API-specific access controls [Description]

Output: All APIs defined by DAP should be accessible to system applications

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Minimal user prompting [Source] SysApps Charter [Implications] Some details of the expected user interactions may need to be specified in the security model or APIs [Description]

Output: Problems such as 'double prompting' should be avoided when integrating other APIs

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] HTML5 [Description]

Output: Applications consist of HTML, CSS and JavaScript

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Location [Description]

Output: Applications have access to geolocation data

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Communicate with other applications [Implications] Some kind of messaging will be supported [Description]

Output: Applications can communicate with other applications

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Communicate with pre-defined endpoints [Implications] Access remote domains will be possible [Description]

Output: Applications can communicate with pre-defined web addresses

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Valid across multiple platforms [Source] Compatibility of application packages [Description]

Output: Applications can run on any conformant platform, potentially including any device form factor

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Access control log [Source] webinos [Description]

Output: Allow access control decisions to be logged.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] API access rationale [Source] webinos [Description]

Output: Applications shall be able to explain why access to data or APIs is being requested.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Application capability restriction [Source] webinos [Description]

Output: Applications shall access only its specified device features, extensions and content.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Application intent [Source] webinos [Description]

Output: Applications shall specify its required functionality at install time or during updates.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Application isolation [Source] webinos [Description]

Output: Applications shall be isolated from each other.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Application policy approval [Source] webinos [Description]

Output: Changes to existing application intentions and permissions shall be approved by the end user.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Authenticity check [Source] webinos [Description]

Output: Before being installed or updated, origin authenticity and integrity checks shall be performed by the runtime

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Certifier list [Source] webinos [Description]

Output: The list of authorities that certified an application shall be viewable by end-users.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Confidential credentials storage [Source] webinos [Description]

Output: The webinos runtime shall support the confidential storage of user credentials.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Credentials access restriction [Source] webinos [Description]

Output: Access to credentials storage shall be limited to a specific user, a specific device and a set of applications.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Data management rationale [Source] webinos [Description]

Output: applications shall be able to explain how collected sensitive data will be managed.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Default policy [Source] webinos [Description]

Output: A default security and privacy policy shall exist an be enforced on each conformant runtime

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Device-identity binding [Source] webinos [Description]

Output: Personal devices shall be bound to their owner's identities.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Device-identity binding revokation [Source] webinos [Description]

Output: The binding between personal devices and owner's identity shall be revokable.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Hierarchical policy enforcement [Source] webinos [Description]

Output: Runtimes can enforce multiple access control rules written by multiple stakeholders in a hierarchy.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Secure cache [Source] webinos [Description]

Output: Data cached by a runtime shall be securely stored to prevent disclosure and tampering by unauthorised entitites.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Secure storage [Source] webinos [Description]

Output: Application data shall be securely stored to prevent disclosure and tampering by unauthorised entities.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Trusted application source [Source] webinos [Implications] Apps must have provenance data attached to them [Description]

Output: When installing or using an application for the first time, the runtime shall establish that the user trusts the source of the application.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] App stores can revoke applications [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] App permissions can be changed remotely [Description]

Output: "An app store needs to be able to approve an application, implying they can verify the permissions, integrity and authenticity of the app"

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] External trusted party can set app default permissions [Source] Extrapolated from B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] The user is not the only source of access control decisions. this also suggests a need for conflict resolution. [Description]

Output: B2G: "App store must be able to set the default permissions for an app".

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Installation [Source] B2G, webinos [Description]

Output: Applications must be installed before executed

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Owner override [Source] B2G (user), webinos (user) [Implications] Access control settings must be changeable [Description]

Output: The device owner must be able to override app settings and permissions (this may not be the user, but a corporate, for example)

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] App privilege visibility [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] There must be a standard way for applications to identify the permissions they have and lack [Description]

Output: Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Permission usability [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Description]

Output: Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Immunity to browser-based threats [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] Non-browser security context: may be additional restrictions on HTML/JavaScript [Description]

Output: Apps should not be vulnerable to common web vulnerabilities when granted significant privileges

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Pre-installed app permissions [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] Different 'levels' apply to SysApps - possibly 'roles' [Description]

Output: Ability to grant trust for certain highly sensitive privileges (such as phone dialing) may be restricted at the OS level to specific trusted parties

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Access to files outside owned by the platform [Source] Mailing list: http://lists.w3.org/Archives/Public/public-sysapps/2012Nov/0003.html [Implications] Need to provide both sandboxed and non-sandboxed storage [Description]

Output: Ability for a system application to access (read and write) files outside of that application's sandboxed storage area.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Keyword] hidden [Data type] An arbitrary string [Control type] n/a [State]

Output: Hidden

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] text [Data type] Text with no line breaks [Control type] Text field [State]

Output: Text

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] search [Data type] Text with no line breaks [Control type] Search field [State]

Output: Search

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] tel [Data type] Text with no line breaks [Control type] A text field [State]

Output: Telephone

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] url [Data type] An absolute IRI [Control type] A text field [State]

Output: URL

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] email [Data type] An e-mail address or list of e-mail addresses [Control type] A text field [State]

Output: E-mail

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] password [Data type] Text with no line breaks (sensitive information) [Control type] Text field that obscures data entry [State]

Output: Password

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] datetime [Data type] A date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC [Control type] A date and time control [State]

Output: Date and Time

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] date [Data type] A date (year, month, day) with no time zone [Control type] A date control [State]

Output: Date

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] month [Data type] A date consisting of a year and a month with no time zone [Control type] A month control [State]

Output: Month

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] week [Data type] A date consisting of a week-year number and a week number with no time zone [Control type] A week control [State]

Output: Week

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] time [Data type] A time (hour, minute, seconds, fractional seconds) with no time zone [Control type] A time control [State]

Output: Time

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] datetime-local [Data type] A date and time (year, month, day, hour, minute, second, fraction of a second) with no time zone [Control type] A date and time control [State]

Output: Local Date and Time

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] number [Data type] A numerical value [Control type] A text field or spinner control [State]

Output: Number

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] range [Data type] A numerical value, with the extra semantic that the exact value is not important [Control type] A slider control or similar [State]

Output: Range

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] color [Data type] An sRGB color with 8-bit red, green, and blue components [Control type] A color well [State]

Output: Color

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] checkbox [Data type] A set of zero or more values from a predefined list [Control type] A checkbox [State]

Output: Checkbox

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] radio [Data type] An enumerated value [Control type] A radio button [State]

Output: Radio Button

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] file [Data type] Zero or more files each with a MIME type and optionally a file name [Control type] A label and a button [State]

Output: File Upload

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] submit [Data type] An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission [Control type] A button [State]

Output: Submit Button

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] image [Data type] A coordinate, relative to a particular image's size, with the extra semantic that it must be the last value selected and initiates form submission [Control type] Either a clickable image, or a button [State]

Output: Image Button

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] reset [Data type] n/a [Control type] A button [State]

Output: Reset Button

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Keyword] button [Data type] n/a [Control type] A button [State]

Output: Button

4.10.7 The input element — HTML5 (Edition for Web Authors)


Input: [Id: Title] WAI-1 : Scope of expressions [State] agreed [Ack.] No reply from reviewer [Type]

Output: clarification

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] WAI-2 : Model best practice in examples [State] agreed [Ack.] No reply from reviewer [Type]

Output: clarification

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] froumentin-2 : typos in spec [State] agreed [Ack.] No reply from reviewer [Type]

Output: editorial

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] froumentin-3 : section 5 reorganisation [State] agreed [Ack.] No reply from reviewer [Type]

Output: editorial

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Harold-1 : Violation of separation of content from presentation [State] agreed [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-11 : Must use namespaces [State] agreed [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-12 : Importing Attribute Value Templates [State] agreed [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-13 : Delivery Context Namespace [State] agreed [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-14 : content of the if element [State] agreed [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-15 : body content is non-standard terminology [State] agreed [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-17 : Exception handling part 2 [State] agreed [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] HTML-1 : Violation of separation of content from presentation [State] agreed [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-3 : Interactive option [State] agreed [Ack.] No reply from reviewer [Type]

Output: proposal

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-4 : CSS Class Terminology [State] agreed [Ack.] No reply from reviewer [Type]

Output: proposal

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-10 : process=once [State] agreed [Ack.] No reply from reviewer [Type]

Output: proposal

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Sathish-1 : minor editorial comments [State] agreed [Ack.] Agreement [Type]

Output: clarification

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] McCathieNevile-3 : Default id attribute [State] agreed [Ack.] Agreement [Type]

Output: clarification

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] froumentin-1 : make function xpath2 compatible [State] agreed [Ack.] Agreement [Type]

Output: proposal

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] McCathieNevile-1 : Window Size [State] declined [Ack.] No reply from reviewer [Type]

Output: clarification

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] McCathieNevile-2 : Minimum Font Size [State] declined [Ack.] No reply from reviewer [Type]

Output: clarification

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] McCathieNevile-4 : Screen resolution units [State] declined [Ack.] No reply from reviewer [Type]

Output: clarification

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] McCathieNevile-5 : Author control of re-rendering [State] declined [Ack.] No reply from reviewer [Type]

Output: clarification

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Seeman-1 : Cannot apply DISelect to a doc that doesn't contain DISelect [State] declined [Ack.] No reply from reviewer [Type]

Output: editorial

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Harold-2 : Use of < and > in XML based language is confusing [State] declined [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-2 : User overriding author's precept [State] declined [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-16 : Exception handling part 1 [State] declined [Ack.] No reply from reviewer [Type]

Output: error

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-1 : Author proposes, user disposes [State] declined [Ack.] No reply from reviewer [Type]

Output: proposal

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-5 : Append to class, don't replace it [State] declined [Ack.] No reply from reviewer [Type]

Output: proposal

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-6 : Scope of expressions [State] declined [Ack.] No reply from reviewer [Type]

Output: proposal

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-8 : The 'em' length unit [State] declined [Ack.] No reply from reviewer [Type]

Output: proposal

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-9 : Inconsistent show/hide policy [State] declined [Ack.] No reply from reviewer [Type]

Output: proposal

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] Gilman-7 : How to get this across [State] declined [Ack.] No reply from reviewer [Type]

Output: request

Issues for the LCWD of Content Selection for Device Independence


Input: [Id: Title] McCathieNevile-6 : Link to Table of Contents [State] declined [Ack.] Objection [Type]

Output: editorial

Issues for the LCWD of Content Selection for Device Independence


Input: [Keyword] hidden [State] Hidden [Control type] n/a [Data type]

Output: An arbitrary string

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] text [State] Text [Control type] A text field [Data type]

Output: Text with no line breaks

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] search [State] Search [Control type] Search field [Data type]

Output: Text with no line breaks

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] tel [State] Telephone [Control type] A text field [Data type]

Output: Text with no line breaks

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] url [State] URL [Control type] A text field [Data type]

Output: An absolute URL

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] email [State] E-mail [Control type] A text field [Data type]

Output: An e-mail address or list of e-mail addresses

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] password [State] Password [Control type] A text field that obscures data entry [Data type]

Output: Text with no line breaks (sensitive information)

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] datetime [State] Date and Time [Control type] A date and time control [Data type]

Output: A date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] date [State] Date [Control type] A date control [Data type]

Output: A date (year, month, day) with no time zone

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] month [State] Month [Control type] A month control [Data type]

Output: A date consisting of a year and a month with no time zone

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] week [State] Week [Control type] A week control [Data type]

Output: A date consisting of a week-year number and a week number with no time zone

4.10.7 The input element — HTML5: Edition for Web Authors


Input: [Keyword] time [State] Time [Control type] A time control [Data type]

Output: A time (hour, minute, seconds, fractional seconds) with no time zone

4.10.7 The input element — HTML5: Edition for Web Authors