Earlier quoted context omitted.
Hopefully not. I'd hate to click through "This site wants to push new ads to you. Allow notifications?" modals on my shiny new iPhone (edit: in addition to content being constrained to poststamp-sized areas between GDPR banners).
You should understand the argument before you form an opinion on it. First of all, there are plenty of us who have legitimate use cases for web push. Second, if you care about being bothered by shitty sites prompting you unprovoked, you have a couple options: content blockers or use different sites. The need for notifications is real and Apple’s choice to exclude their availability in iOS is a business move not a tec…
WebKit Goals for 2020
91–100 of 154 posts
Re: WebKit Goals for 2020
#92Pardon the all-too-typical off topic: woa, Trac! I haven't seen that in a long time. I have fond recollections of its customizability. Is it still being used in anger and improving, or is this just a legacy system we're looking at?
Re: WebKit Goals for 2020
#93Earlier quoted context omitted.
You should understand the argument before you form an opinion on it. First of all, there are plenty of us who have legitimate use cases for web push. Second, if you care about being bothered by shitty sites prompting you unprovoked, you have a couple options: content blockers or use different sites. The need for notifications is real and Apple’s choice to exclude their availability in iOS is a business move not a tec…
> There are plenty of us who have legitimate use cases for web push Such as? The only use case for notifications and PWAs I'm coming across are clickbait news sites creating a sense of urgency with "homepage was updated" modals obscuring content and capturing click events. Web user agents have freedoms in rendering pages to users, and Safari siding with users and power efficiency is a good thing. In line with other c…
I write apps for myself, my family, and my friends. I put them on MY server and make them available to OUR devices. We should be able to notify ourselves whenever we want. Our devices should ask whether we want notifications or not to make sure, and we should be able to say yes. If a browser maker simply wants to avoid burdening the user, there should be a way to choose a default with blacklist or whitelist exceptions.
Instead, Apple (for example) says, "If you want to burden users by asking them if they want notifications, that would be very bad unless you first pay us for a dev account and keep paying and commit to using our own proprietary tech instead of using open web tech, because users aren't bothered by requests to allow notifications as long as they know it helps Apple. If you do, we will grant you the privilege of trying to persuade us that your app benefits us and not just yourself and your friends. Our App Store terms require you to show how your app isn't just a website (which we won't allow to send notifications) but serves Apple's needs in some way before we'll let you send notifications to yourself.
If it were really about serving the needs of users, iOS could allow users a choice between the default "browser that says NO" and "sides with users and power efficiency" and alternative browsers that, like App Store apps, show their contempt for users by letting them decide for themselves what they want.
Re: WebKit Goals for 2020
#94Earlier quoted context omitted.
Personally the problem is not that I don't like it, but that I have no way to test against it. No, I'm not buying their overpriced crap just to see what they've broken for their users. Even MS has had modern.ie[0] for years. Until then, Safari users are on their own[1]. [0]: https://developer.microsoft.com/en-us/microsoft-edge/tools/v... [1]: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
Yeah, I agree with that. But it's one thing to say "sorry, I had no way to test against your browser" , but quite another to say "I am going to intentionally break this browser because it's too 'old' by my standards" . You can apply for a free BrowserStack accounts for open source projects btw[1]; it's still a bit of a pain, but better than nothing. [1]: https://www.browserstack.com/open-source
Re: WebKit Goals for 2020
#95Earlier quoted context omitted.
They do use native apps, because they offer these features and other conveniences only afforded to native apps within Apple’s control.
Problems with Apple’s app review guidelines should be addressed by pushing for Apple to improve the guideline itself. Pushing for Apple to make their browser more adtech-friendly to the detriment of its users is not a solution.
Re: WebKit Goals for 2020
#96as is tradition already, webkit is missing: - full PWA - ServiceWorkers - VP8/9 - webvr - and many others this could all be mitigated if aapl would let us install custom non-webkit browsers on ios. unfortunately it seems we will need the courts to force aapl.
Re: WebKit Goals for 2020
#97We use WebKitGtk[1] (embedded WebKit) in our presentation software Tech Talk PSE[2]. It would be great if SVG rendering, used for diagrams, was of equal quality to Firefox, but unfortunately Firefox seems to render SVG in a far superior way so we usually have to convert to PNG files to make diagrams embed correctly. [1] https://webkitgtk.org/ [2] https://rwmj.wordpress.com/2012/01/31/tech-talk-pse-1-1-0/
Re: WebKit Goals for 2020
#98Apple keeps silently "considering" and "accidentally" messing up various aspects of web app support, while strictly prohibiting browsers that work well. By prohibiting high-quality browsers, Apple pushes developers toward Apple-proprietary "native" technologies--those that are both allowed to be the only things that work well on Apple devices and are NOT allowed to work anywhere else.
Two WebKit goals I'd like to see for 2020: (1) Allow non-WebKit browsers on iOS (start outperforming your competition instead of merely banning your competition), and (2) Make iOS the best platform for powerful web apps instead of the worst, the leader instead of the spoiler.
Re: WebKit Goals for 2020
#99I'm glad that battery life is a top priority. Though WebP would still be nice to have..
I'm curious why they're not exposing it to the Web. Is it because the codec is a ball of risky C++ code? Patent issues? Or because it's non-standard, and for once, they don't want to add a non-standard feature?
There's also JPEG XL being standardized now, which gives similar compression while also supporting lossless conversion from the classic JPEG. This offers nicer migration path. With other formats conversion from JPEG is lossy, so you get smaller files partly because you lose quality in the process.
Re: WebKit Goals for 2020
#100Apple apparently hates the name "progressive web apps", so how about: "offline web apps" or "installable web apps" or just "unrestricted web apps"? I'd like those names more, too. Regardless of the name, where is WebKit's commitment to joining Google, Mozilla, Microsoft, and countless web developers in making web apps first-class apps on iOS? Apple keeps silently "considering" and "accidentally" messing up various as…
PWAs are a Google initiative for Android phones, with Mozilla and Microsoft simply following suit to get their products into Google's platform. Apple doesn't have that problem. They have their own platform with their own goals in mind. Non-native experiences are strictly inferior to native, and they know that. With quality being Apple's primary differentiator in the market, it only makes sense that they would take an extremely measured approach here.