Input: [Commentor] LC-437 Al Gilman on behalf of WAI [Working Group decision] We think that UAAG is out of scope as the document is about delivered content rather than user agents. But after further discussion with the WAI CG, we have added an appendix (Appendix B, Related Reading) linking to the existing WAI Guidelines and Techniques. [Commentor reply] yes [Comment]

Output: User Agent (browser) developers are participants in the mobile value chain. The user agents for mobile devices should conform with UAAG [1] guidelines as appropriate. This is especially true now that some mobile devices have add-on assistive technology such as screen readers. The document's purpose is aimed more at content developers rather than the tools to render the content. Underlying this purpose is a continuing discussion of the limitations of the devices and user agents involved (such as screen size, color depth, input limitations, memory, etc.) [linkage opportunity from WAI document] (1) I can imagine a full version of the doc playing the same role in the ATAG conformance model that WCAG does (i.e. as a standard that an authoring tool guides the author towards conformance with). Perhaps a note to this effect can be put into ATAG 2.0. [linkage opportunity from MWBP document] (2) Clearly all the adaptive stuff in the doc would require authoring tool support. Therefore, the Mobile Web group might consider putting in an informative note about the role of authoring tools (and ATAG) just as WCAG has. This is the text of the WCAG 2.0 note: " A large part of Web content is created using authoring tools. These tools often determine how Web content is implemented, either by making authoring decisions directly or by limiting the choices available to the author. As a result, authoring tools will play an important role in creating Web content that conforms to the Web Content Accessibility Guidelines. At the same time, we recommend that all authors become familiar with the Guidelines because this will help in creating accessible content and coverage of the Guidelines may vary between tools. Developers of authoring tools can help to make their tools more aware of the Web Content Accessibility Guidelines by following the Authoring Tool Accessibility Guidelines. We encourage users and purchasers of authoring tools to consider conformance to the Authoring Tool Accessibility Guidelines as a criterion when selecting tools. "

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-439 Al Gilman on behalf of WAI [Working Group decision] We think this is out of scope since we are not addressing user agents in the document. But after further discussion with the WAI CG, we have added an appendix (Appendix B, Related Reading) linking to the existing WAI Guidelines and Techniques. [Commentor reply] yes [Comment]

Output: 5.29 Refreshing, Redirection, and Spawned Windows should reference UAAG 2.4 Allow time-independent interaction (P1) - 1. For rendered content where user input is only possible within a finite time interval controlled by the user agent, allow configuration to provide a view where user interaction is time-independent. UAAG 3.5 Toggle automatic content retrieval (P1) 1. Allow configuration so that the user agent only retrieves content on explicit user request.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-440 Al Gilman on behalf of WAI [Working Group decision] We have removed that Best Practice, since it didn't have a mobile-specific aspect. [Commentor reply] yes [Comment]

Output: 5.3.7 Background Images should reference UAAG 3.1 Toggle background images (P1) - 1. Allow configuration not to render background image content.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-441 Al Gilman on behalf of WAI [Working Group decision] Out of scope since we are not addressing user agents in the document. But after further discussion with the WAI CG, we have added an appendix (Appendix B, Related Reading) linking to the existing WAI Guidelines and Techniques. [Commentor reply] yes [Comment]

Output: 5.4.3 Structural Elements should reference UAAG 10.4 Provide outline view (P2) - 1. Make available to the user an "outline" view of rendered content, composed of labels for important structural elements (e.g., heading text, table titles, form titles, and other labels that are part of the content).

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-364 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We take your point, but this is the title established by the Group's charter. We have sub-titled the document "basic guidelines" to convey the idea that many more advices could be given. [Commentor reply] no reply from commenter [Comment]

Output: 1. The title of the document is somewhat confusing. The present document is definitely not about best practices for mobile network and system capacity optimization for reliable mobile Web access or other, related technical issues. As the document is providing best design practices of Web sites accessed through a mobile network and a telecommunication terminal, we suggest the title to be updated to “Best Usability Practices for Mobile Web Sites” (in accordance with the last sentence in chapter 1.3.2).

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-365 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] The development of this draft has been somewhat faster than is customary. This is intentional. This is primarily a practical rather than theoretical art and we think there will be great benefit from feedback from implementation. [Commentor reply] no reply from commenter [Comment]

Output: We have the impression that the development process of this draft was somewhat forced to be somewhat too fast. We would recommend to leave more time for stakeholder’s involvement and qualitative fine-tuning, when developing future deliverables.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-369 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We do not wish to limit the scope to connected devices. For example, a periodically synchronised device requires the same best practices for display of web content. [Commentor reply] no reply from commenter [Comment]

Output: A terminology issue: a device does not necessarily have a network connection and a user interface (e.g. a pencil or a wrist watch). We would like to know if this is defined differently for the purpose of this document (the definition is not included in the draft). Otherwise, we consider proposing to use “devices with a network connection and a user interface”, or simply, “terminals”, in the entire document.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-372 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We refer only to ratified documents and not to works in progress. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 1.3, Scope: The WCAG guidelines reference should be more specific, refer to the latest version or relate to the WAI guidelines family, where applicable.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-373 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We have removed the section on usability. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 1.3.2, Usability: - There are more than three aspects of mobile usability but there are three aspects of mobile Web usability (add “Web”). - The relation between these aspects should be described in detail (not only their individual characteristics). This description should include accessibility. - Site usability is not only about effectiveness (see definition of Usability).

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-376 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We feel that the section is sufficently detailed to convey the sense that is intended. It is supposed to background material rather than and exhaustive explanation. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 2.1, Presentation Issues: In addition to the controls not being presented as intended, other issues such as the lack of the necessary interaction control elements and functions should be mentioned.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-377 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] This is background overview section and is not intended to be an exhaustive explanation. We deal with speech/voice in Phase 2. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 2.2, Input: “…hard to type…” should be replaced by “…difficult to enter…”. As this is a far more complex issue than just entering characters, aspects relating to the support, handling, mapping, sorting and transmission of characters should be addressed. This change should also be considered with respect to the fact that speech technology enables and improves access to ICT (including mobile terminal devices and the mobile Web) for disabled people (e.g. people with upper limb impairments) and very young children, who will be able to input data and interact with mobile devices through speech user interfaces.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-378 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] This is background overview section and is not intended to be an exhaustive explanation. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 2.3, Bandwidth and Cost: In addition to transmission speed, there are setup, configuration, access right, reliability, home network cost issues and roaming cost issues involved. These should be addressed or at least, mentioned. See also comment on chapter 1.3.3 above.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-379 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] Please suggest a rewrite or specifics if you think this is especially problematic. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 2.4, User Goals: The first sentence should be rewritten. See also comment on chapter 1.3.3 above.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-381 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] It is the document convention to have introductory text following major headings. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 3, Delivery Model Architecture: The entire section after “3” should be numbered separately (e.g. made 3.1 Introduction).

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-382 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] This BP has been removed. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 5.1.1.2, How to do it: The references should be made more explicit.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-389 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We refer only to ratified recommendations. [Commentor reply] no reply from commenter [Comment]

Output: Annex A, Sources (Non-Normative): It would be highly desirable to reference WCAG 2.0 (under drafting) instead of the outdated 1.0 version from 1999.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-261 Ian Jacobs [Working Group decision] We feel that this is not required, as the document is informative. The work on conformance (and the related disclaimers) will be done in the mobileOK trustmark document. [Commentor reply] yes [Comment]

