Hacker News Reader

Comment by dwaite | Hacker News Reader

If I understand - Chrome is like IE for pushing proprietary extensions, and Safari is like IE for not implementing those proprietary extensions?

View on HN

I'm actually far more concerned with the other thing I mentioned, just like on old versions of windows, safari updates are coupled to iOS updates. So if your phone doesn't get any more updates, or you just don't want them, your browser engine is out of date, giving years old safari versions significant market shares. And this impacts stuff like being able to use "gap" for flexbox, which I don't think qualifies as a proprietary chrome feature

Safari is like IE for not implementing standards everyone else has agreed on and implemented.

Did “everyone” agree on and implement them, or did Google implement them and force everyone else in the WHATWG to play catch-up since they’re dominant?

Maybe there are specific examples of that? But I can't think of any, and it certainly doesn't strike me as common. Random example:

https://caniuse.com/input-inputmode

Firefox: 2013

Chrome: 2017

Safari: Any decade now, I'm sure of it

Your own link says it’s supported on Safari for iOS, for years now. It’s obviously not supported on MacOS because that attribute only applies to onscreen keyboards.

What makes you think onscreen keyboards are not useful in macOS if at least for accessibility reasons?

The browser feature under discussion is clearly intended for small screen mobile devices.

Accessibility keyboards are just keyboards from the web page’s perspective

It's clearly NOT intended only for small screen mobile devices.

There's no reason to restrict suggesting input types to mobile browsers only.

That's exactly why desktop Chrome and Firefox has support it for a long time now.

well apparently Apple disagrees

yeah, as usual. That's exactly the point

Such as?

Here's a breakdown: https://caniuse.com/?compare=chrome+131,safari+18.1&compareC...

Just because Google implements something does not make it a standard.

So, things that are either impossible (touch events or vibration) or ridiculous (why would I want a website to know my battery level or directly access system hardware?)

I'd guess for the same reason we want native apps to be able to do that.

Who said that we want native apps to be able to do that?

There are some use cases for those permissions but we (some) would like more control into that. I can't fight most of the websites as a user (they will tell me to use chrome) but it is for them hard to tell me if you want the service (along a billion other user) then move to android. Apple for a better or worse have much more sway than individual user.

Where "everyone else" means Google used Chrome to make it the standard.

Safari states their position on standards here: https://webkit.org/standards-positions/

IMO they have good reasons for opposing most of the standards

They don't even implement the standards that they have agreed to properly.

I searched that page and their github repo for "inputmode" (my example from before you posted) and couldn't find anything.

https://github.com/WebKit/standards-positions/issues?q=input...

I'd love to find out if anyone on the webkit project is aware of that part of the standard, and if so, the project's official position on it. I can't imagine why they'd oppose it.

Looks like it is already supported by Safari/WebKit for a number of versions: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

Some of those unimplemented “standards” are to protect user privacy. I know this is not universally the case, but it’s worth calling out.

You can fingerprint a browser to > 99.9% accuracy because of Google's lax approach to privacy and security when adding new features.

Of course this benefits the advertising side of the business immensely.

No, not only those, also actually legitimate web standards.

War is Peace

Reply on news.ycombinator.com