Input: [Value] locale-specific-content [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] Legally inappropriate material is to be classified as legal. [Description]

Output: The localization contains content that does not apply to the locale for which it was prepared.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] locale-violation [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] 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. [Description]

Output: Text violates norms for the intended locale.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] style [Example] Company style guidelines dictate that all individuals be referred to as Mr. or Ms. with a family name, but the text refers to “Jack Smith”. [Scope] S or T [Description]

Output: The text contains stylistic errors.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] characters [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] 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. [Description]

Output: The text contains characters that are garbled or incorrect or that are not used in the language in which the content appears.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] misspelling [Example] A German text misspells the word "Zustellung" as "Zustlelung". [Scope] S or T [Description]

Output: The text contains a misspelling.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] typographical [Example] An English text has the following sentence: "The man whom, we saw, was in the Military and carried it's insignias". [Scope] S or T [Description]

Output: The text has typographical errors such as omitted/incorrect punctuation, incorrect capitalization, etc.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] formatting [Example] Warnings in the text are supposed to be set in italic face, but instead appear in bold face. Margins of the text are narrower than specified. [Scope] S or T [Description]

Output: The text is formatted incorrectly.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] inconsistent-entities [Example] The name "Thaddeus Cahill" appears in an English source but is rendered as "Tamaš Cahill" in the Czech version. The date "February 9, 2007" appears in the source but the translated text has "2. September 2007". [Scope] S or T [Description]

Output: The source and target text contain different named entities (dates, times, place names, individual names, etc.)

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] numbers [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] 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). [Description]

Output: Numbers are inconsistent between source and target.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] markup [Example] The source segment has five markup tags but the target has only two. An opening tag in the text is missing a closing tag. [Scope] S or T [Description]

Output: There is an issue related to markup or a mismatch in markup between source and target.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] pattern-problem [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] 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. [Description]

Output: The text fails to match a pattern that defines allowable content (or matches one that defines non-allowable content).

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] whitespace [Example] A source segment starts with six space characters but the corresponding target segment has two non-breaking spaces at the start. The text uses a run of 12 space characters instead of a tab character to align numbers in a table. Two space characters appear after a period even though only a single space is to be used. [Scope] S or T [Description]

Output: There is a mismatch in whitespace between source and target content or the text violates specific rules related to the use of whitespace.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] internationalization [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] There are many kinds of internationalization issues. This value is therefore very heterogeneous in what it can refer to. [Description]

Output: There is an issue related to the internationalization of content.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] length [Example] The translation of a segment is five times as long as the source. [Scope] S or T [Notes] What constitutes a "significant" difference in length is determined by the model referred to in the locQualityIssueProfileRef. [Description]

Output: There is a significant difference in source and target length.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] non-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] 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. [Description]

Output: The content is deemed to show poor statistical conformance to a reference corpus. Higher severity values reflect poorer conformance.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] uncategorized [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] 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. [Description]

Output: The issue either has not been categorized or cannot be categorized.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] other [Scope] S or T [Notes] 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. [Description]

Output: Any issue that cannot be assigned to any values listed above.

Internationalization Tag Set (ITS) Version 2.0


Input: [Clause] Access [Description] The ability of users to obtain and correct information that an entity has collected about them [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary] yes [Applies to]

Output: proposal or statement


Input: [Clause] Agreement With [Description] The entity who the user is entering into an agreement with [Required in Every Proposal] yes [Default Type of Label] certificate, URI, or text string [May be Defined in Vocabulary] yes [Applies to]

Output: proposal or statement


Input: [Clause] Consequence [Description] The impact on the user of reaching an agreement [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary] yes [Applies to]

Output: proposal or statement


Input: [Clause] Contact [Description] Information for contacting a service with inquiries about the services privacy practices. [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary] yes [Applies to]

Output: proposal or statement


Input: [Clause] Experience Space [Description] The space where a particular statement is valid [Required in Every Proposal] yes [Default Type of Label] set of URIs [May be Defined in Vocabulary] no [Applies to]

Output: proposal or statement


Input: [Clause] Practice [Description] What a service will do with data [Required in Every Proposal] yes [Default Type of Label] none [May be Defined in Vocabulary] yes [Applies to]

Output: statement


Input: [Clause] Qualified Data Set [Description] The data a service proposes to collect or requests [Required in Every Proposal] yes [Default Type of Label] see definition below [May be Defined in Vocabulary] no, but qualifier and category components may be [Applies to]

Output: statement


Input: [Clause] Qualifier [Description] Used by the creator of a vocabulary to provide extra functionality beyond that in the base P3 Proposal Grammar [Required in Every Proposal] no [Default Type of Label] none [May be Defined in Vocabulary] yes [Applies to]

Output: proposal, statement, or clause


Input: [Clause] Required [Description] A binary value indicating whether a particular practice, qualified data set, or statement is required in an agreement [Required in Every Proposal] no (defaults to 1 when not present) [Default Type of Label] 0 or 1 [May be Defined in Vocabulary] no [Applies to]

Output: practice clause, qualified data set clause, or statement


Input: [Clause] Schema [Description] A URI that identifies a particular P3 proposal vocabulary [Required in Every Proposal] yes [Default Type of Label] URI [May be Defined in Vocabulary] no [Applies to]

Output: proposal


Input: [Clause] Signature [Description] Signature and attribution information as defined by the Digital Signature effort [Required in Every Proposal] no [Default Type of Label] none [May be Defined in Vocabulary] yes [Applies to]

Output: Proposal or statement


Input: [Event handler] onabort [Event handler event type]

Output: abort


Input: [Event handler] oncancel [Event handler event type]

Output: cancel


Input: [Event handler] oncanplay [Event handler event type]

Output: canplay