Output: I suggest "This document only includes best practices that primarily affect mobile access to the Web." You may also wish to have a look at some of the verbiage insection 3of UAAG 1.0 (on Conformance). For instance, adapting this text might be useful: "The UAWG expects conformance this document to be a strong indicator of accessibility, but it may be neither a necessary nor a sufficient condition for ensuring the accessibility of software. Thus, some software may not conform to this document but still be accessible to some users with disabilities. Conversely, some software may conform to this document but still be inaccessible to some users with disabilities. Some requirements of this document may not benefit some users for some content, but the requirements are expected to benefit many users with disabilities, for general purpose content."

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-262 Ian Jacobs [Working Group decision] In the document we refer to Techniques and MobileOK which are currently being written. We can also imagine adaptation guidelines but we are not sure of the exact course. There's also a new User Agent test initiative but it hasn't started yet so we can't reference it. [Commentor reply] yes [Comment]

Output: A very important feature of the WAI Guidelines is that they work together to identify different responsibilities among authors, user agent designers, format designers, and authoring tool designers. WCAG does not hold up well in some cases when browsers don't take advantage of features that authors expect to be supported. Does the MWI BP WG plan to produce other guidelines than these content guidelines?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-269 Ian Jacobs [Working Group decision] We are talking about site usability rather than user agent or device usability, so refering to the User Agent Accessibility guidelines is out of scope (and could possibly create confusion). [Commentor reply] yes [Comment]

Output: As you'll see below, I think you may wish to refer to some of the guidance of theUser Agent Accessibility Guidelinesas well.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-272 Ian Jacobs [Working Group decision] The fact is there remains occasions where the user may have to type a URI (e.g. a not yet indexed site, a non-linked from the outside intranet, following an ad seen on a bus, ...) and that this has proven to be a difficulty to get people even trying to use the Web on mobile devices, so it's definitely worthy to be noted here. [Commentor reply] yes [Comment]

Output: I think the problem is that it's hard to type, period. People should not be typing URIs anyway; they should be using search engines and following links.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-274 Ian Jacobs [Working Group decision] Yes, this is true. However, the contrast is that it is usually expected that personal devices to be configurable; while the mobile phone is very much a personal device, it's rarely configurable. [Commentor reply] yes [Comment]

Output: I note that the previous concern also holds for many desktop environments, including very common one likes in companies or libraries where people often cannot install arbitrary software or configure their machines freely. Is this even more frequent on a mobile device?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-275 Ian Jacobs [Working Group decision] We do have a best practice on the size of pages to send to a mobile device to avoid this memory limitations problems. [Commentor reply] yes [Comment]

Output: Does this mean that you will have best practices for error handling below to avoid incomplete display or other problems?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-286 Ian Jacobs [Working Group decision] Capabilities has been removed [Commentor reply] yes [Comment]

Output: Ah, that last sentence is already more informative in my opinion.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-292 Ian Jacobs [Working Group decision] We think "as is practical" does convey the message that the Working Group has in mind; note that this document is informative and aims at providing guidance to authors, not imposing very specific rules - that will be done in the mobileOK trustmark. [Commentor reply] yes [Comment]

Output: That last sentence is a good place to start for this entire document. But there are other sentences that talk about One Web that might be pithier. I think you can drop "as is practical" and all similar qualifiers in favor of a section in the document about the general authoring context.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-310 Ian Jacobs [Working Group decision] The idea is to be mindful of the users' costs etc and not send them advertising and so on that is not relevant to their needs and at their expense. [Commentor reply] yes [Comment]

Output: * How does this apply to prefetching?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-312 Ian Jacobs [Working Group decision] We have linked CENTRAL_MEANING and CLARITY since they both address the same range of topics. [Commentor reply] yes [Comment]

Output: The previous paragraph is not the same as "limit content to what the user has requested." It is separate advice for good authoring for the Web generally: Front-load pages with important information. You make this point later on, so I think you should move this explanation to later in the document.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-320 Ian Jacobs [Working Group decision] We reference WCAG 1.0 because this is the current W3C Recommendation. [Commentor reply] yes [Comment]

Output: * I think it is very important that this document adopt the language used by the WCAG WG. They have spent a very long time discussing this topic. For instance, for the first point, copying from the 23 Nov 2005 Draft,section 1.3.1: "When information is conveyed by color, the color can be programmatically determined or the information is also conveyed through another means that does not depend on the user's ability to differentiate colors." If you have a reason to say something other than what WCAG 2.0 says, please explain below. (In general, if another W3C Recommendation says what you want, whether it is WCAG 2.0 or UAAG 1.0, Webarch, or another document please use that language or be sure to explain why you have chosen not to.)

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-323 Ian Jacobs [Working Group decision] We don't think there are enough benefits in re-organizing the document around this kind of grouping to justify the cost of actually doing it. Also, this allows to put the focus on specific concerns rather than on general principles. [Commentor reply] yes [Comment]

Output: * A theme has emerged: "Keep it short". I think you have points related to shortness of URIs, titles, and pages. Perhaps they can be merged.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-324 Ian Jacobs [Working Group decision] The text already reads: "Many mobile clients do not support frames. In addition, frames are recognized as being generally problematic." [Commentor reply] yes [Comment]

Output: * Please provide a bit more rationale, as in "Because they are not widely supported in the mobile context and also are widely known to be problematic for users, do not use HTML frames."

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-326 Ian Jacobs [Working Group decision] As already noted, we don't think the benefits of grouping outweighs the costs. [Commentor reply] yes [Comment]

Output: * This is another instance of "Don't do X" when you are outside the default delivery context; regroup with those?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-328 Ian Jacobs [Working Group decision] The text already reads: "Resizing images at the server [...] reduces amount of data transferred and the amount of processing the client has to carry out to scale the image." [Commentor reply] yes [Comment]

Output: * Please provide more rationale for this one, which I did not understand when I first read it. Something like this might help: "Because mobile devices have limited processing capabilities, make available small versions of images rather than require resizing after delivery."

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-329 Ian Jacobs [Working Group decision] The text already reads: "Avoiding pixel and absolute measures allows the browser to adapt content to fit the display." [Commentor reply] yes [Comment]

Output: * Adding more rationale: "To enable flexible display, use relative units (e.g., "em") rather than absolute units (e.g., pixels) when specifying dimensions (e.g., shapes or font sizes) in formats such as markup languages and style sheets."

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-337 Ian Jacobs [Working Group decision] The text already reads: "Given the typical input limitations of a mobile device the interface must as far as possible minimize user input. Where possible, use selection lists, radio boxes and other user interface artifacts that do not require typing." [Commentor reply] yes [Comment]

Output: * Delete "where possible" * Provide more rationale: "Because text entry is time-consuming and prone to error, avoid interfaces (such as text entry boxes) in favor of other types of controls (e.g., menus or radio buttons).

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-338 Ian Jacobs [Working Group decision] As noted above, this leeway is intended given the document focus on guidance rather than mandated rules. [Commentor reply] yes [Comment]

Output: * Delete "where possible"

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-347 Werner Egipsy Souza (Jataayu Software) on behalf of Jataayu Software [Working Group decision] 1. Always on is a feature of many devices aside from Mobile Devices. Data connectivity from mobile devices is usually only established on demand by an active application. 2 and 3. We think that these aspects are out of scope of the Mobile Web. [Commentor reply] no reply from commenter [Comment]

Output: _3.7 Advantages:_ The mobile device has added advantages compared to a desktop or a laptop, which are: 1. Always On:This device is always on, and always has phone connectivity. Hence websites have the ability to directly connect a user with a phone number, or IP address, if the requirement exists. 2. Accessibility to near field devices, via infrared, Wi-fi, bluetooth and USB(but this option is far less used!), such as car audio systems, music players, cameras, gaming devices. 3. Added capability for Wearable computing , where the mobile device may communicate with other devices, using the means mentioned above.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-362 Werner Egipsy Souza on behalf of Jataayu Software [Working Group decision] We think that device limitations is the correct way to make the contrast between the capabilities of a mobile device and those of the desktop, for an audience that is used to delivering content to desktops. [Commentor reply] no reply from commenter [Comment]

