Browsers • Hacker News Board

Re: Browsers

#261

Post by magicalist » Tue, Dec 18, 2018, 8:43 AM UTC

seba_dos1 wrote: post #256

magicalist wrote: post #244

Earlier quoted context omitted.

> How many sites put invisible DOM elements over the videos? A lot of them? Vimeo, for instance, has a number of opacity: 0 and hidden divs over the video. Twitch has at least a couple of opacity: 0 divs on top. Maybe we're interpreting the phrase > hidden empty div over YouTube videos differently? That's the structure I assume they were talking about.

I'd assume that it was actually an invisible, but not technically hidden div, leading to a fully transparent blending pass - divs with opacity:0 or display:none are trivial to optimize for this case.

> I'd assume that it was actually an invisible, but not technically hidden div

Considering that it's now optimized and that's not what the original post said, I don't know why you'd assume that.

Re: Browsers

#262

Post by StudentStuff » Tue, Dec 18, 2018, 9:04 AM UTC

eridius wrote: post #258

StudentStuff wrote: post #222

Earlier quoted context omitted.

WebRTC was created to replace the need for apps that handle calling, without web push notifications (like every other WebRTC supporting browser has) there is no way for inbound calls to cause the phone to receive a notification unless Safari is open and has the webpage pulled up. WRT VP8/VP9, bandwidth is much more of a concern than you make it out to be. Network bandwidth on mobile devices is inconsistent, unstable,…

Google Meet is a video conferencing app, not a telephone replacement. AFAIK there's no way to "call" someone. So Web Push seems to be rather irrelevant. > Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low I'm not using Google Meet on a cellular network. I'm using it on a wifi network. And if it comes to it, I'd rather have slightly worse video quality with H.264 than slightly bet…

> Google Meet is a video conferencing app, not a telephone replacement.

Great, I really don't care about Google's WebRTC app of the month, it is unlikely to be with us in 10 years.

Your root question about why Google hasn't supported Safari with their Meet product likely boils down to the codec wars, as without VP8/VP9 support, Safari does not support the WebRTC standard. A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center.

Another take is the failing tests listed here, Google could easily depend on a component that Safari has not implemented (once again not WebRTC spec compliant): https://wpt.fyi/results/webrtc?label=stable&aligned

> In any case, if you want better than H.264, how about H.265

H.265 is a patent encumbered, licensed codec that is only supported by Safari & Edge (if you download the H.265 codec manually on Win10). At this point, Apple, Mozilla, Google, Microsoft and others are working on AV1 as a successor: https://headjack.io/blog/hevc-vp9-vp10-dalaa-thor-netvc-futu...

> I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that.

You can send literally anything in the SDP that you want, WebRTC is a forklift of traditional SIP onto the web, but with things like TLS enforced (otherwise idiots like the entire existing VoIP industry will run all signaling & calls over UDP with no crypto, then claim its "secure"). The only limitations you have are the codecs supported by your device, though you could totally write your own fairly complex codec in javascript :P

Re: Browsers

#263

Post by magicalist » Tue, Dec 18, 2018, 9:05 AM UTC

DrPizza wrote: post #245

magicalist wrote: post #229

Earlier quoted context omitted.

ha, just saw your story over on ars. FWIW, I think you're a little credulous there; as I mentioned in my other comment[1], I can't find anything stating that Chrome starting beating Edge at the test (their videos actually claim the opposite) or anybody from Chrome boasting about it (articles from the time like yours[2] also say the opposite). > On the other hand, pretty easy how such a div might trigger a less effici…

I don't think the performance claiming is really the important part here; it's doing something that lacks any real reason but which hurts Edge. And while I agree that video overlays are common, I also think it's reasonable for such overlays to revert to a slightly less efficient path.

> it's doing something that lacks any real reason but which hurts

Hey, there's a new div in the DOM, the only possible reason for a change like that is so Chrome can advertise about beating Edge on a benchmark nobody cares about? Even though they never beat Edge on it and this "advertising" never took place?

This was the credulity I was talking about. These events didn't happen (you literally wrote the stories plural! about edge winning the benchmark) and the motivations make no sense. I'm not sure why you'd repeat it without even a warning that it may just be a narrative made up from grumblings about fixing a fast path heard third hand.

Re: Browsers

#264

