4 ms·

> I get that you’re disappointed Safari doesn’t support the same stuff, the same way as Chrome. In some cases, yes, but in others, no. For example, Safari sti

> I get that you’re disappointed Safari doesn’t support the same stuff, the same way as Chrome. In some cases, yes, but in others, no. For example, Safari still clings to their proprietary image formats. That means I need two versions of each image: something legacy or proprietary for Safari users (PNG, JPEG, HEIF) and something to appease the Google Gods (WebP) so I don't get blasted by Core Web Vitals. It's the IE PNG and SVG issues all over again. (Yes, I'm aware that Safari keeps claiming they've added WebP support--it's broken and has been broken since its inception.) It's this proprietary, "we're going to do things our way and ignore the conventions" that annoys me. Chrome does it, too, but at least Chrome users have the ability to choose another browser; no such luck on iOS. WebP has been around for a long time now as an unencumbered format; there's no reason to continue avoiding it other than those sweet, sweet royalties that Apple wants to collect on HEIF. > If you want to use the new shiny, do so, but accept what you’re doing carries the risks it has and work that into your strategy. No, I don't want to use the new shiny; I want to eliminate the old bloat--all the compatibility code required to achieve the same experience across a variety of browsers while simultaneously appeasing search engines. I don't want to be forced to use Apple's proprietary image and video formats to achieve decent performance in Safari--formats that other browsers often can't reasonably support. I don't want to be forced to do things the "Apple way" and rely on JS when I could be using CSS that works in all other browsers. This is the same path that IE took. Right now they're at the IE7 stage: you can get roughly the same effect that you can with other browsers, but you have to go about it differently. At the same time, they're starting to lag behind. IE7 really exemplified this lag: it took them far too long to add tabs. Proper PNG support was in a similar boat but took even longer. > Some of your users could be on Lynx My sites would work better in Lynx if I didn't have to spend so much time making them work in Safari--but they do work in Lynx; they're just less-than-pretty because, guess what, Safari lacks support for the CSS that I need to accommodate semantic HTML. > on that browser which comes with Haiku It can't be that important if nobody even knows what it's called. > on a shitty phone from 8 years ago. Phones from 8 years ago run sites a lot better when they don't have to download redundant code and JS polyfills to achieve what could've been done with pure CSS. Although, if they don't support TLSv1.2, they're not going to be able to connect to some of my sites anyway; tough cookies. (They'll still be able to access my static websites, where enforcing modern encryption is less of a concern.)

tekknik 5y ago
> That means I need two versions of each image: something legacy or proprietary for Safari users (PNG, JPEG, HEIF) and something to appease the Google Gods (WebP) so I don't get blasted by Core Web Vitals. WebP uses VP8, which requires hardware support to run correctly. Apple's "proprietary" format is also open, and created by a standards body instead of Google. VP8 also has some patent claims on it by Nokia, even though Google has released it under a free patent license. I'd definitely second guess that if I were a legal dept. So really you're arguing that you prefer Google's proprietary format over Apple's. To each their own but know your desired format isn't as free and open as some would hope. > Chrome does it, too, but at least Chrome users have the ability to choose another browser; no such luck on iOS. What if iOS users view this as a feature? I know I certainly do. It's impossible these days to know with certainty which apps are running in a browser. And given Chrome supporting all the things it supports it can be a security issue. So knowing an app must be using webkit to me is a feature. > I don't want to be forced to use Apple's proprietary image and video formats to achieve decent performance in Safari Again, Apple's formats are open. And further this should be completely transparent to you as you should have conversion scripts in place already. > My sites would work better in Lynx if I didn't have to spend so much time making them work in Safari My experience is a bit different. I develop for Safari, then check it in Chrome and FF. It works most of the time with few exceptions that Chrome implements to perform it's magic. > It can't be that important if nobody even knows what it's called. That's actually the point. It supports the standards and you get a few extra market participants you wouldn't have if your customers happen to run that browser. You don't need to know the name at all, so long as it supports the standard. This benefits us by having more and more browser engines and competition, instead of the 3 we have today. > Phones from 8 years ago run sites a lot better when they don't have to download redundant code and JS polyfills to achieve what could've been done with pure CSS. The question is, is any of this needed? If it's CSS it clearly doesn't anything to do with the functionality of the site right?
- zenexer 5y ago
  > Apple’s “proprietary” format is also open No, it isn’t. It’s useless without HEVC, which is encumbered and requires royalties,[0] most of which go to Apple. VP8 is free (as in “free beer,” not as in “freedom”). > What if iOS users view this as a feature? They can view it however they like. I’m typing this on iOS and find it disappointing. > Again, Apple’s formats are open. HEVC is not open.[0] > My experience is a bit different. Chrome has its own issues, though, as does Firefox. Safari just seems to have more than the other two. For example, for the longest time, Safari was the only browser to support color() and DCI-P3. > That’s actually the point. While Safari might not have the nasty Google habit of coming up with their own standards, they do have the nasty IE habit of failing to keep up with widely accepted standards. For example, to this day, HTTP/2 server push remains broken and will crash Safari if you attempt to push a zero-byte resource. > The question is, is any of this needed? If you want to cater to an audience that prefers a clean, efficient UI while simultaneously avoiding creating a horrible mess of dark patterns, yes. If you want to run on as many browsers as possible without looking like a Word document, yes. If you want to appease Google so you don’t get deranked, yes. [0]: https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Patent_licensing https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#P...

tekknik 5y ago

> That means I need two versions of each image: something legacy or proprietary for Safari users (PNG, JPEG, HEIF) and something to appease the Google Gods (WebP) so I don't get blasted by Core Web Vitals. WebP uses VP8, which requires hardware support to run correctly. Apple's "proprietary" format is also open, and created by a standards body instead of Google. VP8 also has some patent claims on it by Nokia, even though Google has released it under a free patent license. I'd definitely second guess that if I were a legal dept. So really you're arguing that you prefer Google's proprietary format over Apple's. To each their own but know your desired format isn't as free and open as some would hope. > Chrome does it, too, but at least Chrome users have the ability to choose another browser; no such luck on iOS. What if iOS users view this as a feature? I know I certainly do. It's impossible these days to know with certainty which apps are running in a browser. And given Chrome supporting all the things it supports it can be a security issue. So knowing an app must be using webkit to me is a feature. > I don't want to be forced to use Apple's proprietary image and video formats to achieve decent performance in Safari Again, Apple's formats are open. And further this should be completely transparent to you as you should have conversion scripts in place already. > My sites would work better in Lynx if I didn't have to spend so much time making them work in Safari My experience is a bit different. I develop for Safari, then check it in Chrome and FF. It works most of the time with few exceptions that Chrome implements to perform it's magic. > It can't be that important if nobody even knows what it's called. That's actually the point. It supports the standards and you get a few extra market participants you wouldn't have if your customers happen to run that browser. You don't need to know the name at all, so long as it supports the standard. This benefits us by having more and more browser engines and competition, instead of the 3 we have today. > Phones from 8 years ago run sites a lot better when they don't have to download redundant code and JS polyfills to achieve what could've been done with pure CSS. The question is, is any of this needed? If it's CSS it clearly doesn't anything to do with the functionality of the site right?

zenexer 5y ago
> Apple’s “proprietary” format is also open No, it isn’t. It’s useless without HEVC, which is encumbered and requires royalties,[0] most of which go to Apple. VP8 is free (as in “free beer,” not as in “freedom”). > What if iOS users view this as a feature? They can view it however they like. I’m typing this on iOS and find it disappointing. > Again, Apple’s formats are open. HEVC is not open.[0] > My experience is a bit different. Chrome has its own issues, though, as does Firefox. Safari just seems to have more than the other two. For example, for the longest time, Safari was the only browser to support color() and DCI-P3. > That’s actually the point. While Safari might not have the nasty Google habit of coming up with their own standards, they do have the nasty IE habit of failing to keep up with widely accepted standards. For example, to this day, HTTP/2 server push remains broken and will crash Safari if you attempt to push a zero-byte resource. > The question is, is any of this needed? If you want to cater to an audience that prefers a clean, efficient UI while simultaneously avoiding creating a horrible mess of dark patterns, yes. If you want to run on as many browsers as possible without looking like a Word document, yes. If you want to appease Google so you don’t get deranked, yes. [0]: https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Patent_licensing https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#P...