Live data from Hacker News

WebKit Goals for 2020

trac.webkit.org

91–100 of 154 posts

Re: WebKit Goals for 2020

#91

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…

What is so “real” about the need for notifications? Apart from messenger/email for which we already have dedicated apps both on desktop and on mobile, for what else would we “really” need push notifications? I don’t really want to be interrupted by anything that isn’t urgent, and stuff other than messaging is not urgent at all (I’m talking browser interactions here, I suspect and hope that things like nuclear power plants don’t rely for their “urgent” stuff on browsers’ capabilities and I also hope they don’t have anything to do with easily-hackable browsers at all).

Re: WebKit Goals for 2020

#92
post #2

Pardon 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?

I’ve been using a Trac+Svn combination for my personal projects for 13 years now. I mainly use it for repository browsing, as I don’t do bug/task management for any of my personal projects, but it’s cool seeing repositories 11 or 12 years old. If it ain’t broke why would I fix it?

Re: WebKit Goals for 2020

#93

Earlier 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…

The only use case for notifications and PWAs I'm coming across are clickbait news sites...

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

#94

Earlier 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

Testing iOS Safari is painful on Browserstack, Appium adds significant latency which makes the tests slow, they use old Appium versions which can be buggy, and there are limitations due to poor WebDriver support from Apple like not being allowed to switch context to iframes from external domains...

Re: WebKit Goals for 2020

#95

Earlier 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.

The core problem with Apple's review guidelines is that Apple should not get to set "review guidelines" for software that runs on a phone they sold to someone else, whether or not they happen to be part of a massive oligopoly wherein their sales and deployed fleet constitute some large percentage of phones being sold with quality parts (using supply chains they have locked up through contracts to prevent small competitors, along with patents on hardware features that they bundle access to only with their locked in software ecosystem). And so like, I in some sense agree? But what this means, and the reason why I agree, is that there should exist an app I can install called Chrome or Firefox that implements a web browser that works the way I might want, in addition to the ability to install whatever app I want (which may, or may not, solve the app review problem).

Re: WebKit Goals for 2020

#96
post #56

as 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.

iOS already has progressive web app support

Re: WebKit Goals for 2020

#97
post #20

We 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/

Unfortunately, converting to PNG doesn't work for interactive apps that use SVG as an interactive GUI instead of just a static vector image format. Of course, the user could just install Firefox (or Chrome) to get good-quality SVG support if Apple allowed it, which is why Apple doesn't allow it on iOS. After all, if Apple allowed you to freely choose a fully-working browser, they couldn't force you to use their Apple-only native technologies to get things to work well. It would be much harder to lock you and your customers (sorry, Apple reminds us that they are actually Apple's customers, NOT yours) into Apple's private world.

Re: WebKit Goals for 2020

#98
Apple 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 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

#99
post #11

I'm glad that battery life is a top priority. Though WebP would still be nice to have..

Apple already has HEIC codec on their systems, which is half the size of WebP.

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

#100
post #98

Apple 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…

>where is WebKit's commitment to joining Google, Mozilla, Microsoft, and countless web developers in making web apps first-class apps on iOS?

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.

Post reply on HN