TIL: You can access a user’s camera with just HTML • Hacker News Board

Re: TIL: You can access a user’s camera with just HTML

#221

Post by epse » Wed, Sep 07, 2022, 6:42 AM UTC

codethief wrote: post #119

totetsu wrote: post #9

This is a site that shows the camera feed full screen and inverts in with css https://nega.radioac.dev/ I hacked it together in half an hour to give people a way to look at the uninverted version of my inverted analogue photos with their phones at exhibitions. most people were more excited to play with it on their phone than by the photos I took days making. :'( [edit oops this javascript ]

I'm getting a blank screen on Firefox for Android :(

It asked me for permission, then just worked, also Firefox for Android

Re: TIL: You can access a user’s camera with just HTML

#222

Post by grumbel » Wed, Sep 07, 2022, 7:36 AM UTC

onion2k wrote: post #186

grumbel wrote: post #95

Earlier quoted context omitted.

> I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML. If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. You can't bookmark a scroll position either and neither can you link it. If you split the document into multiple HTML files, you complete break the ability to search across the w…

Those are all flaws in browsers, not HTML. In the case of bookmarks that's not even a part of HTML. There's nothing stopping browser vendors solving the problems you're talking about but then you'll probably worry that browsers are becoming operating systems or something.

A bookmark is just a link and links are part of HTML. If you only workaround those issues only at the client level you aren't fixing anything, as the Web will still be crippled just the same. You need better ways to link content on the Web itself.

Re: TIL: You can access a user’s camera with just HTML

#223

Post by totetsu » Wed, Sep 07, 2022, 7:48 AM UTC

bpye wrote: post #212

totetsu wrote: post #202

Earlier quoted context omitted.

I'm always too lazy to make an online gallery, and I don't want HN knowing my instagram. But I just made a few snaps of what I had around and put them here. https://golden-taffy-476b64.netlify.app/photos_m/

I really appreciate that you put those up, there's something about the silhouettes of the two figures (2) that I really like.

Thank you. #2 is the most recent of these. It was made by projecting an iphone screen via a toy mirror and lens projector directly onto photo paper. Maybe it was influenced by this exhibition, https://topmuseum.jp/e/contents/exhibition/index-4040.html and Barbara Morgan that I saw there http://www.artnet.com/artists/barbara-morgan/4

Re: TIL: You can access a user’s camera with just HTML

#224

Post by account42 » Wed, Sep 07, 2022, 7:55 AM UTC

moring wrote: post #215

quintussss wrote: post #214

Earlier quoted context omitted.

This mindset is exactly why we all have to suffer with slugish electron apps and bloated websites instead of using fast, native apps written in something like Qt.

The actual reason is that nobody (probably not even you) wants to pay the substantially higher price of developing native apps, nor do they want the suffer the loads of crash bugs that inevitably come with using lower-level technology. The mindset of developers is what it is because the requirements demand so.

Oh please, "loads of crash bugs" are not and were never inevitable. And for the user experience, an exception that prevents you from doing what you want is not even that much better than a hard crash.

And let's not pretent that users are ever given a choice in the quality vs. cost tradeoff except for looking for a different program entirely. And even that is often not an option because the software needs to interact with systems that are actively hostile towards third-party clients.

We shouldn't excuse mediocre software just because the market puts up with mediocrity.

Re: TIL: You can access a user’s camera with just HTML

#225

Post by account42 » Wed, Sep 07, 2022, 8:30 AM UTC

acdha wrote: post #162

grumbel wrote: post #95

Earlier quoted context omitted.

> I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML. If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. You can't bookmark a scroll position either and neither can you link it. If you split the document into multiple HTML files, you complete break the ability to search across the w…

> If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. This isn't true on any popular browser or platform. Single-page scrolling using the keyboard, mouse, or touchscreen is built-in for all common browsers and scrolling even extremely large documents has been fine for at least a decade – unless you load it up with tons of JavaScript even in…

> You can't, and also wouldn't want to since that's inherently unstable (e.g. I resize the window slightly and all of the links break). What you can do is what people have been doing since around 1993 and put anchors on logical sections, paragraphs, etc. so you have a linkable stable anchor which doesn't depend on the window or font size.

Except there is no way to expose such anchors to the user without cluttering up the display. Giving users the option to create a bookmark to the nearest id-ed element + offset (perhaps with extensions to let the website specify which elements to consider) is an example of document support that is missing from browsers.

Chrome does have an extension to bookmark text fragments: https://support.google.com/chrome/answer/10256233?hl=en&co=G... Something like this should be standardized and also include a nearby ID to help find the location when the text changes.

Most pages also don't change that significantly/often and if they do they can just disappear entirely so anchor links aren't that stable either. Most browsers already do remember your scroll position when you refresh the page because even if it sometimes gets you to a different part becaus the preceding content changed it is still useful most of the time.

Re: TIL: You can access a user’s camera with just HTML

#226

Post by moring » Wed, Sep 07, 2022, 8:34 AM UTC

