Edit comment LC-2558 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-2558

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:Several classes implement a formatted field that is defined as: This attribute contains the full physical address including street, locality, region, postalCode, and country as appropriate, and formatted for display. Is this supposed to be active (e.g. if I change region on an address, it automatically updates), or is this a snapshot? If we allow diverging formatting, writing these objects back (assuming we do add an edit feature) becomes pretty confusing. If we don't plan on adding edit, why are these fields not readonly? Andreas [NoInterfaceObject] interface ContactAddress { attribute boolean pref; attribute DOMString? type; attribute DOMString? formatted; attribute DOMString? streetAddress; attribute DOMString? locality; attribute DOMString? region; attribute DOMString? postalCode; attribute DOMString? country; };

Related issues: (space separated ids)

WG Notes:

Resolution:

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

Check to confirm deletion (not reversible)