Post by StudentStuff » Tue, Dec 18, 2018, 9:11 AM UTC

gruez wrote: post #253

StudentStuff wrote: post #249

Earlier quoted context omitted.

Rejecting VP8/VP9 due to Google's involvement is silly and pointless, they're free to use codecs that are much more efficient than H.264. Apple has made its choice to push H.264 & H.265 due to their vested interest in the licensing revenue they stand to gain via the MPEG LA.

Apple has made its choice to push H.264 & H.265 due to their vested interest in the licensing revenue they stand to gain via the MPEG LA. If that’s true, why are they a member of the AOM, which promotes the royalty free av1?

How long can Apple push against all of the major content providers? Google, Netflix, Mozilla, AT&T & the plethora of other streaming providers will not fully support H.265, and Apple doesn't want to not have a seat at the table as they build a codec to supplant it.

I think this is a repeat of the USB C engineering participation by Apple, they may roll it out to their tiny MacOS install base, but it could be years before AV1 is supported on iOS. Safari on iOS is where Apple likes to draw its line in the sand, it also happens to be where they have nearly 1 billion users, versus 70 million on MacOS: https://ngcodec.com/news/2018/10/9/whats-in-a-codec-hevc-ver...

Re: Browsers

#265

Post by bonesss » Tue, Dec 18, 2018, 9:14 AM UTC

eganist wrote: post #184

XCabbage wrote: post #162

Earlier quoted context omitted.

The behaviour that your co-workers claim Google engaged in sounds pretty exactly like the AMD-Intel antitrust case where AMD alleged that Intel's C compiler was deliberately crippling performance on AMD processors to help Intel's processors compete. If true, Microsoft should sue Google over it - not just out of raw corporate self-interest, but because this sort of conduct is evil and should be stamped out. If this ca…

Fascinating. I wonder what the counter-argument would be; that a website isn't software, perhaps? That argument could be sufficiently argued apart by equating manually downloaded/installed software with code that's manually downloaded (GET / host: youtube.com) and run in a browser context. I'd be curious to see how likely Microsoft would be to follow this approach rather than to just stick to using Blink... as they'v…

The counter arguments are a) broken rendering in your browser does not dictate how my websites have to be, and b) since when is Google a monopoly on standardized HTML web video?

Google could start responding to YouTube requests with binary streams of gibberish if they want, MS would only have standing to sue as a content creator and advertiser on YouTube.

If Google is reverse engineering other browsers optimization paths and putting out content that is disagreeable to that optimization, that's possibly unfortunate but not illegal.

Re: Browsers

#266

Post by bonesss » Tue, Dec 18, 2018, 9:22 AM UTC

DrPizza wrote: post #245

magicalist wrote: post #229

Earlier quoted context omitted.

ha, just saw your story over on ars. FWIW, I think you're a little credulous there; as I mentioned in my other comment[1], I can't find anything stating that Chrome starting beating Edge at the test (their videos actually claim the opposite) or anybody from Chrome boasting about it (articles from the time like yours[2] also say the opposite). > On the other hand, pretty easy how such a div might trigger a less effici…

I don't think the performance claiming is really the important part here; it's doing something that lacks any real reason but which hurts Edge. And while I agree that video overlays are common, I also think it's reasonable for such overlays to revert to a slightly less efficient path.

> it's doing something that lacks any real reason but which hurts Edge.

In my own web development activities I can point to hundreds upon hundreds of hidden, invisible, and obscured DOM elements that have no obvious reason to for existing to someone outside the code-base where you find the commen explaining the required work around, browser hack, or legacy constraint. I've also experienced wildly divergent performance on MS browsers compared to others when creating content, often from something as trivial as DOM order or composition.

Clearly Google owes me some money for my part in their ongoing conspiracy to hurt Edge. I'm flexible, I'll accept GCE credit :)

Re: Browsers

#267

Post by bonesss » Tue, Dec 18, 2018, 9:27 AM UTC

WorldMaker wrote: post #225

Manishearth wrote: post #214

Earlier quoted context omitted.

Chrome and Chromium share the same engine, and for this stuff it is the engine that matters.

For now, at least. AOSP and Android "share the same engine", supposedly, but API footprint standardized in AOSP is getting drastically distanced from the API footprint moved behind Google Play Services and other proprietary bulkheads. The number of APKs that run on non-Google Play enabled AOSP builds has dwindled fast in the last few years. (Just ask Amazon.) What's to stop "YouTube needs Genuine Chrome™ with Google…

