Feature detection is somewhat weird

[sicking]

I don't feel strongly here, but the way the feature detection works is pretty unusual. This pattern appears nowhere else in the web platform.

Not a huge deal in and of itself, but at least warrants some discussion on the mailing list to see if there's existing patterns that can be reused.

One somewhat unfortunate aspect of how it currently works is that you have to get access to an IDBDatabase or IDBTransaction object before you can do feature detection. That makes it hard for a library to do detection when the library is first loaded.

It might be better to stick a static function somewhere instead.

[dmurph]

I talked with Josh (@inexorabletash), and he mentioned that he remembered how some other features are detected on the web platform:

Calls with options return an object with those options populated, so the developer can check to see which options that the specified were reproduced in returned options. This can also help with option modes, where a browser only supports mode A and I want B. When I specify B, I can check the options returned and see that A is there, so the browser only supports A.

Not the best, especially because i requires the IDB* objects like you mentioned. I'd be open to a static function. WDYT josh?

[inexorabletash]

Hrm, that's not quite what I was envisioning. Generally options would end up exposed as readonly attributes on the object they represent - I wouldn't introduce a separate objects for that.

So mechanically:

interface IDBObserverControl {
  readonly attribute IDBDatabase db;
  readonly attribute boolean transaction; // reflects option
  readonly attribute boolean onlyExternal; // reflects option
};

// Maybe change this to an interface?
dictionary IDBObserverChanges {
  IDBDatabase db;
  IDBTransaction transaction;
  boolean value; // reflects option
  boolean noRecords; // reflects option
  sequence<IDBKeyRange> ranges; // reflects option
  any records;
};

... but that points out that the names of some of these could use tweaking (e.g. plural for value vs. noRecords). Also, the feature detection can be done for many of these simply by the lack of data in the response e.g. if transaction is in the result dict, it is supported; similar for value and noRecords. So I'm not sure there's a huge value in most of these. onlyExternal makes sense, as does including the ranges.

Aside: Should db attributes/dictionary members be spelled connection instead?

[sicking]

Another approach that we could take here is to look for a genric mechanism for feature-detecting dictionaries and enums.

I.e. right now it's generally easy to detect support for features that live on WebIDL interfaces by looking at window.InterfaceName.featureName. However this is not true when a feature lives as a property on a dictionary or as a value in an enum.

We could define something like window.dictionaries.DictionaryName.featureName and window.enums.EnumName.enumValue.

I'm curious how JS libraries deal with this. It seems like this is going to become a more common problem given that ES6 has added syntax sugar for allowing dictionary arguments.

@domenic might know or have an opinion.

Generally speaking, I don't have an opinion here at all, as long as whatever we do has been vetted by enough people that we don't have to redo it.

[domenic]

Sounds like whatwg/webidl#107

[dmurph]

I'm going to delete the feature detection parts of the description and IDL, and we can figure that out later.

[sicking]

Sounds good to me. Hopefully WebIDL will grow a generic solution.