It's totally reasonable. It's not hard to maintain a safe following distance. Sudden braking isn't the only reason to do so, and insurance claims aren't the only motivating factor. You drive defensively so as to reduce the likelihood of death and destruction while making life easier for other drivers.

So if a car swerves into your lane 10 meters in front of you, then slams on the brakes, you're at fault because it should have been so easy to maintain a safe following distance? (This isn't hypothetical, I've had this exact scenario happen multiple times -- on/off ramps seem to bring out the worst in some drivers).

Whether or not it's reasonable is immaterial. If you constantly consider the possibility of the cars around you to do something unexpected, then you're more likely to avoid death and destruction. As well as prevent the death and destruction of the people around you. It's called defensive driving.

Maybe it's unfair, or too much to ask, or just too difficult. But it's reality.

I'm rooting for self driving cars because I believe that, theoretically, they'll do a much better job than people. In the long run.

However, today, you have to pay attention or you might die. And even if you pay attention you still might die.

My dad told me a story about a coworker he had who was in a car accident. He was sitting at a long line in the highway at a tollbooth. It was foggy. My dad's coworker was watching the fog behind him like a hawk because he didn't feel safe just sitting completely stopped in the highway. A semi-truck appeared out of the fog moving at high speed. My dad's coworker cranked his steering wheel and tried to accelerate off to the side of the road but got rear ended by the truck. He was lucky. Because he was already headed away, this car got bumped out into a field. His car was destroyed and he got a bunch of injuries, but he lived. The people in front of him in the line were not lucky. A bunch of them died.

It's not fair or reasonable. But being constantly considering possibilities saved this guy's life. The other people are dead.

If companies like Amazon and Google are going to outright lie on their status pages, why bother having them at all?

>So it‘s „better“ to update your status page afterwards when your legal team is all on board

Is the initial double quote at the bottom something that is language specific?

And it‘s probably specifiy to German.

Also, the upper one is “, not ".

*"The site is up, I just can't get to it. Fix my network!"

Presumably there is some internal threshold for when to flick the switch on the service dashboard, but without knowing anything about the scale of the outage or what the threshold is we're kinda shooting in the dark.

Perhaps it would help if the dashboards gave a tiny inkling of transparency, like what the thresholds are so you could gauge the relative significance of your personal service outage. If my page is out and vendor shows green, then maybe those relying on my service ontop of vendor won't believe me as much when I pass blame to them and/or maybe the vendor isn't even aware of the issue, so I should contact them because I'm an edge case.

If my service is out and the status page shows red with a nifty "were working on it" I can very clearly show anyone I report to or who is dependent on my service the parent service outage causing the issue, maybe even link them to it. In addition, I know that I don't need to contact the vendors support because they're aware of the issue and actively working on resolving it. I'm sure their support staff will appreciate it that millions of people can avoid contacting their support service reporting the same outage and having to repeat the same information through more costly reporting mechanisms than a page everyone can simply observe.

Every power company I've been with for at least the past 10 years basically do this. If I'm out at work and come home to no power, I first load my power company's outage report site (service status dashboard). I check my area and magically I know if the power company is aware and likely working on it, I can even see their updated time estimates when service will be restored. Sometimes they even tell me what caused the issue (oh boy, information). I never even have to make a call.

Meanwhile if I'm sitting here sipping coffee and hear a loud noise down the street, power is out in the middle of the day and I look across the street and see the neighbor's interior lights on, check the power company's outage map and don't see it: I give them a call. Tada, I know my isolated outage will be addressed and the service provider is aware of the issue. I also know if it looks limited, I'm probably going to be a lower priority if there are multiple outages and limited maintenance staff, so I can sort of expect it may be several hours. I can head out and not waste my time and effort sitting around.

Let's treat critical internet service infrastructure (that's what 'cloud' wanted to be, so let them have all that entails) like we treat other critical service infrastructure. It works quite well.

The underlying issue I see is that my utilities are well regulated and watched over so there often is a lot of transparency about what's going on. Heck, they even have public hearings if they want to increase their prices. Meanwhile, private company offering some service isn't very regulated and has every incentive not to let you know to manage the perception of their image and reliability vs providing empirical actual data. So will we see any sort of transparency? I doubt it, just as I highly doubt the size of represntative truthfulness of any data they report.