Output: 2.6 Device Limitations The word \"Device Limitations\" is not right, The main interest here, should be to to first make note of the fact that the mobile device, has an evolution which is very isolated from the evolution of the PC. The mobile device was evolved from the Telephone, rather than the Desktop PC. Hence, the mobile device as it currently exists, is an advancement of Graham Bell\'s invention, rather than a downgrade of Charles Babbage\'s invention. Where it goes, from there, is an advancement to a cornerstone of the virtual, online, World. The mobile device is slowly becoming a key component of the wearable computing phenomena, where multiple devices, will use the mobile device as a central point of control and storage. Hence \"Differences between the mobile device and the computer\" would be the right word to use.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-363 Werner Egipsy Souza on behalf of Jataayu Software [Working Group decision] 2.7 We're not clear that this is indeed an advantage that is relevant to this phase of Mobile Web Best Practices. 5.2.6 We think this refers to the User Agent and hence out of scope of this document. [Commentor reply] no reply from commenter [Comment]

Output: 2.7 Advantages A point to add: The mobile is destined to be a universal point of data storage, and execution, rather than a data creator. This is greatly due to the various means of device-device communication available to the mobile, such as the operator network, Wi-fi, Infrared, Bluetooth, audio ports and USB ports. 5.2.6 Access KeysAccess keys, should be made accessible, according to prevalent usability standards. One standard, would be that page up and Page Down keys, must be permanently hard-coded, to make navigation of a page, less arduous. One suggested implementation, is to use a slider key for the volume, during the phone mode. Then, when the browser is activated, use the same slider key as a Page Up-Down key.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-400 Zev Blut [Working Group decision] We say that this is relevant when the device does not respect the author's intentions. [Commentor reply] no reply from commenter [Comment]

Output: 5.1.3 Work around deficient implementations “It is recognized that content providers may need to violate specific best practices in order to support their intentions on devices that exhibit deficiencies in implementation. If a device is not known to have specific limitations then content providers must comply with best practices” My question is the use of “must comply” is a bit strong, because there can be cases where developers and the W3C differ in opinion on whether a certain device has limitations. In areas where interpretations differ this may prevent the developer from getting the “mobileOK” mark. Who and or how are agreements going to be made about when a device is known to have specific limitations?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-434 on behalf of I18N WG [Working Group decision] We have added the additional tests to execute in the "what to test" section. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 19 At link Editorial/substantive: S Owner: RI Location in reviewed document: 5.4.12 Comment: The document doesn\'t say that the encoding should be expressed using the HTTP header, so the test should not assume that either. It should probably say something along the lines of \"Check that the encoding is declared. This could be done in the HTTP header or the XML declaration for documents served as XML, or in the HTTP header or the Content-Type meta element for documents served as HTML, or in the HTTP header or the @charset statement for CSS stylesheets.\"

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-435 on behalf of I18N WG [Working Group decision] We have removed the sentence about "the specification of the natural language", clarified that we meant definition of input mode settings, added the relevant tests. We haven't added the encouragement of the declaration of the language as this doesn't have a specific mobile aspect. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 20 At link Editorial/substantive: S Owner: RI Location in reviewed document: 5.5.1 Comment: \"Specification of the natural language in use assists with predictive text input.\" It is unclear to us whether this refers to standard mechanisms in X/HTML to declare language, or to a declaration specific to input modes. That should be made clearer. (If you were referring to input mode settings, we feel it would also be useful to encourage declaration of the language used in content using standard mechanisms, since that assists with not only predictive text input, but also styling, font selection, etc.) Whatever the above refers to, this section contains no other information about how to do it, and how to test for it. This should be added. (The i18n tutorial Declaring Language in XHTML and HTML [link] may be helpful here for you to understand what i mean by \'standard mechanisms...\'.)

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-390 on behalf of Nokia [Working Group decision] We have substantially reworded the Best Practice on balance to clarify that the balance was between the number of links per pages and the number of pages the user has to download to go to his or her intended result. [Commentor reply] no reply from commenter [Comment]

Output: 5.2.3 Balanced Structure It is not clear, whether this is indicating some mathematical balance. We believe a site should be \"balanced semantically or by importance.\" It makes no sense to always make the depth of all links similar. In fact, the first links should be directly to commonly-used information, while later links may lead to a deeper tree of less-often-used features. This is really important to explain well.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-391 on behalf of Nokia [Working Group decision] We have simplified the pair of Best Practices on scrolling into a single best practice, recommending not allow secondary scrolling unless necessary. [Commentor reply] no reply from commenter [Comment]

Output: 5.3.3 Scrolling There could be a stricter recommendation: Limit scrolling while reading a single text flow to one direction.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-392 on behalf of Nokia [Working Group decision] We agreed with this additional principle and generalized it in the Best Practice "EXTERNAL_RESOURCES". [Commentor reply] no reply from commenter [Comment]

Output: 5.3.5 Graphics Proposal for adding a statement [MANY_GRAPHICS]. Avoid many images in one page, because each request on a wireless network adds significant latency compared to fixed networks.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-374 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We already address these issues, but we have slightly revised part of the One Web definition to be more explicit and use the word "representation" (as defined in the DI glossary) in the following text: "As discussed in [Scope] One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However it does not mean that exactly the same information is available in exactly the same representations across all devices. This is due to issues such as the context of mobile use, terminal capability variations, bandwidth issues and mobile network capabilities. Furthermore, some services and information are more suitable for and targeted at particular user contexts." We have also added a link to the Thematic Consistency Best Practice, which give more context on this point. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 1.3.3, One Web: With the currently available technologies and implementations (and considering the product generation gaps), it is not always desirable, beneficial nor affordable to consumers to access the same information, provided on the same format, regardless of the access network and device. Although technology will improve continuously, consumer requirements will be strongly influenced by the context of mobile use (on the move, limited screen and keyboard, disturbing environment, et cetera), will not change that radically. Due to the context of mobile use, terminal capability variations, bandwidth issues, access rights and mobile network capabilities, this principle should be reconsidered. Even if it is easier to develop content for one Web, there are specific issues that need to be addressed. Providing a good and affordable mobile Web user experience becomes even more important to roaming consumers (presently, there is no low-cost global roaming tariff plan for mobile data devices). We would like to discuss the approach taken and would appreciate to hear your arguments for the “One Web” approach taken.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-375 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We have added links to the details of the specifications referenced in the default delivery context. The fall-back solutions belongs in the techniques document. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 1.4, Default Delivery Context: More detailed specifications should be provided. In addition, possible fall-back solutions should be mentioned.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-384 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We have added a note on non-URI-typing access to a web site: "it is expected that users will prefer to use alternative methods of obtaining URIs when available - such as following a hyperlink (from an e-mail, SMS or other Web page), WAP Push, 2D bar code, color bar code, RFID tag and Bluetooth." [Commentor reply] no reply from commenter [Comment]

Output: Chapter 5.2.1, URIs of Site Entry Points: The recommendation should be updated to cover aspects of direct manipulation (clickable) and character entry support.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-387 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] This is a specific best practice on use of "access keys" whose support is known to be quite uniform across mobile devices. We have added a clarification on the limitations of these accesskeys and the devices keyboards: "When building a list of links use numbered lists and assign access keys appropriately. It is recognized that not all characters can be used as access keys as many mobile devices have a limited keyboard." [Commentor reply] no reply from commenter [Comment]

Output: Chapter 5.2.6.1, What it means: This is a far more complex problem than just the limited keyboard (12-key keypads and soft-and hardware-based keyboards should be covered). In addition, aspects relating to the support, handling, mapping, sorting and transmitting characters should be addressed.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-357 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have added the definition that a Web safe color as one which has Red/Green/Blue components chosen only from the values 0, 51, 102, 153, 204, and 255. [Commentor reply] no reply from commenter [Comment]

