Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HTML element

developer.chrome.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: The <usermedia> HTML element

#51

Post by shimman »

oaiey wrote: post #29
shimman wrote: post #27

Earlier quoted context omitted.

Standards are democratic controls for democratic institutions, not "organizations" that are entirely captured by corporate interests. Absolutely despise how private entities have ruined software engineering by pursuing things that favor themselves rather than people in general.

That is not how standards work. Some for sure, but the majority are established by groups of companies / a guild establishing rules. The law pressures them often into it (e.g. the EU did not say USB-C port, they said: one standard, you industry figure it out). There are surely exceptions (maybe the IEEE; which are professionals union).

No, this is how good standards bodies works. It require collaboration across nations, sorry but this is like small d democracy stuff here. What isn't good are corporate interests rat fucking engineering practices to pursue greater profits.

Re: The <usermedia> HTML element

#52

Post by pie_flavor »

austin-cheney wrote: post #42
pie_flavor wrote: post #32

Earlier quoted context omitted.

It's not very complicated to import the QUIC library, or to import the HTTP library with HTTP/3 supported. For the library authors, QUIC isn't more complicated to implement than TCP. Doomsaying about the complexity of Google Sheets is completely unrelated to whether QUIC is good tech and superior to TCP, which it is; the only remaining complaint is that it's too new to have been part of the kernel yet, and if that ma…

That is also entirely incorrect. There are many challenges to implementing an original QUIC library. The Node.js project is developing and evaluating for this right now and the effort is extensive.

There are also many challenges to implementing an original TCP library.

Re: The <usermedia> HTML element

#53

Post by wahern »

austin-cheney wrote: post #48
wahern wrote: post #46

Earlier quoted context omitted.

I couldn't find any evidence Google pushed QUIC with the aspiration of utilizing IP multicast. In 2022 an RFC for adding multicast support to QUIC was published, but backed by Akamai, not Google. And of course the RFC has the caveat that it would only be useful over multicast networks, e.g. edge servers colocated at an ISP. It seems this effort has picked up some steam over 2025 and 2026. But I didn't look too hard.…

Here is a Google Chrome discussion about it from 2018: https://groups.google.com/a/chromium.org/g/proto-quic/c/pAQz... Here is a quick overview (undated) from Google about it: https://peering.google.com/#/learn-more/quic The phrase in that last one is: "multiplexing without head of line blocking". If you search for that phrase you will get a bunch of results. The browser is an extremely limited interface with regards…

I don't understand the conflation of multiplexing and multicasting. Are we talking about the same multicasting? (https://en.wikipedia.org/wiki/IP_multicast)

Regarding QUIC CPU load, at least as of a year or two ago it's demonstrably greater then TCP+TLS. Even Google's own numbers showed higher server-side load of up to 10%, IIRC. QUIC has to do all the same work (QUIC libraries embed the same congestion control and stream management logic as TCP, even using slightly modified versions of BBR, CUBIC, etc), and then some. More over, both TCP stream management and TLS are often offloaded to the NIC, and QUIC support isn't nearly as mature there. Even with vanilla NICs, high-performance application servers use kTLS. Unless your QUIC userland stack is DMA'ing raw packets directly to and from the NIC, QUIC is doing more work.

Re: The <usermedia> HTML element

#54

Post by Klonoar »

phantomathkg wrote: post #7

Chrome basically is abusing its market position, 69.65% globally, and becomes the new IE. Implementing its own HTML/JS standard. The sad truth is, some companies will look at Statcounter[0] and say because Firefox does not reach 5% global population and decided not supporting it, actively or passively. [0]: https://gs.statcounter.com/

IE was bad because Microsoft let it stagnate, not because they were creating new things.

Stop getting history twisted.

Re: The <usermedia> HTML element

#55

Post by bescob_ar »

usr1106 wrote: post #4

Is this Chrome only or something the other browsers are working on, too? A quick web search does not seem to produce any relevant hits.

I seldom see visibility for any releases in popular browsers. The only time I notice any is if I don't use it for years, then get handed a work laptop that uses X browser. It's at least cool to see these docs even if I likely won't ever see/appreciate the element in use.

Re: The <usermedia> HTML element

#56

Post by danaris »

Klonoar wrote: post #54
phantomathkg wrote: post #7

Chrome basically is abusing its market position, 69.65% globally, and becomes the new IE. Implementing its own HTML/JS standard. The sad truth is, some companies will look at Statcounter[0] and say because Firefox does not reach 5% global population and decided not supporting it, actively or passively. [0]: https://gs.statcounter.com/

IE was bad because Microsoft let it stagnate, not because they were creating new things. Stop getting history twisted.

It was both.

If you wanted to do dynamic stuff in IE, you had to use ActiveX. Which was IE-only. So many sites only used ActiveX, because IE was the 900lb gorilla, so why support anything else?

Re: The <usermedia> HTML element

#57

Post by hiccuphippo »

> Cisco observed that users who initially denied permissions were only about 10% likely to successfully grant permissions using legacy prompts, but that rate jumped to more than 65% with the new element.

Meaning they tricked more people into granting permissions they would have otherwise not granted.

Re: The <usermedia> HTML element

#58

Post by hollow-moe »

Or "we willfully borked the permission system in chrome so we could force everyone to implement our stupid solution". They could've just made better the "options" button at the top left of the URL bar which already allows you to quickly edit the website granted permissions but nuh uh. Be As Evil As Possible:tm:

Re: The <usermedia> HTML element

#59

Post by oaiey »

shimman wrote: post #51
oaiey wrote: post #29

Earlier quoted context omitted.

That is not how standards work. Some for sure, but the majority are established by groups of companies / a guild establishing rules. The law pressures them often into it (e.g. the EU did not say USB-C port, they said: one standard, you industry figure it out). There are surely exceptions (maybe the IEEE; which are professionals union).

No, this is how good standards bodies works. It require collaboration across nations, sorry but this is like small d democracy stuff here. What isn't good are corporate interests rat fucking engineering practices to pursue greater profits.

I agree all about company creed and also in many cases the standard is the lowest common denominator of their implementations. I am also a fan of putting national sovereignity over profit, but that does not change that in most cases only companies have the interest, the need and the insights to standardize stuff.
Post reply on HN