Input: [Event handler] oncanplaythrough [Event handler event type]

Output: canplaythrough


Input: [Event handler] onchange [Event handler event type]

Output: change


Input: [Event handler] onclick [Event handler event type]

Output: click


Input: [Event handler] onclose [Event handler event type]

Output: close


Input: [Event handler] oncuechange [Event handler event type]

Output: cuechange


Input: [Event handler] ondblclick [Event handler event type]

Output: dblclick


Input: [Event handler] ondrag [Event handler event type]

Output: drag


Input: [Event handler] ondragend [Event handler event type]

Output: dragend


Input: [Event handler] ondragenter [Event handler event type]

Output: dragenter


Input: [Event handler] ondragexit [Event handler event type]

Output: dragexit


Input: [Event handler] ondragleave [Event handler event type]

Output: dragleave


Input: [Event handler] ondragover [Event handler event type]

Output: dragover


Input: [Event handler] ondragstart [Event handler event type]

Output: dragstart


Input: [Event handler] ondrop [Event handler event type]

Output: drop


Input: [Event handler] ondurationchange [Event handler event type]

Output: durationchange


Input: [Event handler] onemptied [Event handler event type]

Output: emptied


Input: [Event handler] onended [Event handler event type]

Output: ended


Input: [Event handler] oninput [Event handler event type]

Output: input


Input: [Event handler] oninvalid [Event handler event type]

Output: invalid


Input: [Event handler] onkeydown [Event handler event type]

Output: keydown


Input: [Event handler] onkeypress [Event handler event type]

Output: keypress


Input: [Event handler] onkeyup [Event handler event type]

Output: keyup


Input: [Event handler] onloadeddata [Event handler event type]

Output: loadeddata


Input: [Event handler] onloadedmetadata [Event handler event type]

Output: loadedmetadata


Input: [Event handler] onloadstart [Event handler event type]

Output: loadstart


Input: [Event handler] onmousedown [Event handler event type]

Output: mousedown


Input: [Event handler] onmouseenter [Event handler event type]

Output: mouseenter


Input: [Event handler] onmouseleave [Event handler event type]

Output: mouseleave


Input: [Event handler] onmousemove [Event handler event type]

Output: mousemove


Input: [Event handler] onmouseout [Event handler event type]

Output: mouseout


Input: [Event handler] onmouseover [Event handler event type]

Output: mouseover


Input: [Event handler] onmouseup [Event handler event type]

Output: mouseup


Input: [Event handler] onmousewheel [Event handler event type]

Output: mousewheel


Input: [Event handler] onpause [Event handler event type]

Output: pause


Input: [Event handler] onplay [Event handler event type]

Output: play


Input: [Event handler] onplaying [Event handler event type]

Output: playing


Input: [Event handler] onprogress [Event handler event type]

Output: progress


Input: [Event handler] onratechange [Event handler event type]

Output: ratechange


Input: [Event handler] onreset [Event handler event type]

Output: reset


Input: [Event handler] onseeked [Event handler event type]

Output: seeked


Input: [Event handler] onseeking [Event handler event type]

Output: seeking


Input: [Event handler] onselect [Event handler event type]

Output: select


Input: [Event handler] onshow [Event handler event type]

Output: show


Input: [Event handler] onstalled [Event handler event type]

Output: stalled


Input: [Event handler] onsubmit [Event handler event type]

Output: submit


Input: [Event handler] onsuspend [Event handler event type]

Output: suspend


Input: [Event handler] ontimeupdate [Event handler event type]

Output: timeupdate


Input: [Event handler] onvolumechange [Event handler event type]

Output: volumechange


Input: [Event handler] onwaiting [Event handler event type]

Output: waiting


Input: [Name] exclusiveMode [Values] true or false [Description] whether to do inclusive or exclusive dealing of namespaces. In exclusive mode the inclusiveNamespacePrefixList parameter can be specified listing the prefixes that are to be treated in an inclusive mode [Default]

Output: false


Input: [Name] inclusiveNamespacePrefixList [Values] space separated list of prefixes [Description] list of prefixes to be treated inclusively. Special token #default indicates the default namespace. [Default]

Output: empty


Input: [Name] ignoreComments [Values] true or false [Description] whether to ignore comments during canonicalization [Default]

Output: true


Input: [Name] trimTextNodes [Values] true or false [Description] whether to trim (i.e. remove leading and trailing whitespaces) all text nodes when canonicalizing. Adjacent text nodes must be coalesced prior to trimming. If an element has an xml:space="preserve" attribute, then text nodes descendants of that element are not trimmed regardless of the value of this parameter. [Default]

Output: false


Input: [Name] serialization [Values] XML or EXI [Description] whether to do the normal XML serialization, or do an EXI serialization - which is useful if the original document to be signed is already in EXI format. [Default]

Output: XML


Input: [Name] prefixRewrite [Values] none, sequential, derived [Description] with none, prefixes are not changed, with sequential prefixes are changed to n1, n2, n3 ... and with derived, each prefix is changed to nSuffix, where the suffix is derived by doing a digest of the namespace URI. [Default]


Input: [Name] sortAttributes [Values] true or false [Description] whether the attributes need to be sorted before canonicalization. In some environments the order of attributes changes in transit so sorting is important. [Default]

Output: true


Input: [Name] ignoreDTD [Values] true or false [Description] if set to true, ignore the DTD completely, which means do not normalize attributes, do not look into entity definitions, do not add default attributes to each element [Default]

Output: false


Input: [Name] expandEntities [Values] true or false [Description] if set to true ignore all entity declarations, and expand only the predefined entites (lt, gt, amp, apos, quot) and character references. (Entity declarations are potential attack points, [BradHill] mentions an entity that is 2 GB is length, also expanding external entities can lead to cross site scripting attacks) [Default]