Output: 2. Colours: There are a number of interpretations of "websafe" colours - please provide a reference that unambiguously states which colours are expected to be available.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-359 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We do say in 1.3 "From the perspective of this document this means that services should be available as some variant of HTML over HTTP." but indeed HTTP wasn't part of the default delivery context. We have added HTTP 1.0 as part of the default delivery context. [Commentor reply] no reply from commenter [Comment]

Output: 4. HTTP It is not clear that any transport protocol is guaranteed on the device. Given the requirements to support the regular web, and in particular such things as 30x HTTP responses, it would be appropriate to specify a level of HTTP support in the default characteristics. mobile space as a best practice?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-360 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have clarified the default delivery context, and now it only allows external style sheet as required by XHTML Basic. [Commentor reply] no reply from commenter [Comment]

Output: 5. Style sheets XHTML Basic does not include any support for internal styles. It makes sense, given the problems of latency that are a key constraint in the mobile space, to mandate support for internal styling, but it is not clear from the current wording what support can be expected (and therefore, as an implementor, what support we are implicitly being required to provide).

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-361 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We agreed with this and moved this Best Practice as a technique. [Commentor reply] yes [Comment]

Output: There are many types of content which do not require any adaptation. There is no point in these services determining any kind of context. Further, there is no point in determining context in any circumstances for a service that cannot make use of the information. This is not a best practice in itself, merely a technique that can be used to meet some others. In addition, as has been noted by others, having it appear first gives an impression of a strong bias against the one web goal stated elsewhere. cheers Chaals

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-396 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have added the following sentence in the "how to do it" section: If scripting is used, do not use onmouse and onkey triggers, use onclick. [Commentor reply] no reply from commenter [Comment]

Output: BP Not covered: 3. Use Device-independent event triggers in HTML, the onmouse* and onkey* triggers are somewhat difficult to trigger from the range of devices available. onclick is generally implemented in such a way that any device can trigger it, and mutation events (form changes, page load, etc) do not rely on a particular user interface anyway.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-397 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We agree and have added a new best practice to that effect (EXTERNAL_RESOURCES), which combined with the BALANCE Best Practice covers the suggestion. [Commentor reply] yes [Comment]

Output: BP Not covered: 4. Balance page weight and latency In a number of cases it will be appropriate to provide a choice between a large page and the same page broken into appropriate chunks. (Browsers like Opera mini will in any case break a page into appropriate sized pieces for phones that need this done). It can also be important to decide what resources to include externally, and which to include in the page. Use of the data: URI scheme can allow small images to be included inline (as can SVG where supported by the browser), and stylesheets and scripts can likewise be incorporated in the page, reducing latency effects caused by fetching multiple resources, or linked to allow efficiency from decisions on whether to load them and from caching.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-408 Charles McCathieNevile on behalf of Opera Software [Working Group decision] The group agreed and decided to drop this as a Best Practice. [Commentor reply] yes [Comment]

Output: The requirement expressed by [CONTEXT] is only necessary for some kinds of sites - it is really a technique that needs to be used to meet some other requirements in certain circumstances. In addition, having it first in the list of best practices suggests that there is a huge amount of work to be done in order to deliver any worthwhile content to the mobile web that is not required on the web in general. This is simply not true as a general statement. cheers Chaals

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-409 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have noted that borders and margins may sometimes usefully be specified in pixels. [Commentor reply] yes [Comment]

Output: There may be some other exceptions required to this, for borders and margins. These are commonly specified in pixels, and this may be appropriate in a number of cases. cheers Chaals

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-415 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have clarified that only images with an intrinsic size should have their dimensions specified in the markup. [Commentor reply] yes [Comment]

Output: There are some types of image, such as SVG, where a pixel-based size is unnecessary or inappropriate. In such cases it is often appropriate to use CSS to specify width/height rather than HTML attributes. cheers Chaals

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-345 Dan Connolly [Working Group decision] Thematic Consistency has been moved as the first Best Practice in the latest draft. Design for device independence, does not have a specific mobile interpretation, it does not appear to be testable and it is hard to know what techniques one would cite to support it, unless it is the totality of the techniques that we suggest in support of the best practices. We've removed the [CONTEXT] Best Practices as it did not appear to fit well with the other best practices, and has been moved as a technique instead. [Commentor reply] no reply from commenter [Comment]

Output: This draft is better than previous drafts in that it has an explicit "One Web" section. But the first best-practice guideline is still: "[CONTEXT] Take all reasonable steps to find out about the device/browser (client) capabilities, adaptation and other transformation that takes place for any instance of an access to a resource." -- link Guideline #1 should be: design for device-independence. Or something like that. In simple cases, one HTML document should work well across a variety of devices. But even for high-profile sites with dedicated production staff, where server-side content adaptation is worthwhile, designing for device independence is still a good idea; lots of content and navigation should be shared across devices. Ah... 5.2.4 Thematic Consistency of Resource Identified by a URI Much better. How about starting with that one? It's a bit of a mouthful, though. I don't see much justification for "... find out capabilities..." and I notice there's no "what to test" subsection for it.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-344 Elliotte Harold [Working Group decision] The group agreed this Best Practice wasn't very relevant and decided to remove it. [Commentor reply] no reply from commenter [Comment]

Output: Section 5.3.7 states: [BACKGROUND_IMAGE_SUPPORT] Do not use background images unless you know the device supports them. (Normative) I don't see any reasoning in the document to justify this one, and I can't think of any myself. Won;t a device that doesn't support background images simply ignore them without any detrimental effects? I can;t think of any examples in practice where the background image was a critical part of the content. This feels like it would degrade gracefully. At a minimum, I would ask that this normative rule be explained more. But if there's no good explanation for this, then this rule could simply be dropped.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-264 Ian Jacobs [Working Group decision] We agree and we have integrated your suggested rewrite in the section on Phasing, having removed the section on usability as such. [Commentor reply] yes [Comment]

Output: The terms "easily" and "efficiently" are almost unused in the document. In my opinion that do not add much information where they are used and might be safely deleted from this part of the document and from the best practices below. I suspect this entire section could be reduced without significant loss of information to the following: The quality of the user's Web experience via a mobile device depends significantly on the usability of Web sites, of browsers, and of the device itself. Although browser usability (for reading, navigating, and interacting with content) and device usability are important, this document focuses primarily on best practices for improving site usability.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-277 Ian Jacobs [Working Group decision] We have changed the term to "Mobile Web access" to clarify that it's not the mobile web but mobile access to the Web. [Commentor reply] yes [Comment]

Output: "As an illustration of some of these factors: First, unlike the fixed Web, the mobile Web will go where you go. No longer will you have to remember to do something on the Web when you get back to your computer. You can do it immediately, within the context that made you want to use the Web in the first place." The previous paragraph needs to be adjusted. The text (which may have come initially from the Communications Team!) suggests that there are two Webs: one fixed and one mobile. That is not a message we want to communicate. The point is that we want one Web and that we want to improve mobile access to it.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-283 Ian Jacobs [Working Group decision] We agree that this best practice didn't fit very well with the rest of the documents, and was more a general technique than an actual best practice. As such, we have redistributed the text between some other parts of the document as well as in the Techniques. [Commentor reply] yes [Comment]

Output: This point is problematic on several fronts: * "Reasonable" is not well-defined. That term may work well in some contexts (such as a patent policy, where people are used to it). I think you should avoid it in this document. Alternatively, say once up front in the delivery context section what you mean by "reasonable". * I am not sure who is responsible for carrying out this task. Is this the responsibility of someone who is producing content? It doesn't feel like it. * You say to do this for "any instance of an access." Even when there is caching? It may be that in that case I haven't accessed the resource, but I'm not sure of that, so it may be worth clarifying. * This should not be the first best practice note --- this is about content adaptation. I think it is important to start with the message: Design for one Web! Then, talk about how to improve the user experience above and beyond that. * The statement seems overly general. What about saying something a bit more specific, like "Follow published standards when determining device capabilities for the purpose of content adaptation."

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-289 Ian Jacobs [Working Group decision] We have added a clarification of the intended meaning of deficient: "By deficient we mean non-support of mandatory features of a relevant standard or recommendation and other bugs or errors in implementation." [Commentor reply] yes [Comment]

