ss3000

Haha I never noticed until now but you're totally right, the resemblance is uncanny: https://mobileimages.lowes.com/product/converted/728363/7283...

Some pages are intended to be embedded in iframes (which have their own security context isolated from the embedding page), and happen to use cookies for authentication. Safari not allowing cookies from third party domains in iframes is the issue here.

Assuming these iframes will never work means degrading the experience for all users, when only users on Safari are actually affected. Detecting the UA and branching based on that is a much more pragmatic solution.

For the frequent travelers out there, I backed this thing on Kickstarter and had really high expectations for it: https://www.kickstarter.com/projects/netta/the-six-a-carry-o...

Just received it last month, and build quality seems excellent. And judging from the positive Kickstarter comments so far, I can't wait for my next trip. :)

It's quite a bit more expensive than the Away case, but the large back-wheel and push mechanism felt super innovative and provide a very tangible improvement to quality of life for steering the case around in streets compared to existing designs, whereas the Away case at the end of the day is just a regular old suitcase with slightly nicer materials (I own one but plan on selling it off soon if this one holds up in practical use).

We should of course default to feature detection whenever possible, but non-standard behavior like this in certain browsers is exactly why feature detection alone is never going to cover 100% of current use cases for UA detection.

To add to OP's point, this thing in Safari also comes to mind as an example of something that isn't easy to detect and address outside of UA detection: https://github.com/vitr/safari-cookie-in-iframe

Deprecating UA Strings and moving towards UA Client Hints seems like a move in the right direction though.

The fact that in 2020 we still don't really have CPUs that are significantly faster than those released in the middle of the decade in terms of single threaded perf (which is still the paradigm that most programming languages today operate under for the most part) kind of put a nail in the coffin of that prediction.

I can totally picture new languages as described doing well today if we had exponentially more single threaded processing power/watt at our disposal than we actually do.

I think there is still opportunity for languages that offer huge leaps in expressiveness w.r.t handling concurrency even at the cost of raw single threaded performance. Though I would not label a language like that as "slower" as it'd allow us to actually make much better use of our computing resources than we reasonably could today without blowing through most of our complexity budget, resulting in faster programs in practice.

Here to second the learning opportunities.

One very salient explanation of this that has stuck with me goes something like this:

A fast growing early stage startup is great for learning because you'll often end up with tasks that you're not qualified to do, which forces you to go out of your comfort zone and learn from the inevitable mistakes you'll make along the way, whereas in a large company they usually have plenty of more senior people to take care of the more challenging tasks outside of your current pay grade.

> That'll open up an instance of _VSCode_ in a web browser and you can start coding

GitPod actually runs https://theia-ide.org/, not VSCode, but Theia is compatible with VSCode extensions, and they've themed it to look practically identical, so it's definitely not super obvious.

ZeroTier is also open-source. If TailScale isn't then I personally wouldn't even consider it a competitor.

I have also pondered on variations of this idea of users _owning_ their own data and only granting access to their data to apps they trust, as a means to counter the status quo of every company holding users' data hostage in their own walled gardens and preventing data mobility between apps.

However, the one thing that I've always struggled with is how to handle apps that need write access to users' data in order to be useful. For instance, a messaging app needs to be able to write new messages onto the user-owned data store, but if we allow arbitrary reads/writes to some namespaced path to the store, an app simply needs to encrypt the data with some secret key that the user doesn't know in order to build a decentralized walled garden that stifles data mobility in the same way that centralized walled gardens do today.

Could you please be a bit more specific?

I looked through all of the links in the original post and couldn't really find any mentions of specific limitations.

Just trying to learn more about this space.

Curious if you've explored something based on ProseMirror?

I've heard good things about it and it seems to have a decent implementation for hybrid WYSIWYG + Markdown.

https://prosemirror.net/examples/markdown/

Then you'll _really_ love the Galaxy S9 with the curved edges, where the natural resting spot for your fingers is on the curved edges of the actual screen.

/s

> But, I think they're going to have trouble getting $1500 for someone's main phone if it only has one camera lens.

Has it really come to this?

I'd gladly buy a phone with a single mediocre camera as a daily driver if all the other specs are flagship-class (which sadly the Razr's are not) and if it means saving a few hundred bucks off the hardware and R&D of the latest and greatest camera tech.

Am I in the minority now?

First time hearing about Shadow. Their site doesn't mention anything about usage limits, so it sounds a bit too good to be true. Do they have any usage limits in practice?

Is VR not just a special case of AR?

First time hearing about Capacitor. Curious if anyone could share some more concrete differences between Capacitor and Cordova?

Point taken. Maybe in this case the spec authors were also at fault for leaving too much leeway in the implementation.

Nevertheless, from their stance on the issue so far it stands to reason that the Chromium team would have objected to any efforts to tighten the spec, which would also have led us to this same situation.

W.r.t. this particular decision, I feel a more reasonable approach here might have been to allow users to manually trigger autocomplete on individual fields with `autocomplete="off"`, and/or to allow users to strip away the ability to disable autocomplete on a site by site basis.

Analogously to how users are able to selectively grant access to certain default-off features for each website (notifications, camera access), users should also be able to revoke access to certain default-on features for sites that abuse them without affecting the vast majority of sites that use the features for their intended purposes to create a better user experience.

Setting aside the merits/lack-thereof of this particular decision, Chromium ignoring established web standards like this is especially dangerous as we're trending towards a world where 1) Chromium itself powers the most popular browser in the world by an increasingly unhealthy margin, and 2) even competing browsers are increasingly becoming skins on top of Chromium.

We are becoming more and more reliant on the developers of Chromium to be steadfast stewards of the standardization process. Their massive influence means that any deviation from actual web standards on their part will inevitably create a new and conflicting de-facto standard that will create decades of lasting damage and irreversible tech debt for the entire web (eventually leading to a repeat of the IE6 dark ages).

Decisions like this demonstrate an utter disregard for the crucial role Chromium plays in the web standardization process, and jeopardizes the entire ecosystem.