EDIT: Seems to be preventable with a quick Tampermonkey hack: https://gist.github.com/lukepothier/1b18905039b1ed960efebec3...

Of course, servers should still be capable of serving the fonts that the client requires to render the content correctly, but the browser should be equipped to make that happen as quickly as possible.

This would be especially helpful now that shared caches are going away.

One other option is to actually install the font into your OS. Any correctly-coded website will try a local source first, which should help a lot for poor connections.

Then Google Fonts is not correctly coded, as it'll use remote font only. And myriads of websites reusing Google Fonts snippets. To try local source first, you have to explicitly ask for it in @font-face/src which Google Fonts does not do.

So installing font into your OS won't help you with any website using Google Fonts service.

For a good technical reason: the version installed on the computer may not really match whatever the version on Google Fonts serves (fonts have notoriously no semantic versioning aside from some programmer-oriented fonts, examples of these outside are Segoe UI (changed between Windows 7 and 8) and Liberation fonts (some versions notoriously lack some glyph symbols) and on Google Fonts platform the Exo and Exo 2 problem (which was resolved by renaming the second version to Exo 2)).

Of course, there are also some benefits to Google (you know what are those benefits are).

https://developers.google.com/fonts/faq#can_i_download_the_f...

> Note that when browsers render websites that use the Google Fonts API, they will check if a font is installed locally on your computer, and prefer to use the local version over web fonts.