Output: * How do you define a "deficient" implementation? It sounds quite subjective to me. Do you mean implementations that do not conform (strictly) to standards? Otherwise how would you classify something as deficient or not? Do you mean "known bugs"?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-297 Ian Jacobs [Working Group decision] We have reworded the explanatory text about navigation bars, noting in particular that the navigation bar shouldn't prevent the user from seeing the core of the content. [Commentor reply] yes [Comment]

Output: * If you really mean "should be enough" then say "Provide between 2-4 links at the top of a given page for navigation to important parts of the page." That seems to me to be more useful than saying "minimal navigation." Find the 80% point, say it, and then let people adapt for other cases as required (and explain to them when they might encounter those cases). * In the same spirit as my comment on the previous point, you might rephrase this as:[Navigation helps in small doses] Providing 2-4 links at the top of a page to important content in the page facilitates navigation. Many more than that hinders navigation.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-299 Ian Jacobs [Working Group decision] We have substantially reworded the Best Practice on balance to clarify that the balance was between the number of links per pages and the number of pages the user has to download to go to his or her intended result. [Commentor reply] yes [Comment]

Output: * Does "link on page" mean that it links to something on the current page, or could it also be a link that points to a different page? * I don't know what "balance" means here. I imagine it means "roughly equal to in number," but it may not be about equality. * Does "depth of navigation" mean "to other pages"? * Do you mean something like "Users tend to give up if they have to follow more than 2-3 links in order to find something." * I hoped I would understand this point better by reading the "What it means" text, but the first sentence is confusing: it uses "navigation links" and "navigate multiple links" as though they mean something different, but the phrases are very similar.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-300 Ian Jacobs [Working Group decision] We have changed the Best Practice to mention URIs instead of links, and the text now refers to the Web Architecture principle. We have not renamed it since the wording "thematic consistency" is about the expected goal not the implied principle. [Commentor reply] yes [Comment]

Output: * You refer to "links"; do you mean "what you get when you follow the link?" * I suggest expressing this point in terms of serving roughly equivalent representations rather than in terms of links. * You might want to citeWebarch section 3.5.1, which says "A URI owner SHOULD provide representations of the identified resource consistently and predictably". * Since this is the "One Web" point, I think it belongs at the front of the document. You might want to retitle it "One Web Principle" rather than "Thematic Consistency". * You might want to simplify to "[One Web Principle] Because you never know for sure who will be reading your content (and their device, browser, and human capabilities), you should start by designing for a broad audience, then optimize your content for targetted audiences."

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-303 Ian Jacobs [Working Group decision] We have shortened the best practice by moving it in the explanatory text that also has been clarified. We haven't combined it with link_target_format since we want to to be clear on both these points. [Commentor reply] yes [Comment]

Output: * You might want to shorten this and combine it with the next point as follows:[Describe Link Targets] To help users decide whether to follow a given link, provide this information about the target of the link: * What it is, in clear language * How large it is (which may imply a time-consuming download) * The file format (which the user may know is not supported by the device). * I would note that in UAAG 1.0 we require the user agent to provide some of these services so the author doesn't have to; seecheckpoint 10.5. That helps address part of the goal of the following point about "knowing" whether the device supports a given format.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-314 Ian Jacobs [Working Group decision] We have removed the conditional statement since it is indeed taken into account by the default delivery context. [Commentor reply] yes [Comment]

Output: * Delete "if they can be determined". This is an instance of a qualifier that weighs down the point you are making and should be described elsewhere.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-315 Ian Jacobs [Working Group decision] We have added the following explanatory paragraph: "The page should lay out so that simple repeated scrolling in the same direction (axis) allows the user to experience all its content." We have kept the opt out clause, with explanations on cases where this might be needed (e.g. a map). [Commentor reply] yes [Comment]

Output: * What do you mean by "direction"? Do you mean "down, not up"? Do you mean "Don't make people scroll horizontally? * Delete "unless secondary scrolling cannot be avoided." In general, delete "except where impossible" as I've mentioned above.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-316 Ian Jacobs [Working Group decision] We agreed and removed the second best practice on scrolling. [Commentor reply] yes [Comment]

Output: * I do not understand how this point differs from the previous one.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-321 Ian Jacobs [Working Group decision] The Best Practice was dropped, so this comment doesn't apply anymore. [Commentor reply] yes [Comment]

Output: * This is another instance of the general point "Don't do X". I think you should regroup all of those points in one and relate them to the default delivery context.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-325 Ian Jacobs [Working Group decision] WCAG 2.0 is still a Working Draft, so the group has chosen to align with WCAG 1.0 which is a Recommendation. In particular, we have syncronized the text of this BP with the WCAG 1.0 guideline. [Commentor reply] yes [Comment]

Output: * Please stick very close to WCAG 2.0 on this one as well.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-334 Ian Jacobs [Working Group decision] We have clarified that a user should always be able to at least download items (in LINK_TARGET_FORMAT), no matter the level of support his or her device has for the said format. We have also mentioned the various ways one can determine which format is supported or not. [Commentor reply] yes [Comment]

Output: * Perhaps you can be more specific about HTTP (is it "accept" headers?) since that is an explicit assumption above. * The user may wish to receive content even if its device does not directly support it (e.g., to save and use it later). Please make it clear that the user can, on demand, request content that is not supported by software on the client.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-402 Zev Blut [Working Group decision] We have clarified that only a few links should be placed at the top of the page, leaving the rest of the navigation links to the bottom, and added a note to the effect that user should be able to see the content of the page without scrolling. [Commentor reply] no reply from commenter [Comment]

Output: 5.2.2 Navigation Bar I am not quite certain if having a navigation bar on the top page and having the navigation links on the same line is really a best practice that I agree with. Perhaps providing a definition or example of what a navigation bar is for a mobile site would help those who disagree with this. In many cases having navigation items like home and back links of the top of the page distracts the user from viewing the content that the user is currently looking for. The user must skip through a number of links before getting the view the content, which is not desirable in some cases. In such an example I think that having the navigation bar at the bottom is preferable when the user has found the searched for content. Although, in the case that the current page is not what the user is looking for having the navigation at the top is certainly better, for the quickness of getting out of the page. Perhaps this section could use a bit more explanation. This may be a difference of interpretation depending upon the if the handsets force the user to traverse each link or can skip links that are on the same line.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-404 Zev Blut [Working Group decision] The DoCoMo way of doing this is in the spirit of this BP i.e. the user will receive an appropriate message if his or her phone does not support the OBJECT tag, but we agree that the Best Practice was a worded a bit too restrictively. We have changed the wording of the Best Practice to: [OBJECTS_OR_SCRIPTS] Do not rely on embedded objects and/or scripts. [Commentor reply] no reply from commenter [Comment]

Output: 5.4.5 Non Text Items The way that current i-mode handsets deal with handsets that cannot support the object tag differs from this recommendation. This may make many i-mode sites break the best practices rules. You can refer to the following link for more detail: link

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-407 Zev Blut [Working Group decision] We have clarified that we really meant "do not rely on cookies being available"; i.e. it is indeed fine to make use of Set-Cookie to determine if the phone support cookies. [Commentor reply] no reply from commenter [Comment]

