GetUserMedia API lands on Chrome | Hacker News Reader

GetUserMedia API lands on Chrome

chrome.blogspot.se

63 pointssreeix37 comments

And of course its half-done. Asks me if I want the site to allow use of my non existing camera, and the options dropdown just has a (none) entry in it.

It's the same approach as with downloads. To this day, the only browser to support resuming downloads (and making use of HTTP range) is Opera.

As a developer I like that I can use the API now instead of just reading about it. Chrome rolls out updates very smoothly and rapidly, who cares if the initial support of a very new standard is not perfect? It sure beats the support that FireFox, IE and Safari have (none).

For this particular feature; there are plenty that Chrome doesn't support fully (IndexedDB) or at all (CSS calc) that those other browsers have had for quite a long time.

Do you mean this IndexedDB? http://caniuse.com/#feat=indexeddb . Or this calc? http://caniuse.com/#feat=calc . They look pretty supported to me, remembering that they're both based on a draft specs.

Calc must be new; this is great, this means Firefox, WebKit, and IE10 all have it.

IndexedDB is using an outdated spec more than 8 months old.

Have you actually tried to use IndexedDB in Chrome? It's on an outdated spec draft from around a year ago.

CSS calc has been in Chrome (behind a -webkit prefix) since Chrome 19.

http://caniuse.com/calc

Firefox got support for getUserMedia in July... https://hacks.mozilla.org/2012/07/getusermedia-is-ready-to-r...

Using Nightly go to about:config and enable the media.navigator.enabled pref, then you can test it out at this page: https://people.mozilla.com/~anarayanan/gum_test.html

> Using Nightly go to about:config and enable the media.navigator.enabled pref, then you can test it out at this page

That's not support. Support is on the shipping main branch. Chrome has had support for a while too if you wanted to jump through some hoops.

Why is that half-done? What should it have done instead?

Maybe you have some USB camera you want to plug in when some site makes such request.

Tell me I don't have a webcam connected and inform me that this site requires one, and possibly wait for me to connect one.

Right now, I get the permission bar, click "accept" and it fails silently. And the "none" thing is really just a bad taste; you don't offer UI elements when they don't do anything.

(I didn't try, but I think that permission dialog wouldn't even recognize it when I connected a camera after it opened)

I don't agree, as others have said, this dialog could have served to remind you that you had forgotten to plug in your USB webcam.

These days, no camera is surely an edge case that I think they handled fine.

Opera is not the only browser to support resuming downloads. With the appropriate server headers and local state, Safari and FireFox can also resume downloads.

I believe Chrome does as well.

Well, we have camera and mic APIs.

How about we get around to <input type=date> now?

EDIT: That camera toy thing is a lot of fun. It has an awful lot of effects.

EDIT 2: The xylophone is also pretty cool. I want to play around with this, see what I can make. The xylophone app's entire source is this: http://www.soundstep.com/blog/experiments/jsdetection/js/app...

EDIT 3: Wow, I am seriously impressed by Sketchbots. Very, very nice.

> How about we get around to <input type=date> now?

It's been in Chrome stable for five weeks now. :) <input type=color> as well. http://miketaylr.com/code/html5-forms-ui-support.html

Chrome's webforms status is here: http://www.chromium.org/developers/web-platform-status/forms and www.chromestatus.com usually captures everything else.

Oh hi π.

My bad, I didn't realise Chrome had it yet.

Now I just need a use for it...

I have been using input type date a lot recently. My app is chrome only and has to serve not very tech oriented people. And telling them to add date in a specific format is a huge pain in the ass. So input type date and even color to some extent have saved me a ton of support time. Although the interface can be better. It looks like a poorly designed html popup. (Although it is probably exactly that since chrome uses shadow DOM)

Yeah, it doesn't feel native. It looks like something from a Google GUI framework.

It uses GTK native color picker in linux, but the date input is not native one.

I noticed that myself. I'd kinda prefer a browser picker, but I suppose using OS controls is good generally.

What part of your app requires that it be "Chrome only"? There are tons of Javascript UI libraries that can handle date inputs cross-browser such as jQuery UI. http://jqueryui.com/demos/datepicker/

Yes, i am familiar with libraries, but since i will have physical access to all the user's computers (it's an app for a school's teachers) i though i might as well just support the newer browsers and don't support older ones at all. And i am also not a fan of libraries like jquery. Most of the modern browsers can do what they do a lot quicker.

And i should have mentioned, it is not strictly chrome only, but i have told all teachers to use chrome because firefox does not have date pickers yet. But the site is still completely functional in latest firefox and safari plus ie10 (provided teachers add dates manually). I just don't like using libraries at all. I try to avoid them until absolutely necessary. So much that i have never had to use jquery, or any other library for that matter. The app in question is quiet elaborate (feature wise) but still does not have a single file not written by me. It may not be the wisest thing to do, but it makes me comfortable to know exactly what my code is doing.

Why are you complaining about the lack of a feature that you don't have a use for?

Someone else pointed it out in another thread, and I'm also bothered by it, that we seem to be gaining advanced hardware access etc. yet seemingly not basic form controls. Although I was mistaken on the Date picker.

Probably the wrong place to ask...

Why does <input type=date> display the field in format MM/DD/YYYY in the field but the value property is formatted in YYYY-MM-DD?

Is the former a localization setting and the latter the standardized format? Is there any customization available? Also, no input[placeholder] support.

Example: http://jsfiddle.net/dUc5V/3/

It's probably localization, yes, since to me it shows up as DD-MM-YYYY.

It displays based on locale. YYYY-MM-DD is the ISO Standard[1], which is also used in ES5 as the standard date/time representation.

[1]http://en.wikipedia.org/wiki/ISO_8601

http://behero.us/ reused the xylophone code to build something like guitar hero

Cool, but "Kinect in the browser" is a gross exaggeration on their part.

sure, they would need a (reduced) stick figure detecture for it to be a proper kinect in the browser.

And they don't even have any of that lovely depth information.

It looks like this is already in Firefox, too, at least in nightly builds (compatible? Haven't looked at it that closely, but I hope so).

Now if only Safari will follow suit with a compatible implementation...

The snow effect on the webcam toy is incredible. You can shake off that which settles! It falls in place but still... very impressive.

Webcam toy is one of the coolest things I've seen in a long time. Shows the potential of an open web to the fullest paired with skills and imagination.

Warp speed.

http://neave.com/webcam/html5/

I've being playing with WebRTC for a little while and I love that we are saying goodbye to Flash for accessing devices (which no one has mentioned yet).

I built my own site photo booth site to give the new JavaScript a go.

http://gotcaption.com/

Next is to update the code for it for working Firefox Nightly. Hopefully the browser vendors will consolidate the API and stop using vendor prefixes.

Can't wait for WebRTC to start getting wide support. Can't get here fast enough.

Reply on news.ycombinator.com