Detect which contact properties are supported by the browser

[rayankans]

It might be a good idea to expose which ContactPropertys are supported by the browser. The properties will expand to include icons & addresses in the future, and probably some other things as well.

Having a way to detect which will remove the need for browser sniffing and give UAs a way to opt-out of some properties if they are not available on a given platform.

This can be easily achieved by having a read-only property in ContactsManager which is the list of supported ContactPropertys.

[domenic]

Can you explain more why it is important to distinguish between "this user agent does not support property X" and "this contact does not have a value for property X"?

[rayankans]

It's not about distinguishing whether the contact has a value for that property or not.

Ideally, if you want to request a property (say address), it would be nice to know if the browser supports it before making a call instead of try/catching.

[domenic]

JavaScript doesn't require try/catching. It will just give undefined for accessing a property that does not exist.

[rayankans]

Yeah, but you'd still want to know ahead of time if requesting a property is supported so you can have a fallback.

Also, I'm not a fan of allowing the select function taking any garbage values and just ignoring them. The spec allows for that right now, and I'm planning to update it to reject if you request a property not in the ContactProperty enum.

[domenic]

I'm still not understanding. Can you provide a code example? It seems like you should provide a fallback if the field is missing, too.

The spec allows for that right now, and I'm planning to update it to reject if you request a property not in the ContactProperty enum.

That's against general web design principles and forward-compatibility. Please do not do that.

[rayankans]

The spec allows for that right now, and I'm planning to update it to reject if you request a property not in the ContactProperty enum.

Actually, what I said was wrong, it's already enforced by the IDL compiler.

I'm still not understanding. Can you provide a code example? It seems like you should provide a fallback if the field is missing, too

Let's assume you want access to a contact's icon. If you don't have a way to know whether the browser supports that, you'd need to call navigator.contacts.select(['icon']), at which point it will either go though, or reject because icon is not supported.

Ideally, a developer should be able to run something like:

if (isSupported('icon')) {
  navigator.contacts.select(['icon']).then(...);
} else {
  // Create a Form or something equivalent.
}

Where isSupported could be something like checking if 'icon' exists as an attribute in ContactsManager/ContactInfo.