Output: 5.4.14 Cookies Does this prevent systems that make use of Set-Cookie to determine if the phone supports cookies from getting the mobileOK mark?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-419 on behalf of I18N WG [Working Group decision] We have added a reference to XHTML Basic. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 4 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 1.4 [link] Comment: Please point to the specification XHTML Basic [link] .

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-420 on behalf of I18N WG [Working Group decision] We agreed and moved it to section 1.2 and move the other sections down correspodingly. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 5 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 1.6 [link] Comment: This section seems to fit better at the beginning of the document.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-424 on behalf of I18N WG [Working Group decision] We have removed the spurrious line break. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 9 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 2.7 [link] Comment: Please correct the line break before \"communications.\".

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-428 on behalf of I18N WG [Working Group decision] This was a Dangling Reference from an earlier version which did make reference to CDF. The reference has been removed. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 13 At link Editorial/substantive: E Owner: FS Location in reviewed document: General Comment: CDFWG is in the references, but not in the text.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-430 on behalf of I18N WG [Working Group decision] Thanks for pointing this out. We have included a reference to the OMA documentation on UAPROF. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 15 At link Editorial/substantive: E Owner: FS Location in reviewed document: General Comment: UAProf is mentioned several times in the text, but not in the references. We guess you mean UAProf profile repository [link] .

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-431 on behalf of I18N WG [Working Group decision] We have added references to these documents. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 16 At link Editorial/substantive: E Owner: RI Location in reviewed document: Sec. 5.4.12 [link] Comment: Please refer to the tutorial on Character sets & encoding in XHTML, HTML and CSS [link] , and the QA on Setting encoding in web authoring applications [link] , instead of the \"HTTP charset\" document.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-438 Al Gilman on behalf of WAI [Working Group decision] We have added the following note to the section on content adaptation: "Whatever the adaptation model at work, the process of adaptation should not diminish accessibility." [Commentor reply] yes [Comment]

Output: section 3.1 which ever content adaptation implementation model is used, the model must retain necessary accessibility information (alt, label, etc.) and convey that information to the mobile device and the user.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-371 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We agree and have changed the text to read "to improve the user experience of the Web on mobile devices." [Commentor reply] no reply from commenter [Comment]

Output: Chapter 1.1, Purpose of the Document: The purpose should stretch beyond “…to promote more effective delivery…” and provide design guidelines applicable to the usability and accessibility of the mobile Web or, at least, specifics of interacting with mobile Web sites.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-380 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We have added that aspect to the list of advantages. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 2.7, Advantages: “Connected” should be added to the popularity reasons.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-383 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We have added the suggested mention of software versions. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 5.1.4, Testing: Update the recommendation to “…devices and provided specific software versions…”.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-386 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] We've added a note to the sentence "irrespective of differences in presentation capabilities": "and access mechanism." [Commentor reply] no reply from commenter [Comment]

Output: Chapter 5.2.4.1, What it means: Connectivity and download speed issues should be mentioned.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-342 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have updated the document to clarify that content should not rely on scripting, and avoid using scripting as much as possible due to battery considerations. [Commentor reply] yes [Comment]

