Edit comment LC-2547 for Device and Sensors Working Group

Quick access to LC-2514 LC-2515 LC-2517 LC-2518 LC-2519 LC-2520 LC-2521 LC-2522 LC-2523 LC-2524 LC-2525 LC-2527 LC-2528 LC-2529 LC-2530 LC-2531 LC-2547 LC-2557 LC-2558 LC-2559 LC-2560

Comment LC-2547

Comment Shortname:

Commenter:

On Behalf Of:

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeAbstract The Contacts API defines the high-level interfaces... Status of This Document This section describes the status o... 1. Introduction This section is non-normative. Every operat... 2. Conformance As well as sections marked as non-normative,... 2.1 Terminology The terms document base URL, browsing conte... 3. Security and Privacy Considerations The API defined in... 3.1 Privacy considerations for implementors of the Contacts... 3.2 Privacy considerations for recipients of contact inform... 3.3 Additional implementation considerations This section i... 4. API Description 4.1 ServiceContacts interface The Servi... 4.1 ServiceContacts interface The ServiceContacts interface... 4.1.1 Attributes contacts of type Contacts, readonly The o... 4.2 Contacts interface The Contacts interface exposes a dat... 4.2.1 Methods find Find contacts in the address book acc... If successCallback is null, then throw a TypeError (as defin... 4.3 Contact interface The Contact interface captures the pr... 4.3.1 Attributes addresses of type array of ContactAddress... 4.4 ContactName interface The ContactName interface describ... 4.4.1 Attributes familyName of type DOMString, nullable T... 4.5 ContactField interface The ContactField interface is a... 4.5.1 Attributes pref of type boolean This attribute indi... 4.6 ContactAddress interface The ContactAddress interface i... 4.6.1 Attributes country of type DOMString, nullable This... 4.7 ContactOrganization interface The ContactOrganization i... 4.7.1 Attributes department of type DOMString, nullable... 4.8 ContactFindOptions interface The ContactFindOptions int... 4.8.1 Attributes filter of type DOMString, nullable A stri... 4.9 ContactFindCB interface This is the wrapper interface f... 4.9.1 Methods onsuccess Parameter Type Nullable Option... 4.9.2 Event Handler Attributes The following is the event h... 4.10 ContactErrorCB interface This is the wrapper interface... 4.10.1 Methods onerror Parameter Type Nullable Optiona... 4.10.2 Event Handler Attributes The following is the event... 4.11 ContactError interface The ContactError interface enca... 4.11.1 Attributes code of type unsigned short, readonly An... 4.11.2 Constants INVALID_ARGUMENT_ERROR of type unsigned... 5. Contact Search Processing The Contacts find() method pr... 5.1 Search Qualifiers The search qualifier provides an appl... 5.1.1 Advanced Search Qualifiers We call composed attribute... 5.2 Options Processing 5.2.1 Search Cardinality By default... 5.2.1 Search Cardinality By default, the Contacts find() o... 5.2.2 Search Filters A search filter may be specified from... 6. Extended Contact Properties and Parameters The propertie... 7. API Invocation via DOM Events The API contained in this... A. User Interaction Guidelines This section is non-normativ... A.1 Accessing Contact Information - Example #1 A website re... A.2 Accessing Contact Information - Example #2 A website re... B. Adding and Updating Contacts This section is non-normati... B.1 Adding a new Contact This section is non-normative. A w... B.2 Updating an existing Contact This section is non-normat... C. References C.1 Normative references [DOM-LEVEL-3-EVENT... C.1 Normative references [DOM-LEVEL-3-EVENTS] Björn Höhrma... C.2 Informative references [FILE-API] Arun Ranganathan. Fi...
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody Bah, Slimane Bernhart, Bryan Bhaumik, Rijubrata Bogdanovich, Ilya Caceres, Marcos Christiansen, Kenneth DADAS, Mohammed Gouaillard, Alexandre Grant, Reilly Hazaël-Massieux, Dominique Hirsch, Frederick Hu, Ningxin huang, qigang Hwang, Dongseong Jeon, Jonathan Kang, Shin-Gak Kim, Sung Hei Kim, Sunghan Kinlan, Paul Kis, Zoltan Kliche, Ingmar Kollarova, Martina Kostiainen, Anssi Krishnan, Sanjay Lamouri, Mounir Lee, Dong-Young Lee, Kangchan Lee, Seungyun Lee, WonSuk Lin, Wanming Liu, Dapeng Liu, Guanyu Logvinov, Andrey Mandyam, Giridhar McCathie Nevile, Charles Mehrnezhad, Maryam Mikityuk, Alexandra Nilsson, Claes Olejnik, Lukasz Pashidis, Michallis Poussa, Sakari Pozdnyakov, Mikhail Raggett, Dave Scheib, Vincent Shalamov, Alexander Song, Jungkee Spreitzer, Raphael Steglich, Stephan Stojiljkovic, Aleksandar Tran, Dzung Waldron, Rick Walsh, Michael WEI, XIAOHAI xiong, aiden Xue, Fuqiao Yamamoto, Eiji Yamazaki, Fumi Zhang, Rong Zhang, Zhiqiang zhong, heng

Type: substantive editorial typo question general comment undefined

Comment:Below is feedback from the Protocols and Formats Working Group on the Contacts API. Apologies that this arrives so far after the review deadline, it takes a while to organize group review particularly in the summer. (1) Re: 'photos' attribute, http://www.w3.org/TR/2011/WD-contacts-api-20110616/#attributes-1 The spec does not allow to provide an alternate text or a description to any of the photos. However, since the photos are meant to be used as profile photos (explicit note provided), in general the name of the contact person should be sufficient to be used as alternate text. (a) The following accessibility-related problem could still occur: A contact item has a photo, but no name and no displayName is provided (all attributes except 'id' are optional). * This would be a clear disadvantage to the visually impaired users. * Proposed change: Add the following note: "If one or multiple photo fields are provided, either the 'displayName' or the 'name' attribute should have reasonable content, thus serving as alternate text for the photos." (b) It is not clear what information the 'type' attribute should carry for a photo item. Is this intentionally left unspecified? The spec would benefit from clarifying what information should go into the 'type' attribute for photos, even if only by examples. Regarding 'type' information on photos, we wonder if this information would be useful for semantic purposes, in order to be able to differentiate between multiple photos and their appropriate use. For example, by marking the photos as "work", "leisure", etc., an application could automatically suggest an appropriate photo for a particular situation (e.g. job application, social networking site, etc.). This would also be helpful for people with visual impairment, as part of an automatically generated alternate text for the photos. (2) Re: 7. API Invocation via COM Events, http://www.w3.org/TR/2011/WD-contacts-api-20110616/#api-invocation-via-dom-events * The event types mentioned include mainly mouse-specific events (dblclick, mouseup). However, in the spirit of device-independence a user should also be able to activate the Contact Picker via keyboard. * Proposed change: Add "keypress" and "keyup" to the list of allowed even types.. (3) Re: A.1 Accessing Contact Information ­ Example #1, http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example‹1 <http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example--1> * In the example shown, it is not clear what the "Select" operation applies to. Can the user select the information fields only (as shown on the left), or can they also select and exclude individual contacts? * Proposed change: Use checkboxes on the right side to select specific contacts (the same as on the left side for selecting the information fields). (4) Re: A.2 Accessing Contact Information ­ Example #2, http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example‹2 <http://www.w3.org/TR/2011/WD-contacts-api-20110616/#accessing-contact-information---example--2> * Why is there no mention of the non-blocking contact search notification, as in example #1? * Proposed change: Clarify. (5) Re: Formatting issue with table header cells in the spec Header cells in tables (like the table in 4.9.2 <http://www.w3.org/TR/2011/WD-contacts-api-20110616/#event-handler-attributes>) are displayed as inverted (white on blue). When rolling over its text, the text color remains white and the background color is set to a light yellow. This is not readable anymore. The problematic layout rule is contained in http://www.w3.org/StyleSheets/TR/W3C-WD, line 56ff: @media screen { /* hide from IE3 */ a[href]:hover { background: #ffa } } (6) Typos * "acheive" in Section B. Adding and Updating Contacts, http://www.w3.org/TR/2011/WD-contacts-api-20110616/#adding-and-updating-contacts

Related issues: (space separated ids)

WG Notes:

Resolution:

(Please make sure the resolution is adapted for public consumption)

Check to confirm deletion (not reversible)