What's to stop that now?

They could throw up a check and have "Youtube requires Chrome XX.X with the Evil-DRM plugin enabled" live whenever they want. It's the relevant market forces and ecosystem.

Re: Browsers

#268

Post by protomikron » Tue, Dec 18, 2018, 10:36 AM UTC

krapp wrote: post #130

protomikron wrote: post #123

What I would like to see is some kind of "white-list" browser - I think it's our best chance to keep an ad-free environment. Maybe it is a bad idea in general to allow a remote page write pixels to your screen: images, videos, text and now applications It is nice that the web is open (at least reasonably), but maybe raw JS, HTML and CSS is too general? The most valuable webpages have simple designs and are liked beca…

>Maybe it is a bad idea in general to allow a remote page write pixels to your screen: images, videos, text and now applications Computers have been doing this since the 60s, at least, in some form or another. I don't think you want to live in a world where the very idea of networks is considered harmful. Where all of the software you consume has to be loaded from physical media and the internet and any network conne…

Maybe I have expressed myself unclear, but I don't want to advocate against networked software and loading resources over a network in general. I would like to have a more "typed" API to networking services (including web-pages) that provides sufficient information to render the application on my client - the term "whitelist" may indeed be a sub-optimal term.

> Having "specifications" that websites and authors would have to enforce based on content would make the web less free.

We already have enforced specifications (HTML, HTTP, TCP, ...) and they did make the web free, as you could and can participate, when you implement these specifications (at least to a sufficient degree). However we could go further and provide specifications for more high-level tasks.

Consider the problem of going from A to B via public transport. Cities with a working public transport infrastructure normally provide a webpage that allows you to search for routes and reporting journey time, cost and additional information. However these webpages are more or less convenient to use and every transportation provider has to implement its own shitty webpage. Hypothetically it could implement an API that provides this information and the "Browser" has its builtin GUI (configurable by the user) to access this information.

> Software authors have the right and the freedom to write whatever they like, any way they choose, up to and including the UI.

I am more talking about users who should have the possibility to access the information they seek in an uncluttered way. And we can keep stuff like , so you are still able to draw your pixels.

Re: Browsers

#269

Post by TheRealDunkirk » Tue, Dec 18, 2018, 11:35 AM UTC

JoshuaJB wrote: post #124

sonnyblarney wrote: post #78

Earlier quoted context omitted.

The concern is not 'now' it's 'later'. Google is a business like any other - and when they have the power to lever a monopolized situation - they will. For example, they may start integrating technologies for which they have exclusive, or at least 'special' access. Can you imagine if all of a sudden Google apps start performing better than anyone else's? Or what if they integrate technology that de-facto collects usa…

"For example, they may start integrating technologies for which they have exclusive, or at least 'special' access. Can you imagine if all of a sudden Google apps start performing better than anyone else's?" This is already happening. I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't…

I just started a new job at a MASSIVE international conglomerate. I was literally told that an intranet site I needed to use would only work in IE, and that it specifically would fail to render fields if I used Chrome. It's a little disingenuous to hear these kinds of complaints coming from the company which distorted the browser market so badly that the world is still paying for it 20 years later.

Re: Browsers

#270

Post by pitkali » Tue, Dec 18, 2018, 12:34 PM UTC

TheRealDunkirk wrote: post #269

JoshuaJB wrote: post #124

Earlier quoted context omitted.

"For example, they may start integrating technologies for which they have exclusive, or at least 'special' access. Can you imagine if all of a sudden Google apps start performing better than anyone else's?" This is already happening. I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't…

I just started a new job at a MASSIVE international conglomerate. I was literally told that an intranet site I needed to use would only work in IE, and that it specifically would fail to render fields if I used Chrome. It's a little disingenuous to hear these kinds of complaints coming from the company which distorted the browser market so badly that the world is still paying for it 20 years later.

So now it's okay because it's done to an actor that you consider deserving of such treatment? People said such behaviour is wrong, so they changed their act. Why wouldn't you hold others accountable to the same standard? What is the point of listening to the criticism and correcting your behaviour if it will be okay for others to keep punishing you?

Seems counterproductive to me.