- From: Chris Lilley <chris@w3.org>
- Date: Wed, 24 Jan 2007 17:53:38 +0100
- To: public-cdf@w3.org
- Cc: Björn Höhrmann <derhoermi@gmx.net>
Hello public-cdf, In this message http://lists.w3.org/Archives/Public/public-cdf/2005Dec/0002.html Bjoern wrote: A) > I've looked at http://www.w3.org/TR/2005/WD-WICDFull-20051219/ and > http://www.w3.org/TR/2005/WD-WICDMobile-20051219/ and I think the > requirements > > * For accessibility, conforming user agents should profile the > option of switching off audio. > to the extend that they make sense should be moved to "WICD Core 1.0" We agree and this is now in WICD Full, with revised wording: http://www.w3.org/TR/2006/WD-WICD-20061122/#doc-audio The use of "profile the option" was indeed confusing. It had noting to do with profiles. It wass saying the user agent should allow the user to set an option in their client so that audio does not play by itself automatically. Instead they are told that there is audio and given the option to play it if they want. Here is what UAAG actually says: http://www.w3.org/TR/UAAG/guidelines.html#tech-configure-multimedia 3.2 Toggle audio, video, animated images (P1) Allow configuration not to render audio, video, or animated image content, except on explicit user request. We have therefore moved the requirement from WICD Full to WICD Core as you suggest, and expressed it using the same wording as UAAG does, including a link to UAAG section 3.2. B) > * For accessibility, conforming user agents must provide the > option of pausing, rewinding, or stopping video. This is similar to A) and again occurred with identical wording in Mobile and Full. We have moved it to Core as you suggest. The relevant quote from UAAG is http://www.w3.org/TR/UAAG/guidelines.html#tech-slow-multimedia 4.4 Slow multimedia (P1) http://www.w3.org/TR/UAAG/guidelines.html#tech-control-multimedia 4.5 Start, stop, pause, and navigate multimedia (P1) The revised wording to address your comments A and B is thus: http://www.w3.org/TR/2006/WD-WICD-20061122/#doc-accessibility-guidelines 4.4 Child content accessibility guidelines For accessibility, conforming WICD Core 1.0 user agents must provide the option of pausing, rewinding, or stopping video. See section 3.2 of [User Agent Accessibility Guidelines 1.0]. For accessibility, conforming WICD Core 1.0 user agents must allow the user to slow the presentation rate of rendered audio and animation content (including video and animated images). See section 4.4 of [User Agent Accessibility Guidelines 1.0]. For accessibility, conforming WICD Core 1.0 user agents must allow the user to stop, pause, and resume rendered audio and animation content (including video and animated images) that last three or more seconds at their default playback rate. They must also allow the user to navigate efficiently within rendered audio and animations (including video and animated images) that last three or more seconds at their default playback rate. See section 4.5 of [User Agent Accessibility Guidelines 1.0]. C) > and the requirements for JFIF, JPEG, PNG support should be spelled out > by changing "WICD Core 1.0" such that any supported bitmap format must > be supported from both XHTML and SVG content; support for the formats > would then be required through requirements in SVG. Note that JPEG is a compression technique and JFIF is a file format that uses the JPEG compression technique. JPEG/JFIF is the correct way to refer to what everyone nowadays calls "JPEG files". Your comment appears to indicate that there are three separate formats. You seemed to be asking for XHTML to support all raster image formats that SVG supports (currently PNG and JPEG/JFIF) rather than explicitly listing them. We could have gone either way on this. A slight advantage for doing it by reference is that if SVG ever adds more formats or removes them, WICD stays in sync. A stronger argument for explicitly listing them is that it is clearer and easier to read. In the end we decided to simply state that PNG and JPEG/JFIF must be supported in XHTML for WICD Core compliance. Its straightforward and easy to test. The revised wording is: http://www.w3.org/TR/2006/WD-WICD-20061122/#doc-raster 4.1 Raster formats The viewer must support JPEG/JFIF [Scalable Vector Graphics (SVG) Tiny 1.2 Specification], PNG [Portable Network Graphics (PNG) Specification (Second Edition)] and GIF 89a (non-interlaced, non-transparent, non-animated) raster image formats. Other image formats may be supported in addition. For PNG, all color types and bit depths shall be supported, gamma correction shall be supported, and any alpha or transparency information shall be used to composite the image onto the background. > Both documents can then be reduced to plain lists (as opposed to the > current line and section noise with confusing inline requirements and a > weird conformance section) of what must be supported by compliant user > agents. Common factors between Mobile And Full have been moved to Core, and places where is is different remain in the individual profiles. > The requirements for content do not make much sense to me; frankly, what > should it say? That you can use any audio format you like, but if you > use script it must be ECMA-262 compliant? That would not make much > sense. It would be great to mandate a particular audio format, but a) the RF ones are not universally implemented, especially on Mobile b) Mobile platforms have by and large already picked their supported audio and video formats, mostly from MPEG and thus not RF. However, just because we can't mandate a format for one area does not mean that we don't for other areas (raster images, scripting languages). D) > There are some related problems here, for example, "WICD Full 1.0" > notes "A conforming style language is CSS" and that implementations > must support that, the specification then also says CSS 2.1 is re- > quired, The wording "conforming style language is CSS" no longer appears in the document. The individual profiles define the level and profile of CSS as appropriate, for example WICD Mobile says Conformant WICD Mobile 1.0 user agents must support the updated version of CSS Mobile Profile 1.0. while WICD Full says Conformant WICD Full 1.0 user agents must support Cascading Style Sheets, level 2 revision 1 [CSS21] specification. E) > and "WICD Core 1.0" requires CSS Media Queries support; I do > not really think it would make sense to define a CSS 2.1 + CSS3MQ > CSS profile specifically for "WICD Full 1.0" conformance. Media queries is discussed in another comment and not considered here. F) > "WICD Mobile 1.0" is confused about whether ECMA-262 or ECMA-327 must > be supported. The current text, in the references, is ECMAScript Language Specification 3rd Edition ECMAScript Language Specification 3rd Edition , European Computer Manufacturers Association, December 1999. Also available as ISO/IEC 16262:2002 G) > "WICD Mobile 1.0" 3.3.1 clarifies the semantics of the 'handheld' media > type, I do not think this is "CDR"-specific in any way, this text should > be moved to the specifications that define the semantics of this type. The current text is in WICD Core http://www.w3.org/TR/2006/WD-WICD-20061122/#conformance A user agent that discovers a CSS style sheet, provided for its own device class (either by media attribute - for instance set to "handheld" - or by a Media Query expression), should assume the content was created with specific properties "in mind". The agent is then expected to deactivate any custom adaptation techniques (for example rendering wide screen content on a narrow screen) and display the intended layout "as is". This does not define, or redefine, the semantics of the CSS 'handheld' media type. H) > I don't think the resulting documents really merit separate technical > reports, and I am not really convinced there is much value in having > special terms for user agents that implement the specified set of > features. The Working Group has moved items which are genuinely common to all WICD profiles to WICD Core, retaining profile-specific information in the actual profiles. Both content conformance and user agent conformance is specified via the individual profiles, which in turn reference the Core. We are informed by content providers, operators, and handset manufacturers that the resultant labelling does indeed have value. Please let us know shortly if these changes do not address your concerns. -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Wednesday, 24 January 2007 16:53:58 UTC