Output: true


Input: [Name] xmlBaseAncestors [Values] inherit, none, combine [Description] whether to inherit xml:base attributes from ancestors (like C14N 1.0) or not (like Exc C14n 1.0) or combine them (like C14n 1.1) [Default]

Output: combine


Input: [Name] xmlIdAncestors [Values] inherit, none [Description] whether to inherit xml:id attributes from ancestors (like C14N 1.0) or not (like C14N 1.1 or Exc C14n 1.0) [Default]


Input: [Name] xmlLangAncestors [Values] inherit, none [Description] whether to inherit xml:lang attributes from ancestors (like C14N 1.0 and C14n 1.1) or not (Exc C14n 1.0) [Default]

Output: inherit


Input: [Name] xmlSpaceAncestors [Values] inherit, none [Description] whether to inherit xml:space attributes from ancestors (like C14N 1.0 and C14n 1.1) or not (Exc C14n 1.0) [Default]

Output: inherit


Input: [Name] xsiTypeAware [Values] true or false [Description] if set to true, looks for namespace prefix usages in xsi:type attributes as well, otherwise xsi:type attributes are treated just like regular attributes. [Default]

Output: false


Input: [Commentor] LC-421 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 6 At link Editorial/substantive: S Owner: FS Location in reviewed document: Sec. 2.2 [link] Comment: We propose to add to this section on \"input\" the requirement to provide an adequate input method for the user. Especially for complex scripts like Chinese or Japanese, this is a crucial requirement. [Working Group decision] The Best Practices do not set requirements on user agents, only on content; we already give recommendations on input mode for the content (see AVOID_FREE_TEXT and DEFAULT_INPUT_MODE]. Any further consideration would better fit in the techniques related to these best practices, on which we welcome contributions: link link [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-422 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 7 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec.2.3 [link] Comment: In some character encodings like UTF-8, scripts with a similar number of characters (e.g. latin versus indic scripts) vary in space requirements. To avoid high bandwidth / cost related to scripts, you might propose for such cases the use of the compression scheme for unicode [link] . [Working Group decision] We have not found sufficient support for this encoding scheme in mobile devices. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-433 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 18 At link Editorial/substantive: S Owner: RI Location in reviewed document: 5.4.12 Comment: The section mentions the use of the XML declaration for declaring in-document the encoding of XML documents, but makes no mention of the standard in-document declaration of encoding for HTML documents or XHTML served as text/html, which uses the Content-Type meta element. This seems a strange omission. Please add text describing this. [Working Group decision] We have added a link to the I18N tutorial on specifying the encoding and have added the specific case you mention in the related technique: link (note that the document only focuses on XHTML, not on HTML) [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-436 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 21 At link Editorial/substantive: S Owner: RI Location in reviewed document: General Comment: We believe the document should encourage all participants in the mobile value chain to support Unicode. This is extremely helpful in ensuring international use of this technology and ease of localization of content. [Working Group decision] After futher discussion with Richard Ishida, we have added more specific recommendations as to why using Unicode is a smart thing to do: "Encoding of the content to a desired character encoding is dependent on the authoring tools being used, Web server configuration and the server side scripting technology being used (if any). For a discussion of this see [CHARSET1] and [CHARSET2]. Unicode is a good choice for representing content when served in multiple languages. The amount of bandwidth required to transmit content can vary significantly depending on the character encoding used. Text consisting principally of characters from the Latin alphabet will encode more efficiently in UTF-8, whereas text consisting principally of characters from ideographic scripts will encode more efficiently in UTF-16. When choosing a character encoding, consider the efficiency of the available encodings. Since the Default Delivery Context specifies use only of UTF-8, all applications should support UTF-8. " [Commentor reply]

Output: yes

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