Output: This Best Practice should require that content not rely on scripting, unless the delivery context is known to support them. Some mobile browsers allow the user to turn off javascript (handy where you are trying to save battery). It should also lean away from using script unless necessary - it is one of the more battery-intensive ways to do most things. It should also cross-reference requirements on page size, and a best practice on page size vs latency (see Opera's comment on "missing points") cheers Chaals

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-356 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have qualified the screen width as being a minimum. [Commentor reply] no reply from commenter [Comment]

Output: 1. Meaning The text does not make it clear whether the characteristics are minimum specifications, or actual specifications that should be assumed. For example should a developer assume in the absence of other information that the width of a device is 120 px, or that there may be no more than 120 px width available.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-410 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have changed the wording to: "Use features of the markup language to indicate logical document structure." [Commentor reply] no reply from commenter [Comment]

Output: [This is a comment on Mobile Best Practices, but cc'ed to WCAG as a comment for them on text the are currently using] The wording "Ensure that perceivable structures within the content can be programatically determined", copied verbatim from the WCAG working draft, has proven to be very difficult to understand for the majority of the developers I have ased to comment on this draft (which is only a couple of dozen). Perhaps something more straightforward, like "use markup, properly" is simpler for a title, with the current title moved into the "what it means" session as a couple of sentences. cheers chaals

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-411 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have reworded the "how to test" section accordingly. [Commentor reply] yes [Comment]

Output: Testing for the absence of tabindex, and the absence of complex layouts (absolute positioning, etc) should also be enough. cheers Chaals

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-412 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have added a test along these lines in the "what to test" section. [Commentor reply] yes [Comment]

Output: Another test for this is to see if there is rendered content that is not inside a table - if there is none, it is quite likely that tables are being used for layout. (Even more so if there is no caption or summary element on the outermost table). cheers Chaals

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-413 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have changed the wording to read: "[CAPABILITIES] Exploit device capabilities to provide an enhanced user experience.". [Commentor reply] yes [Comment]

Output: Rather than the negative "Do not take a least common denominator approach", this could be better phrased as "... to maximise usability" or something similar. It needs to be clear that while thispractise does authorise sending enhanced content to users who are clearly able to make use of it, it does not authorise breaking the "one web" principle and simply ignoring users (provided they have at least a "baseline-capable" device). cheers Chaals

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-258 Ian Jacobs [Working Group decision] We have elevated THEMATIC CONSISTENCY to the most prominent in the document and hence have given it the precedence it deserves. [Commentor reply] yes [Comment]

Output: Please start early with the "One Web" message, for example by adding something like this to the end of the preceding sentence: "An important Web design principle (discussed, for example, insection 4.3of "Architecture of the World Wide Web") is to design content that is flexible enough to enable a valuable user experience for a variety of devices. This document explains how to design for "one Web" while also optimizing for the mobile experience."

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-259 Ian Jacobs [Working Group decision] We have removed the incriminated sentence. [Commentor reply] yes [Comment]

Output: What does "in context" mean?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-260 Ian Jacobs [Working Group decision] The paragraph boundary was indeed unnecessary and we have merged the two paragraphs accordingly. [Commentor reply] yes [Comment]

Output: I suggest merging the previous two paragraphs; I otherwise was unsure about the mobileOK trustmark in the paragraph where it was introduced.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-263 Ian Jacobs [Working Group decision] We have expanded the consideration on phasing and have added a mention of the expected longevity of the document. [Commentor reply] yes [Comment]

Output: The first reference to "phase of work" is confusing. Does it mean "phase of this WG?" or "phase of this document"? Please clarify. It may be described in [Scope], but I think you need to provide a short summary of what "phasing" means or of what the phases are.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-265 Ian Jacobs [Working Group decision] We have replaced perhaps by "for example" and "for instance". [Commentor reply] yes [Comment]

Output: What does "perhaps" mean here?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-266 Ian Jacobs [Working Group decision] We have reworded this to read "not to exclude access from any particular class of device, except where this is necessary because of device limitations." [Commentor reply] yes [Comment]

Output: The document says "as far as is possible." When is it not possible? I think you can safely say that it is considered "best practice not to exclude access." You don't have to add disclaimers. If there are specific cases that you are thinking of (e.g., there may be privacy or security reasons), please call them out rather than say "as far as possible." I make similar comments below.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-268 Ian Jacobs [Working Group decision] We have reworded the introduction to the default delivery context section and think it sets now more clearly what concerns the content and what concerns the device/context. [Commentor reply] yes [Comment]

Output: The first sentence confused me because the title of the section includes "context" and the first sentence includes "content". I thought it was a mistake at first. It might help to say very quickly that there are two things discussed; context and content.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-270 Ian Jacobs [Working Group decision] The incriminated text has been removed. [Commentor reply] yes [Comment]

Output: I find "pointer to" to be very informal.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-271 Ian Jacobs [Working Group decision] We have replaced "annexes" by "appendices". [Commentor reply] yes [Comment]

Output: I think "Appendices" is more common than "Annexes" in W3C specs.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-273 Ian Jacobs [Working Group decision] We have reworeded the paragraph to read: "Equally, mobile users are typically less interested in lengthy documents or in browsing. The ergonomics of the device are frequently unsuitable for reading lengthy documents, and users will often only access such information from mobile devices as a last resort, because more convenient access is not available." [Commentor reply] yes [Comment]

Output: What is an "entertainment application"? Do you mean a game?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-276 Ian Jacobs [Working Group decision] We have removed the reference to this aspect, as we agreed it's not always something you get with mobile access. [Commentor reply] yes [Comment]

Output: I am not sure what implicit user identification means. Also, it sounds ominous to me, and therefore I'm not convinced it is always an "advantage". Do you plan to address privacy concerns?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-278 Ian Jacobs [Working Group decision] We have added link to the discussion on the phasing of our work. [Commentor reply] yes [Comment]

Output: See also previous comment on "phase"; I suggest a link to where the term is first explained.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-279 Ian Jacobs [Working Group decision] We have removed the section accordingly. [Commentor reply] yes [Comment]

Output: I think you can cut this entire section (4.1). The explanations do not add more than the text in the . I find they are not necessary anyway to my understanding of the document.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-280 Ian Jacobs [Working Group decision] We have removed the wording altogether and have instead created a list of the best practices with the links pointing to the relevant URIs. [Commentor reply] yes [Comment]

Output: There is an editorial problem around "by using URI reference composed" in the previous paragraph. Also, I think you should use "URI: instead of "URI Reference".

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-281 Ian Jacobs [Working Group decision] We have resolved to keep the labels the same, but we have added a table of BPs. [Commentor reply] yes [Comment]

Output: In both WAI Guidelines and theWebarchdocuments I worked on, we found it useful to provide short mnemonic labels for best practices and similar statements. In Webarch, we created a navigation bar to the statements at the top of the document (after the TOC), so people could access them individually and rapidly.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-296 Ian Jacobs [Working Group decision] We agreed with the weakness of the section and have added more detailed advice on shortening URIs. Meanwhile, we keep the specifics of configuring a server to that end for the techniques. [Commentor reply] yes [Comment]

Output: You say "how to do it" and then don't say how to do it --- you just say "don't make the user do X." Instead, what about talking about how to configure the server to do the right thing for index.html or similar?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-298 Ian Jacobs [Working Group decision] We have removed the incriminated sentence. [Commentor reply] yes [Comment]

Output: If "The device will take care of wrapping" is true enough to be stated as you have done, then add a best practice note: "Do not put explicit line breaks in navigation bars because browsers on mobile devices will do the right thing." or something more eloquent.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-301 Ian Jacobs [Working Group decision] We have replaced "use" with "provide" as suggested. [Commentor reply] yes [Comment]

Output: * Because the word "use" suggests "user", I recommend making this sound a bit more clearly like it is intended for authors. "Provide navigation mechanisms that are consistent across pages." [If you mean something else, then that's another issue.]

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-317 Ian Jacobs [Working Group decision] This one is meant to be about not putting banner ads, and other clutter in advance of the text. The "frontloading" aspect is discussed under [CLARITY]; we have added a link from one to the other to highlight their relationship. [Commentor reply] yes [Comment]

Output: * The key [CENTRAL_MEANING] is less communicative than "Frontload important information". See my earlier comment about using short labels that capture the essence (even if imperfectly) of the point.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-318 Ian Jacobs [Working Group decision] We have referenced the text of this Best Practice from the text of the best practice on navigation bar, with clarification on why it is important to keep navigation bars short in the mobile context. [Commentor reply] yes [Comment]

Output: The first sentence of the previous paragraph is more communicative than 5.2.2 as written.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-327 Ian Jacobs [Working Group decision] We have removed the word "always" and have instead clarified in the explanatory text that this is an exception to the best practices on relative measures. All the markup languages in scope for this document (XHTML Basic and above) have support for this feature. [Commentor reply] yes [Comment]

Output: * Why do you use "Always" here and not in other points? I recommend deleting "Always" for the same reason I suggest deleting "when possible". * What about markup languages that don't support this?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-332 Ian Jacobs [Working Group decision] We have removed "as possible". [Commentor reply] yes [Comment]

Output: * Delete "as possible", and * Add this to the list of things to "keep short"

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-339 Ian Jacobs [Working Group decision] We have removed the word "tab" and used a more generic wording about navigation order. [Commentor reply] yes [Comment]

Output: * Perhaps "tab order" is the term of art. Do people use a tab key on mobile devices? In UAAG 1.0 we talk about "sequential navigation" (distinguished from "direct navigation" through keyboard shortcuts).

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Value] terminology [Description] An incorrect term or a term from the wrong domain was used or terms are used inconsistently. [Example] The localization had “Pen Drive” when corporate terminology specified that “USB Stick” was to be used. The localized text inconsistently used "Start" and "Begin". A text renders the Hungarian term recsegőhid as “buzzer bridge” in English (a literal translation), but the term to be used in English is “wedge block,” as specified in a terminology list supplied to the translator. [Scope] S or T [Notes]

Output: This value is not intended for simple typographical errors or word choice not related to defined terminologies. For example, a mistyping of “pin” as “pen” or the use of “imply” instead of “infer” (mistaking two commonly confused words) would not count as terminology issues and is best categorized as either spelling errors or mistranslations, depending on the nature of the issue. Terminology refers only to cases where incorrect choices about terms (either formal or commonly defined in a domain) are involved.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] mistranslation [Description] The content of the target mistranslates the content of the source. [Example] The English source reads "An ape succeeded in grasping a banana lying outside its cage with the help of a stick" but the Italian translation reads "l'ape riuscì a prendere la banana posta tuori dall sua gabbia aiutandosi con un bastone" ("A bee succeeded...") [Scope] T [Notes]

Output: Issues related to translation of specific terms related to the domain or task-specific language are to be categorized as terminology issues.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] omission [Description] Necessary text has been omitted from the localization or source. [Example] One or more segments found in the source that have been intended for translation are missing in the target. After an alignment, a verification tool flags the pairs of aligned segments where the target has no corresponding source because of incorrect segmentation or some alignment issue. In such case the 'omission' type may apply to the source entry. [Scope] S or T [Notes]

Output: This value is not to be used for missing whitespace or formatting codes, but instead has to be reserved for linguistic content.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] untranslated [Description] Content that has been intended for translation is left untranslated. [Example] The source segment reads "The Professor said to Smith that he would hear from his lawyer" but the Hungarian localization reads "A professzor azt mondta Smithnek, hogy he would hear from his lawyer." [Scope] T [Notes]

Output: omission takes precedence over untranslated. Omissions are distinct in that they address cases where text is not present, while untranslated addresses cases where text has been carried from the source untranslated.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] locale-specific-content [Description] The localization contains content that does not apply to the locale for which it was prepared. [Example] A text translated for the Japanese market contains call center numbers in Texas and refers to special offers available only in the U.S. [Scope] S or T [Notes]

Output: Legally inappropriate material is to be classified as legal.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] locale-violation [Description] Text violates norms for the intended locale. [Example] A text localized into German has dates in mm/dd/yyyy format instead of DD.MM.YYYY. A text for the Irish market uses American-style foot and inch measurements instead of centimeters. A text intended for a U.S.-based audience uses U.K. spellings such as “centre” and “colour.” [Scope] S or T [Notes]

Output: This value can be used for spelling errors only if they relate specifically to locale expectations (e.g., a text consistently uses British instead of U.S. spellings for a text intended for the U.S.). If these errors are not systematic (e.g., a text uses U.S. spellings but has a single instance of “centre”), they are instead to be counted as spelling errors.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] characters [Description] The text contains characters that are garbled or incorrect or that are not used in the language in which the content appears. [Example] A text ought to have a '•' but instead has a '¥' sign. A German text erroneously uses û, ô, and â instead of the appropriate 'ü', 'ö', and 'ä'. A Japanese text has been garbled and appears with Devanagari characters. [Scope] S or T [Notes]