https://fonts.googleapis.com/css2?family=Inconsolata&display...

    @font-face {
      font-family: 'Inconsolata';
      ...
      src: url(https://fonts.gstatic.com/s/inconsolata/....woff2) format('woff2');
  unicode-range: U+0000-00FF, ...;

Some random references to it w/ the snippets:

https://stackoverflow.com/a/52413970

https://stackoverflow.com/questions/18303215/how-can-i-preve...

https://github.com/google/fonts/issues/2620

I've created issue "Local font name makes web accessible", and I hope it would be fixed.

https://github.com/google/fonts/issues/2855

When you select fonts on Google Fonts, the website instructs you to link to CSS hosted by Google, which is simple to implement, but not performant. Really, you would want to load that CSS asynchronously, so that the rendering of the whole website doesn't wait for Google Fonts. (Here's how you load CSS asynchronously, by the way: https://stackoverflow.com/q/32759272/247696 ) Or even better, host the fonts yourself.

- 1. Copyright (though many fonts are free, true)

- 2. Everyone uses a different font (just like everyone uses a slightly different version jquery) so cache hit would be pretty small IMO. Do you really want a browser to be gigabytes large? Especially on mobile it's not viable

Maybe if browsers standardized on shipping, say, 20 carefully chosen fonts (not necessarily the most popular ones, just a good variety of different types of fonts), the smaller websites would follow and use them; but I think any major brand likes to distinguish themselves and have a custom unique font.

Absolutely, i would rather give the browser 50 GB even on my phone over paying my mobile operator for downloading the same data over and over again.

And it wouldn't take anywhere near that much, I am sure 80% of most used fonts are only a couple dozen, that wouldn't tale gigabytes

For example, Google Maps by default doesn't load maps of the entire world when you install it. However, it does let you opt-in to pre-downloading specific areas that you frequently travel.

Browsers could do the same by simply adding an opt-in to download / cache common assets like fonts, jquery, etc.

Not embedding all of them would allow tracking. Caching all web fonts would allow tracking.

The solution is embedding all the popular ones so everyone has them and it can't be used as a signal.

https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-...

so it should be possible to log. And given a list it is not hard to download.

It may be not really carefully chosen, but didn't Microsoft have done this already? (Core fonts for the Web, https://web.archive.org/web/20020124085641/http://www.micros...). The reason they have discontinued this programme is that it actually costs them some money (as the fonts are not owned by Microsoft.)

Also, how would you cater to non-LGC (Latin, Greek, Cyrillic) users?

Web standards and browser features are generally built for the long term and backward compatibility. I mean, it's not impossible to find a solution, but it's definitely not "let's download some fonts and bundle with the browser, done" kind of problem.

Self-hosting is the way to go since it gives you full artistic control and you can use things like the Unicode-range CSS property to tell clients how to combine smaller fonts so you can support many languages without forcing a French browser to download a ton of Chinese glyphs which aren’t used on the page.

Another nice option we have now is using font-display to allow using a similar system font until downloads are completed, which can work really well for slow connections:

https://calendar.perfplanet.com/2020/a-font-display-setting-...

Correct me if I'm misunderstanding, but don't the vast majority of fonts _not_ include full Unicode support, or even close to it? I know of GNU Unifont, but not many people are using that on the web...

I take your point on selectively downloading the relevant glyphs for the user's locale, but this could be done by the browser too - it is aware of the locale.

There are some things that are really well executed, and other things where the ball gets dropped completely.

Chrome will come along and do something like hide parts of the url, or allow scroll-jacking, but then say that fonts should probably be a system level implementation.

It would be trivial for the chrome team to establish something like a series of web-safe fonts like Roboto, Inter, Merriweather, etc. Stuff that gets used incredibly often. Even things like licensing aren't really an issue when most of these fonts are under their open license not to mention that Google has the money to be able to license it if they wanted to.

I could learn how to do it in 30 minutes, but I don't feel like spending 30 minutes learning that.

I'd guess that 99% of users don't know how to install fonts or simply don't care about it enough to their spend time installing fonts.

It's just something people say they do online to feel good.

I can recommend Mullvad[1] which takes none of your information for registration, and which ticks all the right boxes on That One Privacy Site's VPN comparison chart[2].

[1] https://www.mullvad.net

[2] https://thatoneprivacysite.net/vpn-comparison-chart

  var integer = 1;
  var long = 1l;
  var float = 1f;
  var double = 1d;
  var decimal = 1m;
  var unsignedInteger = 1u;
  var unsignedLong = 1ul;

I've restored to using slack on Safari now. This problem still occurs, but reloading the slack tab is easier then finding and killing the slack process.

  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, target-densityDpi=medium-dpi">

Just as a quick point and I will drop it in the article comments too. I'm the lead for our Chrome Developer Relations team.

Chrome doesn't disable picture in picture for Youtube, Youtube disable it in Chrome. They listen to resize events iirc and then exit fullscreen mode (the only way to currently get to pip mode in Chrome).

That applies to blocking Google ads, as well as fixing Youtube malfeatures.

Of course, it's understandable you won't see this from a browser paid for by Google. But you can't paint in broad brush strokes like "I don't think hiding side-effects or user actions helps anyone."

I'm not saying that there can't be meaningful response from the browser to user hostile actions, I don't think anyone disagrees.

There's a broader question about a user's will and the sites intent especially when it comes to business plans of the site that I'm not sure if access to features native in the browser is aligned with say ad blocking or tracking etc... I don't know.

The site's business plans are not my problem. Basically, my phone and my computer should do what I want. Why is there even an API to make a video player enter/exit full-screen mode ? That's 100% a user decision and there is no valid reason why that should ever be exposed to JS.

There absolutely are valid reasons and responsible uses for the browser to expose that API. Instead the argument should be around the irresponsible uses justifying hiding that part of the API.

Valid reasons to expose full-screen to the API:

* An "Always full-screen videos when I play them" button. * Remote control of demo displays, kiosks, etc. Force them to all fullscreen and play a video synced up. * Disable unnecessary features when website is full screen (e.g. stop polling website for changes) * Exit full-screen on certain conditions. For example on a shared streaming site like Rabb.it, maybe if someone joins your chat room (assume this is configurable by the user)

In short, you can use JS to respectfully enact user decisions.

I'll also mention a related case. On Safari iOS, you can't autoplay a <video> element unless the user has interacted with it via tapping it. The goal, obviously, is to stop autoplaying videos. The goal, of stopping annoying autoplaying videos, is noble, but at the cost of removing the possibility of responsible usage. Maybe it's worth it, maybe it's not, but there is an undeniable tradeoff.

A possible solution is having a "responsible app mode" in browsers. Whitelisted webpages have full access to these privileged APIs which would otherwise be stubbed out and non-functional (hopefully in a way that a webpage can't detect).

Also, especially for video, the browser should be able to play it full screen without any distractions.

Of course, there are optional enhancements (subtitles, or different audio tracks) driven via JS. And for those the controls have to go somewhere.

Ideally, if there were a standard for those, the browser could handle it. (But then we're at the problem of an ever bloating browser.)

I think you're overreacting to one bad-actor. Inevitably your suggestion here leads to good-actor pages having much less power to present good UI to its users. The browser has to think of all use-cases and have options for that, rather than defining lower-level hooks that pages can do what they want with.

Would it make you feel better that there already many other ways that pages can do user-hostile things? Have you ever visited a page that blocks right-click? Would you want to forbid Mouse Events because of this?

> You're asking that the browser define its own UI for an exit button.

Yes. Currently firefox puts a "to exit full screen press esc" OSD already on videos, that also interferes with visual presentation of sites/directors. So ... directors already don't put shit there.

The same thing goes for walled gardens (like Apple's - they don't allow some things), the problem is not that it's curated, the problem is that there are insufficient tools available for users to put their walls where they want.

Yes, by default I don't want to allow blocking right click. (You might be familiar with the saga of this bug https://bugzilla.mozilla.org/show_bug.cgi?id=78414 . )

No, the left mouse button is for interaction with the webpage, the right mouse button is mine. Just don't send any events for the right mouse button.

The historical answer does the same, as browsers were explicitly designated User Agents, as their whole purpose is to act in the name of the user, and fulfill whatever the user wishes to, which also clearly places the will of the user over everything a website may wish to.

How you interpret this is obviously left to you...

> The historical answer does the same, as browsers were explicitly designated User Agents, as their whole purpose is to act in the name of the user, and fulfill whatever the user wishes to, which also clearly places the will of the user over everything a website may wish to.

The browser is a User Agent, I agree. This doesn't mean they can predict all user hostile behavior and fix it before it ever happens. Browsers often fix bad behaving websites over time. Recently there's been a lot of effort to fix pages that cause scrolling jank when they load ads in the background.

There’s been countless cases brought against ad blockers, and all that were about ad blocking, were decided favourable for the blockers.

Additionally, there’s a precedent that users want to be able to control what a site does, and are willing to take extra steps to achieve this, so a browser should implement such functionality ideally in the first place.

I don't care about helping developers who want to hinder my usage of my browser on my hardware. It's my CPU they are executing on, and thus it should be I & I alone who determines what is executed.

Just like my browser blocks popups, and my browser blocks those sites that try to prevent right-click, and my browser blocks those sites that spawn dialogs when you try to leave them, Just in the same way I want my browser to force websites to allow PiP.

The current version 55 is a little slower than Chrome on my 3 year old phone, but performance in the past few major versions has definitely improved. The nighty developer build of Firefox 57 absolutely flies.

Mozilla is doing an amazing job with their Firefox modernization, it's a shame how little attention it gets on Android.

Video Background Play Fix https://addons.mozilla.org/en-US/firefox/addon/video-backgro...

I think a better question is why would a talk/podcaster be using YouTube for distribution?

Browser block popups, forcefully enable right-click on sites that disable it, browsers allow users to forcefully enable zoom, or background playback.

And just like that, browsers should also allow users to forcefully enable PiP.

Too bad Mozilla won't ever dare to defend themselves from Google's bullying and will happily accept having background playback on YouTube, until now one of the primary motives for people to try Fennec out, being taken away.

https://bugzilla.mozilla.org/show_bug.cgi?id=1355407

RESOLVED WONTFIX

E: This is a simple and earnest question. Why the downvotes?

The viewport meta tag is part of what makes RWD possible. [2] The viewport meta tag does not relate to PiP in any way that I can imagine.

[1]: https://developer.mozilla.org/en-US/docs/Glossary/Responsive...

[2]: https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/View...