On 4/11/2012 3:23 AM, Jonas Sicking wrote:
> On Tue, Apr 10, 2012 at 11:37 PM, Randell Jesup<
rje...@mozilla.com> wrote:
>> I'd like to move this discussion to the dev-media public mailing list,
>> barring objection.
Doing so with this comment; please followup to dev-media
>> On 4/10/2012 10:30 PM, Jonas Sicking wrote:
>>> I'm obviously very late into this thread. I should have payed more
>>> attention.
>>>
>>> I have for a long time been pushing<input type=file> as the way to do
>>> this. It's been hard to get traction behind this idea, but I believe
>>> in part because of it's sorry state of implementation. However
>>> recently things have improved so let me recap where we are:
>>>
>>> In native-Fennec builds the following things work:
>>
>> (uses of<input type=file> snipped)
>>
>>
>>> As for getUserMedia({ picture: true }), we have a patch to display
>>> exactly the same UI as when<input type=file accept="image/*">.click()
>>> is called. However no support for desktop at all.
>>>
>>> That said, getUserMedia({ picture: true }) has advantages:
>>> * It's consistent with other patterns of getUserMedia which will
>>> emerge once we have full WebRTC support.
>>> * We can make it work in workers.
>>>
>>> In the end, maybe we should have both since I know some developers
>>> prefer pure javascript APIs, whereas others like elements even for
>>> things that don't have in-page-rendering such that the DOM is their
>>> one-stop-shop for state/user interaction.
>>>
>>> But I'm also concerned that we get stuck with a mozilla-only API if
>>> other vendors aren't interested in getUserMedia({ picture: true }) and
>>> instead push the<input type=file> route.
>> I'll address this last point, as I've participated in the Media Capture Task
>> Force formed for this purpose. I see no indication that<input> is being
>> pushed by any browser maker and the draft for using it for image capture is
>> abandoned I believe; conversely I see them largely lining up behinds
>> getUserMedia. The Task Force itself was created largely because Microsoft
>> wanted to participate but couldn't due to W3C IPR rules and issues around
>> getting clearance from MS lawyers; in fact a Microsoft person is chairing
>> the Task Force.
>>
>> The biggest issue is the classic one of exposing APIs before the standard is
>> agreed to - they may change. However, I think we'll know the final
>> direction of getUserMedia() for pictures in short order, and also we'll
>> likely prefix getUserMedia for now as Chrome has. (Opera exposed it
>> directly already, and is fighting any API change. It's possible we'll
>> change the name when it's un-prefixed.)
>>
>> The current<input> support will likely remain around due to the normal
>> forces protecting anything that gets sufficient use.
> The draft for "using [<input>] for image capture" was never a very
> well drafted spec. Simply because it was never shown to be necessary.
> I.e. HTML 4 has always had enough of a feature set to implement still
> picture capturing, and HTML 5 a long time ago added the missing pieces
> to get it to feature parity with the current getUserMedia({ picture:
> true }) proposal.
>
> So I wouldn't say that it's demise is meaningful in any way.
>
> I'm ok with exploring getUserMedia, but I strongly believe it would be
> bad for the web to reduce<input> to being a legacy API which we
> should not invest in. It has several nice properties including
> integration with form validation, accessibility, and DOM Events. The
> feedback that I've gotten lately from developers is to have *more*
> APIs done through elements rather than less. For example I've heard
> several requests that the Geolocation API should have been done
> through form integration rather than as a pure JS API, and same
> argument for the up coming joystick API.
An interesting viewpoint; to be honest I'm not up on the issues here,
but a generic note of caution would be that almost any decision will
result in some people saying "couldn't you do it the other way instead?"
> My plan is similarly to add contact support to<input> as a more
> secure version of the current Contacts API.
>
> Also, the claim that browser developers aren't pushing for<input>
> integration but rather getUserMedia doesn't seem to match what I'm
> seeing in Chrome for Android.
We know the WebRTC project in Google has just officially started
supporting Android builds this month, so it appears they are moving
forward with full WebRTC there, at least in Chrome. It's very hard to
say what they'll do in the current default browser; in the longer term
that might become Chrome or they might add WebRTC - and even if they
don't, they may add getUserMedia. Microsoft seems to be pushing this
direction (per my comments), and Opera (if it matters) has already
deployed it un-prefixed. Apple is Apple, and hasn't said anything.
> So I'm ok with exploring getUserMedia. But I still don't understand
> the urgency in pushing the API in ways that doesn't add anything
> beyond the already existing<input> support. Especially when the
> latter works better across browsers and so seems like the better
> choice for authors right now.
If you want to use it in a programmatic way from JS, <input> is annoying
though not necessarily blocking (IIRC).
My expectation is that future uses will move to getUserMedia, especially
once it supports additional controls and constraints. Controlling the
display of live preview, modifying it, allowing the app to control when
to take the picture (modulo security issues), resolution selection,
flash control, etc, etc are all things that will likely come via
getUserMedia/MediaStreams and I don't see coming via <input>, and I
don't see anyone re-opening standardization of these via <input>
You may be right that the simplistic getUserMedia solution won't have
all of these (and in fact would be prefixed). But it would make it
easier to add support for those when they become available. Building
around <input> will likely lock you in to a simple snap-an-image
ability. This may be fine for many uses; if so: great. And I don't
think anyone is saying "don't support <input>".
Randell