Re: Proposed additions to manifest (v2)

[Harald Kirschner]

> I know I was one of the initial proponents of using the list off
> modernizr, but in thinking about this with the recent Ringmark
> announcement, one question that's worth considering is, can we simply
> use something coarse grained as a ring level for our first iteration? It
> feels like it would keep things simple and we can add more fine-grained
> options later if there's a need.
>
> Thoughts?

Just to throw in another useful resource for possible feature names: has.js, which is more focussed on JS APIs and their capabilities (modernizr's focus is CSS, though they have a eclectic mix). As you can see in has.js tests, its a *very* exhaustive and detailed list: http://dante.dojotoolkit.org/hasjs/tests/runTests.html

As an exercise we could assemble one big list of all possible features, mixed from modernizr, has.js and our own needs … and then boil it down to what our 100+ Tier 1/2 apps would eventually need, reviewing their code. Another idea is to start a poll in our dev community, which features they would like to detect. We might up with a smaller list than expected.

---
Harald Kirschner | Mozillian Software Engineer | hkirs...@mozilla.com (mailto:hkirs...@mozilla.com)

[Ian Bicking]

On Wed, Mar 14, 2012 at 11:21 AM, Harald Kirschner
<hkirs...@mozilla.com>wrote:

I imagine it will be fairly small, because we're only interested in
make-it-or-break-it features. If a browser doesn't support Array.forEach,
is it worth figuring out if you use that and noting that in your manifest
as a requirement, or just avoiding that method or patching Array to add it?

The features I think will be most important:

- Offline storage
- WebGL
- Maybe some older things, like Canvas (is there a point when we don't
expect apps to specify features, like we aren't expecting anyone to support
IE6?). VML?
- CSS transforms
- There might be some subtle features that are necessary for good games
performance (CSS transforms are kind of an example of this – it's not
always possible to have fallbacks that perform reasonably)
- Audio and video (I'm guessing there may be finer levels of support that
apps might want, like H.264). You know DRM will show up eventually.
- Flash. And yeah, Silverlight.
- WebSockets, SSE, though likely only if you need particular performance –
chat servers might like WebSockets, but can work fine without them; some
games may not. Also some app developers simply won't care to handle
backward compatibility, even when it's possible to do.
- WebRTC
- Some particular new and upcoming features that truly enable new
categories of apps. But not every new thing is like that. Notifications?
Eh. But if there's an API to *manage* notifications (not just send them),
then I would expect some categories of apps to be useless without that.
Though I guess in theory an app that created notifications from some other
app might rightly require that feature (like you can imagine right now
someone could make notifications for Twitter in a non-Twitter app by using
their API – using that app on a device without notifications would be
pretty useless).

Modernizr doesn't address most of these particularly well, and maybe has.js
even less so (it seems focused on even lower-level features). I think it
would make more sense to maintain our own list, fairly minimal but extended
based on feedback.