Input: [Commentor] LC-393 on behalf of Nokia [Comment] 5.4.15 Cache Headers Proposal for adding a statement [CACHE_CLOCK_SKEW]. Ensure the site will function acceptably without cache, but explicitly set cache headers with long expiration times to allow for clock or time zone inaccuracy in the client. [Working Group decision] Timezone inaccuracies in the client don't normally affect caching since it relies on GMT time. Clock skews aren't specific to mobile devices and should be handled as a case of deficiency in the implementation when specific to a given mobile device. As such, we haven't modified the document, but would welcome a technique on this specific item: link [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-366 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] We believe that Web site access through mobile devices would benefit from the provision of some minimum-level requirements on terminal capabilities and browser features. If this cannot be achieved, other work should be referenced. [Working Group decision] The Default Delivery Context (section 1.4 in the Last Call Working Draft) provides the assumed minimum-level requirements alluded to. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-367 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Accessibility should be addressed more specifically, as the mobile Web (and its specific issues) does not seem to be in the scope of the WAI/WCAG guidelines 2.0, currently under updating. The provided cross-referencing is beneficial but it does not provide enough substance. [Working Group decision] The group took inspiration from WCAG 1.0 (and links back to it), but the accessibility experts are in the WAI groups. As such, we think further work on accessibility in the mobile context is out of our scope. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-368 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Access to the mobile Web through a speech user interface is not covered by the present draft version. We believe it should be addressed (also as there is excellent work in W3C to cross-reference), as it is an important accessibility enabler to young and older users and users with temporary or permanent functional abilities. [Working Group decision] This is out of scope of the current phase of work of the Best Practices, as stated in our scope document: """ As the Mobile Web Initiative is primarily concerned with accessing content that would currently be rendered in a desktop or laptop browser, the BPWG's focus is currently on best practices that are most pertinent to "traditional" browsing. However, in future phases, the group may broaden the scope of its work in order to take into account other content presentation options that may be available on mobile devices - e.g., using the emerging multimodal technologies.""" link [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-370 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Setup and configuration is currently considered by consumers as a major difficulty, when trying to access mobile services and applications. As this document does not address setup and configuration-specific issues and it does not provide such guidelines, it should reference available recommendations and best practices developed in other standard bodies and fora, in order to improve the user experience. [Working Group decision] Setup and configuration is out of scope for the Mobile Web Best Practices which only focus on the delivery of content to Mobile Web devices. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-385 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Chapter 5.2.2.2, How to do it: Provide advice on how to implement device-based wrapping. [Working Group decision] The group thinks this topic would be a better fit as part of the techniques, on which we welcome contributions: link [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-388 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Chapter 5.4.13, Error messages: The purpose of error messages should be dual: 1. To provide information to the user; and 2. To provide information to the service provider. The recommendation should cover both aspects. [Working Group decision] Telling providers to check their error logs is out of scope for this document. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-358 Charles McCathieNevile on behalf of Opera Software [Comment] 3. Security In order to build commercial services on the web, secure connections are necessary. In addition, these are widely implemented already. Is there no requirement to support https connections in the mobile space as a best practice? [Working Group decision] We don't have any best practice regarding security, and deploying a secure service on the Web and on mobile devices require much more guidance than simple best practices. As a consequence, the group doesn't feel the document should talk about HTTPS. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-394 Charles McCathieNevile on behalf of Opera Software [Comment] BP Not covered: 1. Don\'t format text as justified. Text aligned to be justified on both sides is often problematic on the web in general - on mobile devices with a relatively small range of fonts and display options, it seriously reduces legibility of content, often at a cost of some extra processing. [Working Group decision] We have added a new best practice on text effects: "[FONTS] Do not rely on support of font related styling." but we think the particular aspect of justification would be better handled by a technique that was started at: link [Commentor reply]

Output: yes

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


Input: [Commentor] LC-395 Charles McCathieNevile on behalf of Opera Software [Comment] BP Not covered: 2. Identify word breaks. (This is related to the previous point) Long words which can be broken should include useful information about appropriate points to do so by including a  or similar. display options, it seriously reduces legibility of content, often at a cost of some extra processing. [Working Group decision] We think this would be a better fit for a technique rather than a specific best practice. A technique has been started in: link [Commentor reply]

Output: yes

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


Input: [Commentor] LC-267 Ian Jacobs [Comment] "From the perspective of this document this means that services should be available as some variant of HTML over HTTP." Why is the previous statement here? It sounds like it is an assumption about delivery and belongs in the next section. [Working Group decision] Yes and no: yes, HTTP has been added in the default delivery context -- but no, it also belongs here -- as a clarification of what "One Web" means in the context of this document. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-285 Ian Jacobs [Comment] * The word "exploit" seems like it is being used in the French sense of "make use of". I find that in (American) English it carries a negative connotation, as when one "exploits" a security hole. * This statement is so broad that it should be dropped as a best practice note. Instead, I recommend that you create a section a the top of the document that explains what the best practices notes strive to allow people to do. For example: By following the guidance of this document, designers can: * Learn to optimize their designs for delivery to a mobile device by taking full advantage of device capabilities. * .... In short, this best practice note doesn't actually teach me anything useful. Instead, I would like to learn from the document how to do the thing you are talking about. I realize that there is an "abstract" layer and a "techniques" layer and that the abstract point is to take advantage of device capabilities, but I do not believe you have captured the right level in the above note. Instead, if you are thinking of one or two slightly more specific points, I recommend stating those instead of this very general point. [Working Group decision] * "exploit is the word used in the Device Independence authoring techniques, so we prefer being consistent with them * we think it is important to inform the reader that a good user experience on a mobile devices needs most of the time to be adapated to the device * the techniques document is the place where the reader can learn more on actual ways to learn about device capabilitiles * we have also clarified that we mean more client capabilities than just the ones required to implement the other best practices. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-287 Ian Jacobs [Comment] * Please delete "reasonable" (if you keep this one). [Working Group decision] We think that reasonable is an appropriate word to use. We expect you to try, but don't expect you to break your back. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-288 Ian Jacobs [Comment] * This can be a dangerous point if not worded carefully. See the relatedprinciple in Webarch: " Agents that recover from error by making a choice without the user's consent are not acting on the user's behalf." I realize that in this context one may not always be interacting directly with the user. But "silently recovering from error" is one of the things that I believe the TAG feels strongly is a bad thing. [Working Group decision] The "silently recovering from error" point is relevant to user agent requirements which is out of scope. We believe the text already addresses the issues you've raised. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-290 Ian Jacobs [Comment] * Below you say something more interesting, which I paraphrase as "It's ok to not follow some of the other best practices in this document when you need to work around errors." That's a big gate and you should strive to narrow it. Furthermore, you seem to define conformance below "then content providers must comply..." Does that statement belong in 5.1.3.1 or is it a general statement that belongs in a conformance section? [Working Group decision] We decided to keep the best practice as is, but we have added text to the default delivery context to mention that no get-out clauses apply in the default delivery context. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-291 Ian Jacobs [Comment] * In my opinion, unless you adopt something more along the lines of what is stated below (a kind of "exception" provision for error conditions) then I think you should delete this one, which, as stated, seems to me to amount to "Do useful things." Again, the note has a very different impact if you are talking about when it's ok to not follow _other_ good practices. [Working Group decision] We are writing for Web people who may not have realised that there is even more variation in browsers on mobile than there is on the desktop. We do indeed talk about when it is ok not to follow other good practices. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-293 Ian Jacobs [Comment] I realize that you have chosen to write the good practice notes in the imperative voice. I also realize that more information is provided below. However, I think the reader might take away a lot more if the points included more rationale. Any many people (including myself initially) may simply look at the checklist and not take time to read the entire document. For instance: "Short URIs require less effort to type, are less prone to errors when typing them, and are easier to remember." In light of my previous comment about short labels for the statements, you might end up with: [Short URIs Are Friendly] Short URIs require less effort to type, are less prone to errors when typing them, and are easier to remember. This is not much longer than what you have and I think the rationale provided (likely imperfect as proposed) makes the statements much more meaningful. [Working Group decision] Generally speaking, we think the imperative voice better convey our message across. For the specific best practice on short URIs, we have added a explanatory words and examples, but have kept the best practice mostly as is. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-302 Ian Jacobs [Comment] * Access key support on traditional desktop devices is problematic at best. I do not know about the current state of support from the WCAG WG for access keys (looking in the WCAG 2.0 techniques, I find only a placeholder). Is access key support on mobile devices expected to be more interoperable? [Working Group decision] Yes, access key support on mobile devices is interoperable among mobile devices and with some desktop implementations. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-304 Ian Jacobs [Comment] * I am not sure what you mean by this checkpoint. Through Internet protocols I believe two parties can agree on whether a client supports a particular format available on the server. So do you mean that after such a negotiation, in (adapted) content you serve, you don't have to provide information about the format? I don't think you mean that, in particular because I think that would imply lots of communication about all the links in a document to determine the format of identified resources. * Other than through Internet protocols dynamically, I don't know how you can "know the device supports" a given format unless you are designing in a very closed environment, and I thought that the purpose of these guidelines was to explain how to design effectively in anopenenvironment. * Perhaps you can shorten this, therefore, to something like "To help users reduce the cost of unnecessary downloads, for pieces of content in formats that are not part of the default delivery context, identify the format in links." [Working Group decision] Most content adaptation systems rely on a database of known devices, with information on which format the device support. If you use such a system, you can annotated only the links you know may not be supported; if you don't, you fallback on the default delivery context, which tells you that only XHTML, JPG and GIF are supported formats (we have amended the text to clarify this). [Commentor reply]

Output: yes

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


Input: [Commentor] LC-305 Ian Jacobs [Comment] * I have a similar concern as above about "unless you know." I think that some of these checkpoints make more sense at certain points in a pipeline than at others. For instance, I as a human author probably don't know whether a particular user agent supports this or that. On the other hand, a piece of software that is actively involved in some protocol negotiation and that is doing content adaptation may very well have that information available. But the points are written for multiple audiences and therefore may be confusing. * What is "an available geometric shape"? I think you mean that the format supports the shape. [Working Group decision] The document is about delivered content. The inference for a content author is that if they specify an image map, then under certain circumstances this will not work so they should in addition consider an alternative linear arrangement of links. We have shortened the best practice to: "Do not use image maps unless you know the target client supports them effectively." and explained "effectively" in the text with the remainder of the BP as it is now put. We have also included a note to the effect that Image Maps on the Mobile Web are a bad idea. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-307 Ian Jacobs [Comment] * In developing UAAG 1.0, which addresses these topics, we distinguished two concerns (1) the (visual or other sensory) disorientation caused by suddenly opening windows and (2) the change in focus. * I urge you to recast these in terms of thecheckpoints of Guideline 5of the UAAG 1.0 Recommendation. I am happy to discuss them further with you to help answer any questions. * In particular, an important point is that it's ok to do these things when the user says it's ok. * For the point about "unless you have informed the user", that may be locking up the barn after the horse has been stolen. I think it's more important to provide an alternative. [Working Group decision] We don't mean to be prescriptive about providing a means of helping the user choose, we do mean that there must be a way of telling the user that the page will refresh and of stopping refresh once it has started. Any other consideration is more to do with User Agents, which is out of scope for this document. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-308 Ian Jacobs [Comment] * Please delete this point. I believe the purpose of this entire document is to explain to the reader what it means for content to be suitable for use in a mobile context. Do you mean "suitable" in the sense of "not offensive"? [I don't think you do; just checking.] [Working Group decision] As explained in the text, we simply mean that you're rarely interested in very detailed and long texts when using the web on a mobile devices, but that you would be generally speaking looking for specific information: "Users in a mobile context are often looking for specific pieces of information, rather than browsing. Content providers should consider the likely context of use of information and, while providing the option to access all information, should offer appropriate information first." [Commentor reply]

Output: yes

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


Input: [Commentor] LC-309 Ian Jacobs [Comment] I believe that the above checkpoint no longer exists in WCAG 2.0. I have not followed that debate recently, but I believe that it is so contentious as written (and not verifiable in any obvious way in that formulation) that you will regret having included it. I recommend talking to the WCAG WG about the evolution of their thinking in this area. [Working Group decision] The point is less to be measurable and more to provide best practice guidance. We are saying in the explanation below that a discursive style is usually less appropriate in the mobile context. It's an important point and we have kept it. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-311 Ian Jacobs [Comment] * How are you defining "what the user has requested?" Does that mean "Implement HTTP GET"? [Working Group decision] No, as we explain in the text below. 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]

Output: yes

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


Input: [Commentor] LC-313 Ian Jacobs [Comment] * I think the point of this document is to define what "usable" means. Therefore, I don't think you should have a checkpoint that says divide pages into usable pieces. Tell us instead what makes a piece usable. [Working Group decision] We believe the explanation under the best practice makes it clear what we mean by usable size. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-319 Ian Jacobs [Comment] * The first sentence of the second point here can be generalized to be "don't do things that the device can't handle." Because I don't think that is known in all cases, I suggest you delete the first sentence. Perhaps rephrase the point in terms of the default delivery context: "Very large or high-resolution graphics are unlikely to achieve their desired goal when rendered on devices with small screens. Avoid them unless there is no other way to provide the information in question." * In some cases, people may wish to download images for viewing on another device (e.g., I store something on my phone then view it on my desktop computer). You may wish to remind the author of that scenario. [Working Group decision] We keep this best practice as it is a classical problem in mobile web design and want to insist on this type of practical issue. On the 2nd point, we've included discussion on downloading items (under link_target_format). [Commentor reply]

Output: yes

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


Input: [Commentor] LC-322 Ian Jacobs [Comment] * Please stick very close to WCAG 2.0 on this one as well (I think it is 1.4.3). [Working Group decision] We stick close the WCAG 1.0 - the current W3C Recommendation. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-330 Ian Jacobs [Comment] * Please delete "unless the device is known not to support them" in favor of a general section on handling this sort of thing (as described above). [Working Group decision] Given that style sheets are part of the default delivery context, this get out clause is needed when a site adapts its content for a device that doesn't support style sheets. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-331 Ian Jacobs [Comment] * This also comes from WCAG, but I no longer see it in WCAG 2.0. Have you asked them why it was deleted? (I don't see it in the23 Nov 2005 draft) [Working Group decision] It may have been a WCAG point but the mobile interpretation is that some devices don't do style sheets. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-333 Ian Jacobs [Comment] * Delete this point and add to the list of things to "keep short": markup. [Working Group decision] We think these are separate concern that deserve separate contexts. While we may have chosen to organize the best practices in the way you suggest, we haven't found enough benefits behind your proposed re-organization to work on a major re-organization as you suggest. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-335 Ian Jacobs [Comment] * Please delete "Where possible" * I suggest merging these two into a single point about following standard protocols for content type negotiation. [Working Group decision] The point is that: * simple standard content negotiation works poorly in the mobile space. * It may not be possible to do it if you're not using content adaptation. * Respect the markup format the client is asking for. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-336 Ian Jacobs [Comment] * "to a minimum" is not well-defined. * Add this to the list of things to keep short. [Working Group decision] We prefer to have well-focused practical best practices rather than generic lists of items that fit under a same principle. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-340 Ian Jacobs [Comment] * Delete "appropriately" (twice) * By "explicitly" do you mean "through markup language features" (such as the "for" attribute in HTML)? * Please be more explicit about what appropriate positioning is rather than make this general statements. Is "before" better than "after" in reading order? [Working Group decision] We have removed the duplication of "appropriately". We have split the best practices in two to separate the concerns of labeling and positioning, but the proper positioning of labels with forms controls depends too heavily on the context to be specified more precisely. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-346 Ville Karinen [Comment] Hello all, i remember there was some discussion whether MWBP promotes One Web or not, but in any case, i guess one goal of the *document* is to explain different kind of approaches or strategies how Web can be served for/accessed via mobile device. "The primary goal is to improve the user experience of the Web when accessed from such devices." However, it seems that the document is concentrating mainly on authoring process. As we can change the existing Web very slowly, it would be informative for non-mobile Web experts to illustrate already existing Web to Mobile adaptation processes, which are based on proxy based conversion. These conversion proxies provide the most widest Web to Mobile resource today. Here are some examples which kind of proxies i mean: WEB TO MOBILE Google's quite new HTML -> XHTML MP converter: MWBP document (WAI) conversion as an example. This converter can handle even forms. (Opera Software MIDP browser based on proxy adaptation. This combination enhances site and browser usability) HTML-> WML conversion (handles forms also) Maybe it should explained more clearly, why WAI guidelines - for example - do not cater mobile devices enough. In my opinion, different kind of Web to Mobile proxies should be studied in the future working groups - especially with content conforming relevant (and existing) WAI guidelines. It is said, that the mobile handset can be the only Web device for many users in the third world. That is why it is important to note, that conversion proxies might be someties the only way to get information from the Web. Kind Regards, Mr. Ville Karinen Student (Agr. & For.) [Working Group decision] As stated in the "Classes of products" section [2], we're only dealing with "content as it gets delivered to a Web user agent". The way it is authored, adapted or proxied along the delivery chain is thus out of scope for our document, although we briefly explain where content adaptation fits in there [3]. Furthermore, a W3C Technical Report would not be the right place to present vendor-specific solutions for content adaptation. Nevertheless, the Techniques the Working Group has started to work on will present a set of technical advices regarding how to put the best practices in application; as these techniques will be open for contributions, maybe could you then suggest something along the lines of your email message? In the meantime, is there a way to rephrase your comment in a way that would fit in the scope of our best practices? Thank you very much for the time you took to review and comment on the document. Dom 1. link 2. link 3. link [Commentor reply]

Output: yes

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


Input: [Commentor] LC-352 Werner Egipsy Souza (Jataayu Software) on behalf of Jataayu Software [Comment] _5.3.1 URLs of Site Entry Points_ Here, if URLs for a menu system running into more than 5 pages can follow a URL syntax containing page numbers such as: link then it becomes easy for the user to navigate between pages, just by changing the page number on the URL, through the bookmark. Of course, if the browsing application itself could provide a page browser using this syntax, the user\'s task of navigating through pages would be much easier [Working Group decision] The Best Practice is about site entry points, to which this technique doesn't really apply. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-353 Werner Egipsy Souza (Jataayu Software) on behalf of Jataayu Software [Comment] _5.3 Navigation and Links _All the URLs for each page, must be listed in the options(or right click) menu, so that if a user he/she wants to go to a URL on the page, he/she just has to scroll through the options(or right click) menu to reach the required URL. then it becomes easy for the user to navigate between pages, just by changing the page number on the URL, through the bookmark. Of course, if the browsing application itself could provide a page browser using this syntax, the user\'s task of navigating through pages would be much easier [Working Group decision] This is a user agent issue and so out of scope. We do recommend use of access keys which can achieve the same goal of easing navigation. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-351 Werner Egipsy Souza (Jataayu Software) on behalf of Jataayu Software [Comment] _5.3.7 Link Target Identification _The cost of following a link,as in the case of articles, should be identified in the number of pages which are required by the article, as is done by the BBC Wap page. Hence we get a link at the bottom of the first page of the article, which says \"_Continued Page 2/4_\". The user is then able to choose whether he/she wants to read a 4 page article, or whether he/she should look for another article. [Working Group decision] We think this suggestion would be a good fit for a technique related to this best practice; we welcome techniques contributions in our wiki at: link [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-398 Zev Blut [Comment] 1.4 Default Delivery Context There is an entry for screen width, but not height. I think that there should be some value for a default screen height. [Working Group decision] We decided not to include the screen height because: * research showed that even being able to view only a few lines (4) was sufficient for a reasonable user experience * we didn't want to fix the aspect ratio [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-399 Zev Blut [Comment] 2.2 Input Discusses the potential lack of back button support, but in section 1.4 the default device supports XHTML- Basic. Is it not reasonable that if the default is assuming XHTML-Basic then the target default handsets have back buttons? [Working Group decision] The "back button" is not mandated by any of the specifications that defines the default delivery context, and in particular, there doesn't seem to be any evidence that any device supporting XHTML-basic would feature a back button. As such, we have kept our text regarding the back button as is. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-401 Zev Blut [Comment] What does the group consider a proper range for short URLs? [Working Group decision] No specific values have been defined for lengths of URLs because it was felt that specifying precise value might in practice prove too restrictive This BP should be interpreted as meaning if you have the choice between link http://example.com as the access point for your site you should choose the shorter one, which we have tried to clarify through additional examples. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-403 Zev Blut [Comment] 5.3.4 Navigation Bars etc. This is a good idea, but it makes me wonder how possible the one web vision becomes. If one wants to create a page that can provide an optimal display, the developer would need to do quite some work or use a powerful platform. I fear that some developers may give up trying to get the mobileOK mark if it becomes too difficult. [Working Group decision] This is a WCAG checkpoint and a fairly common usablity rule. Put the important stuff first. Note that the Best Practices and the mobileOK trustmark, while related, are different and it is not defined yet which best practice will be included in the definition of the trustmark. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-405 Zev Blut [Comment] 5.4.6 Image Size [IMAGES_SPECIFY_SIZE] Are there actual examples where not setting the width and height of an image actually hurts the display of the image by the browser? I am not so sure how necessary this is, especially when considering that providing this information increases the size of the page. [Working Group decision] We have clarified that specifying the intrinsic dimensions of an image allows that the browser doesn't have to re-flow the page in the course of displaying it (re-flowing creates usability problems due to changes of focus, and also may have a bad CPU/battery impact). [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-406 Zev Blut [Comment] 5.4.13 Error Messages This is also a great idea, but some handsets ignore the developer’s custom HTTP 5xx response and shows a built in error message to the user. [Working Group decision] Good point but clearly the content author can't do anything about this User Agent deficiency [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-416 on behalf of I18N WG [Comment] Please say about the participants in the mobile value chain s.t. like "these participants are working with multiple languages ...". [Working Group decision] We have removed the section on participants in the mobile value chain altogether since it was not necessary to the comprehension of the document. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-417 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 2 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 1.3 [link] Comment: On scope of MWBP 1.0: Please give internationalization as another example of general good practice which have a specific mobile interpretation. [Working Group decision] Our position on this is that if we reference other work we do so because of a specific mobile interpretation. As far as we are aware we do not make reference to any internationalisation as we feel that internationalization recommendations "are general to all forms of Web access". Please come back to us if we are mistaken. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-418 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 3 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 1.3.2 [link] Comment: On aspects of usability: Please mention that proper localization is part of localizability, e.g. in the case of site usability, device usability or browser usability. [Working Group decision] We do not think that this has a specific mobile interpretation; the section on usability has been removed in any case. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-423 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 8 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 2.4 [link] Comment: Travel related information might not be useful in a mobile context, since there might be no resource for translating. Please mention the need to make it explicit in the content that such resources are missing. [Working Group decision] Non availability of resources in the language of your choice is not a mobile specific issue. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-425 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 10 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 2.7 [link] Comment: Your mention the importance of mobile devices for developing countries. Esp. for these countries, internationalization and localization issues are crucial (e.g. support of a font for the script). such requirements should be made explicit in this document. [Working Group decision] We don't think this has a specific mobile interpetation. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-426 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 11 At link Editorial/substantive: E Owner: FS Location in reviewed document: General Comment: You don\'t have any normative references. Is this intended, and if yes, why? [Working Group decision] Yes, it is intended as the document is non normative. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-427 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 12 At link Editorial/substantive: E Owner: FS Location in reviewed document: General Comment: In sec. 4.2, you describe the structure of Best Practice Statements\". Nevertheless, many Best Practice Statements leave parts of this structure out. Will this be changed in a future version of this document? [Working Group decision] No, as some of the sections are not applicable to some of the best practices. We have clarified that "what to test" is left out on non-testable best practices. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-429 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 14 At link Editorial/substantive: S Owner: FS Location in reviewed document: Sec. 5.2.7 [link] Comment: Please mention that if in the content there is a link to something which is not in the same language, it would be good to make it explicit. [Working Group decision] We have mentioned "language" as being one of thing worth mentioning as part of the LINK_TARGET_FORMAT: "Links to content that is in a different format or different language to that of the page the link is on (i.e. content that can only be interpreted by other applications or downloads) should be human signposted" [Commentor reply]

Output: yes

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


Input: [Commentor] LC-432 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 17 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 5.4.13.2 [link] Comment: \"Please consider proposing that it would help bandwidth to store standard messages in the device itself, rather than download them each time.\" [Working Group decision] Recommending that HTTP errors be handled by the device itself would go contrary to the web architecture (e.g. preventing the content provider to give detailed information to the user as to what the error is and what may have caused it). [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-437 Al Gilman on behalf of WAI [Comment] 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. " [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]

Output: yes

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 [Comment] 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. [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]

Output: yes

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 [Comment] 5.3.7 Background Images should reference UAAG 3.1 Toggle background images (P1) - 1. Allow configuration not to render background image content. [Working Group decision] We have removed that Best Practice, since it didn't have a mobile-specific aspect. [Commentor reply]

Output: yes

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 [Comment] 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). [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]

Output: yes

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 [Comment] 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). [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]

Output: no reply from commenter

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 [Comment] 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. [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]

Output: no reply from commenter

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 [Comment] 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. [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]

Output: no reply from commenter

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 [Comment] 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. [Working Group decision] We refer only to ratified documents and not to works in progress. [Commentor reply]

Output: no reply from commenter

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 [Comment] 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). [Working Group decision] We have removed the section on usability. [Commentor reply]

Output: no reply from commenter

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 [Comment] 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. [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]

Output: no reply from commenter

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 [Comment] 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. [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]

Output: no reply from commenter

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 [Comment] 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. [Working Group decision] This is background overview section and is not intended to be an exhaustive explanation. [Commentor reply]

Output: no reply from commenter

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 [Comment] Chapter 2.4, User Goals: The first sentence should be rewritten. See also comment on chapter 1.3.3 above. [Working Group decision] Please suggest a rewrite or specifics if you think this is especially problematic. [Commentor reply]

Output: no reply from commenter

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 [Comment] Chapter 3, Delivery Model Architecture: The entire section after “3” should be numbered separately (e.g. made 3.1 Introduction). [Working Group decision] It is the document convention to have introductory text following major headings. [Commentor reply]

Output: no reply from commenter

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 [Comment] Chapter 5.1.1.2, How to do it: The references should be made more explicit. [Working Group decision] This BP has been removed. [Commentor reply]

Output: no reply from commenter

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 [Comment] 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. [Working Group decision] We refer only to ratified recommendations. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-261 Ian Jacobs [Comment] 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." [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]

Output: yes

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


Input: [Commentor] LC-262 Ian Jacobs [Comment] 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? [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]

Output: yes

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


Input: [Commentor] LC-269 Ian Jacobs [Comment] As you'll see below, I think you may wish to refer to some of the guidance of theUser Agent Accessibility Guidelinesas well. [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]

Output: yes

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


Input: [Commentor] LC-272 Ian Jacobs [Comment] 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. [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]

Output: yes

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


Input: [Commentor] LC-274 Ian Jacobs [Comment] 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? [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]

Output: yes

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


Input: [Commentor] LC-275 Ian Jacobs [Comment] Does this mean that you will have best practices for error handling below to avoid incomplete display or other problems? [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]

Output: yes

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


Input: [Commentor] LC-286 Ian Jacobs [Comment] Ah, that last sentence is already more informative in my opinion. [Working Group decision] Capabilities has been removed [Commentor reply]

Output: yes

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


Input: [Commentor] LC-292 Ian Jacobs [Comment] 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. [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]

Output: yes

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


Input: [Commentor] LC-310 Ian Jacobs [Comment] * How does this apply to prefetching? [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]

Output: yes

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


Input: [Commentor] LC-312 Ian Jacobs [Comment] 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. [Working Group decision] We have linked CENTRAL_MEANING and CLARITY since they both address the same range of topics. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-320 Ian Jacobs [Comment] * 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.) [Working Group decision] We reference WCAG 1.0 because this is the current W3C Recommendation. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-323 Ian Jacobs [Comment] * 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. [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]

Output: yes

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


Input: [Commentor] LC-324 Ian Jacobs [Comment] * 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." [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]

Output: yes

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


Input: [Commentor] LC-326 Ian Jacobs [Comment] * This is another instance of "Don't do X" when you are outside the default delivery context; regroup with those? [Working Group decision] As already noted, we don't think the benefits of grouping outweighs the costs. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-328 Ian Jacobs [Comment] * 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." [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]

Output: yes

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


Input: [Commentor] LC-329 Ian Jacobs [Comment] * 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." [Working Group decision] The text already reads: "Avoiding pixel and absolute measures allows the browser to adapt content to fit the display." [Commentor reply]

Output: yes

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


Input: [Commentor] LC-337 Ian Jacobs [Comment] * 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). [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]

Output: yes

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


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

Output: yes

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 [Comment] _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. [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]

Output: no reply from commenter

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 [Comment] 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. [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]

Output: no reply from commenter

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 [Comment] 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. [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]

Output: no reply from commenter

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


Input: [Commentor] LC-400 Zev Blut [Comment] 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? [Working Group decision] We say that this is relevant when the device does not respect the author's intentions. [Commentor reply]

Output: no reply from commenter

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 [Comment] 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.\" [Working Group decision] We have added the additional tests to execute in the "what to test" section. [Commentor reply]

Output: no reply from commenter

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 [Comment] 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...\'.) [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]

Output: no reply from commenter

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 [Comment] 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. [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]

Output: no reply from commenter

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 [Comment] 5.3.3 Scrolling There could be a stricter recommendation: Limit scrolling while reading a single text flow to one direction. [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]

Output: no reply from commenter

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 [Comment] 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. [Working Group decision] We agreed with this additional principle and generalized it in the Best Practice "EXTERNAL_RESOURCES". [Commentor reply]

Output: no reply from commenter

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