account42 wrote: post #224

moring wrote: post #215

Earlier quoted context omitted.

The actual reason is that nobody (probably not even you) wants to pay the substantially higher price of developing native apps, nor do they want the suffer the loads of crash bugs that inevitably come with using lower-level technology. The mindset of developers is what it is because the requirements demand so.

Oh please, "loads of crash bugs" are not and were never inevitable. And for the user experience, an exception that prevents you from doing what you want is not even that much better than a hard crash. And let's not pretent that users are ever given a choice in the quality vs. cost tradeoff except for looking for a different program entirely. And even that is often not an option because the software needs to interact…

> We shouldn't excuse mediocre software just because the market puts up with mediocrity.

The market has stopped putting up with mediocre software and chose higher-quality alternatives. The one thing that is not obvious to developers is that the market considers faster software with less features, hard crashes and limited portability as much worse than the web-based alternatives.

Re: TIL: You can access a user’s camera with just HTML

#227

Post by account42 » Wed, Sep 07, 2022, 8:52 AM UTC

meltedcapacitor wrote: post #174

_Algernon_ wrote: post #157

Earlier quoted context omitted.

The browser is inefficient. Use a modern website on a ten year old laptop and it is close to unusable because of modern web dev practices. That laptop is still perfectly usable for a lot of things. The modern web drives obsolescence second only to gaming, but while gaming is user driven and entertainment focused (i.e. not essential), the web is megacorp driven and also includes necessary modern infrastructure. That i…

"modern web practices" may be more to blame than the browser. It's possible to make lean fast things running on browsers (within reason), but the culture is nobody gets fired for bloat. It's ubiquitous, same for mobile apps, server side, etc.

The browser is responsible for providing web developers with ever-increasing resources to eat up. It also defers way an increasing amount of much functionality to javascript (or at least allows javascript to reimplement that functionality) - e.g. there is no native support for DASH video so you are always beholden to whatever js the website uses (unless you want to use website-specific hacks).

Re: TIL: You can access a user’s camera with just HTML

#228

Post by account42 » Wed, Sep 07, 2022, 9:00 AM UTC

johnfn wrote: post #86

amalcon wrote: post #83

Earlier quoted context omitted.

I recognize that this kind of thing is useful to the developer, of course, and we've gotten a lot of neat things this way. My worry is basically that the absent functionality is the best thing about the web as a user. Take the notification API: One of the nice things about web pages and apps is that they stop bothering me once I close them; not so if I accidentally permit notifications! Fortunately I can turn that wh…

I don't know, this seems like a good compromise to me. Some apps (calendar) would be absolutely crippled without them. For everything else, I've just never turned them on in the first place. > I wish there were a permission pop-up before playing sound at all The browser can't actually play sound unless 1) it's triggered as the result of a user action (such as a mouse click) or 2) if you've often listened to sound on…

> The browser can't actually play sound unless 1) it's triggered as the result of a user action (such as a mouse click) or 2) if you've often listened to sound on that page in the past.

The point is that a click should not give the website permission to play audio - that should be handled much explicitly and not just the user selecting text or some other interaction. Besides, last time I checked Firefox still let AudioContext play sound without any user interaction even though the element has more restrictions. Which is another problem: the HTML + JS spec is too bloated to properly secure things.

Re: TIL: You can access a user’s camera with just HTML

#229

Post by account42 » Wed, Sep 07, 2022, 9:03 AM UTC

lcnPylGDnU4H9OF wrote: post #118

amalcon wrote: post #96

Earlier quoted context omitted.

My answer to this is that the calendar just does not need to be a web app. Weakening a primary advantage of everything else on the web just so that my calendar can be a web app seems like a poor trade-off. Re: sound, "Triggered as the result of a user action" is not a high enough bar.

> the calendar just does not need to be a web app And the chat app, and the email app, and the social media app (other opinions about social media notwithstanding). I think each of these things have their own legitimate use for notifications. I guess it's the point of "weakening a primary advantage". I don't see how it's weakened (or rather, I don't see how it's a problem) when the notifications are on a per site per…

The world would be better off if social media apps did not have notifications.

Re: TIL: You can access a user’s camera with just HTML

#230

Post by onion2k » Wed, Sep 07, 2022, 10:28 AM UTC

grumbel wrote: post #222

onion2k wrote: post #186

Earlier quoted context omitted.

Those are all flaws in browsers, not HTML. In the case of bookmarks that's not even a part of HTML. There's nothing stopping browser vendors solving the problems you're talking about but then you'll probably worry that browsers are becoming operating systems or something.

A bookmark is just a link and links are part of HTML. If you only workaround those issues only at the client level you aren't fixing anything, as the Web will still be crippled just the same. You need better ways to link content on the Web itself.

A bookmark is just a link and links are part of HTML.

Bookmarks are entirely part of the browser UI. They're an entry in a database of URLs that the browser presents to the user, and when the user clicks on one it tells the browser to navigate to that address. There is absolutely no HTML involved.