Output: Characters ought to be used in cases of garbling or systematic use of inappropriate characters, not for spelling issues where individual characters are replaced with incorrect one.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] numbers [Description] Numbers are inconsistent between source and target. [Example] A source text states that an object is 120 cm long, but the target text says that it is 129 cm. long. [Scope] S or T [Notes]

Output: Some tools may correct for differences in units of measurement to reduce false positives (e.g., a tool might adjust for differences in values between inches and centimeters to avoid flagging numbers that seem to be different but are in fact equivalent).

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] pattern-problem [Description] The text fails to match a pattern that defines allowable content (or matches one that defines non-allowable content). [Example] The tool disallows the regular expression pattern ['"”’][\.,] but the translated text contains "A leading “expert”, a political hack, claimed otherwise." A tool uses a regular expression to ensure that the content of an element is an IRI and flags what appears to be a malformed IRI. [Scope] S or T [Notes]

Output: Defining what is or is not an allowable pattern is up to the processing application and is beyond the scope of this specification. Best practice would be to use the Comment attribute to specify the pattern that led to the issue.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] internationalization [Description] There is an issue related to the internationalization of content. [Example] A line of programming code has embedded language-specific strings. A user interface element leaves no room for text expansion. A form allows only for U.S.-style postal addresses and expects five digit U.S. ZIP codes. [Scope] S or T [Notes]

Output: There are many kinds of internationalization issues. This value is therefore very heterogeneous in what it can refer to.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] length [Description] There is a significant difference in source and target length. [Example] The translation of a segment is five times as long as the source. [Scope] S or T [Notes]

Output: What constitutes a "significant" difference in length is determined by the model referred to in the locQualityIssueProfileRef.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] non-conformance [Description] The content is deemed to show poor statistical conformance to a reference corpus. Higher severity values reflect poorer conformance. [Example] The sentence "The harbour connected which to printer is busy or configared not properly." would have poor conformance. [Scope] S or T [Notes]

Output: Non-conformance is determined through the use of multiple statistical measures of similarity to a corpus of known-good content. For example, in a system that uses classification techniques the poor conformance might be a function of combined incorrect terminology, wrong spelling and bad grammar, or other features as determined by the system.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] uncategorized [Description] The issue either has not been categorized or cannot be categorized. [Example] A new version of a tool returns information on an issue that has not been previously checked and that is not yet classified. A text is defective in ways that defy categorization, such as the appearance of nonsense garbled text of unknown origin (e.g., a translation shows an unintelligible result and/or appears unrelated to the source material). [Scope] S or T [Notes]

Output: This value has the following uses: A tool can use it to pass through quality data from another tool in cases where the issues from the other tool are not classified (for example, a localization quality assurance tool interfaces with a third-party grammar checker). A tool’s issues are not yet assigned to values, and, until an updated assignment is made, they may be listed as uncategorized. In this case it is recommended that issues be assigned to appropriate values as soon as possible since uncategorized does not foster interoperability. uncategorized can be used where a portion of text is defective in a way that defies assignment to a value in either the originating system or in any other ITS localization quality markup to indicate that it is uncategorizable.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] other [Description] Any issue that cannot be assigned to any values listed above. [Scope] S or T [Notes]

Output: This value allows for the inclusion of any issues not included in the previously listed values. It is encouraged not to use this value for any tool- or model-specific issues that can be mapped to the values listed above. In addition, this value is not synonymous with uncategorized in that uncategorized issues may be assigned to another precise value, while other issues cannot. If a system has an "miscellaneous" or "other" value, it is better to map this to this value even if the specific instance of the issue might be mapped to another value.

Internationalization Tag Set (ITS) Version 2.0


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: [Patterns] RDF terms [Query Forms] SELECT [Other] VALUES [Modifiers]

Output: DISTINCT


Input: [Patterns] Property path expression [Query Forms] CONSTRUCT [Other] SERVICE [Modifiers]

Output: REDUCED


Input: [Patterns] Property path patterns [Query Forms] DESCRIBE [Modifiers]

Output: Projection


Input: [Patterns] Groups [Query Forms] ASK [Modifiers]

Output: ORDER BY


Input: [Patterns] OPTIONAL [Modifiers]

Output: LIMIT


Input: [Patterns] UNION [Modifiers]

Output: OFFSET


Input: [Patterns] GRAPH [Modifiers]

Output: Select expressions


Input: [Event name] loadstart [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent begins looking for media data, as part of the resource selection algorithm. [Preconditions]

Output: networkState equals NETWORK_LOADING


Input: [Event name] progress [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent is fetching media data. [Preconditions]

Output: networkState equals NETWORK_LOADING


Input: [Event name] suspend [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent is intentionally not currently fetching media data, but does not have the entire media resource downloaded. [Preconditions]

Output: networkState equals NETWORK_IDLE


Input: [Event name] load [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent finishes fetching the entire media resource. [Preconditions]

Output: networkState equals NETWORK_LOADED


Input: [Event name] abort [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent stops fetching the media data before it is completely downloaded. [Preconditions]

Output: error is an object with the code MEDIA_ERR_ABORTED. networkState equals either NETWORK_EMPTY or NETWORK_LOADED, depending on when the download was aborted.


Input: [Event name] error [Interface] ProgressEvent [PROGRESS] [Dispatched when...] An error occurs while fetching the media data. [Preconditions]

Output: error is an object with the code MEDIA_ERR_NETWORK or higher. networkState equals either NETWORK_EMPTY or NETWORK_LOADED, depending on when the download was aborted.


Input: [Event name] loadend [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent stops fetching the media data, for whatever reason. [Preconditions]

Output: One of load, abort, or error has just fired.


Input: [Event name] emptied [Interface] Event [Dispatched when...] A media element whose networkState was previously not in the NETWORK_EMPTY state has just switched to that state (either because of a fatal error during load that's about to be reported, or because the load() method was invoked while the resource selection algorithm was already running, in which case it is fired synchronously during the load() method call). [Preconditions]

Output: networkState is NETWORK_EMPTY; all the DOM attributes are in their initial states.


Input: [Event name] stalled [Interface] ProgressEvent [Dispatched when...] The user agent is trying to fetch media data, but data is unexpectedly not forthcoming. [Preconditions]

Output: networkState is NETWORK_LOADING.


Input: [Event name] play [Interface] Event [Dispatched when...] Playback has begun. Fired after the play() method has returned. [Preconditions]

Output: paused is newly false.


Input: [Event name] pause [Interface] Event [Dispatched when...] Playback has been paused. Fired after the pause method has returned. [Preconditions]

Output: paused is newly true.


Input: [Event name] loadedmetadata [Interface] Event [Dispatched when...] The user agent has just determined the duration and dimensions of the media resource. [Preconditions]

Output: readyState is newly equal to HAVE_METADATA or greater for the first time.


Input: [Event name] loadeddata [Interface] Event [Dispatched when...] The user agent can render the media data at the current playback position for the first time. [Preconditions]

Output: readyState newly increased to HAVE_CURRENT_DATA or greater for the first time.


Input: [Event name] waiting [Interface] Event [Dispatched when...] Playback has stopped because the next frame is not available, but the user agent expects that frame to become available in due course. [Preconditions]

Output: readyState is newly equal to or less than HAVE_CURRENT_DATA, and paused is false. Either seeking is true, or the current playback position is not contained in any of the ranges in buffered. It is possible for playback to stop for two other reasons without paused being false, but those two reasons do not fire this event: maybe playback ended, or playback stopped due to errors.


Input: [Event name] playing [Interface] Event [Dispatched when...] Playback has started. [Preconditions]

Output: readyState is newly equal to or greater than HAVE_FUTURE_DATA, paused is false, seeking is false, or the current playback position is contained in one of the ranges in buffered.


Input: [Event name] canplay [Interface] Event [Dispatched when...] The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content. [Preconditions]

Output: readyState newly increased to HAVE_FUTURE_DATA or greater.