There was a lot of discussion around Safari 15.4 beta supporting Web Push on iOS but a ton of other great highly demanded features are coming.
Just a few highlights:
* RegExp lookbehind assertions
* outline following border-radius
* Declarative Shadow DOM
* WASM SIMD
* OffscreenCanvas (2D only for now)
Check out the beta or a recent STP release. We welcome feedback, including what you’d like to see next.
@othermaciej I was going to say that it would be nice to have access to :has() selector in content blockers, because I've tried this once before and it didn't work, but I've just checked and it seems to work! My content blocker app likes this 😎
(I'm hiding cookie banners and the popups are sometimes not tagged with anything unique, but they contain something that can be identified somewhere inside)
@othermaciej There's another thing I always wanted to have to solve another subset of troublesome popups, but it might be a bit out of scope (?) - to be able to "deactivate" a CSS class on the page as if it wasn't there - so if a script adds e.g. ".noscroll" to body which sets overflow:hidden, I can disable that .noscroll class and reenable scrolling
@othermaciej hey, sorry I didn't respond, I had to recheck how this all works…
I'm trying to stick to content blocker only. Injecting scripts would solve a lot of things, but it also adds this scary permission warning (even if it's only CSS and not JS, I think - can you actually do what it says if it's only CSS?).
I think people feel safer if they know my extension can't inject anything there. Just this week Chrome told me that an extension I had installed has become a cookie-stealing malware…
@othermaciej without injecting JS/CSS to the page, there are a few categories of popups I can't deal with using just a content blocker & css-display-none:
1) unmarked/obfuscated class - `:has` will hopefully fix some of those
2) blocks scroll by setting overflow:hidden/position:fixed via style="…"
3) blocks scroll behind popup using a class that does the same
Something new in content blocker API could help with 3, probably not 2. Although objectively, I guess it might be a too niche feature…
@othermaciej I've checked how it looks with Web Extensions, but it seems it looks even more dangerous than an App Extension with injected CSS, because you have to first enable the extension and then manually grant it access for all sites, and then there are exclamation mark signs everywhere…
@othermaciej I made this monstrosity now and it works on that site too 😅 Should I be worried that this may be too complex and affecting performance somehow, or is this all super optimized behind the scenes?
@othermaciej oh man I would have killed to have WebKit support for OffscreenCanvas at my last job. That's a real nice cache but I know that it will be super useful to a lot of folks when it's finally supported in all evergreen browsers
@othermaciej how can I check for webgl support in OffscreenCanvas? Do I really have to do UA sniffing and know that Safari doesn’t support it?
@sto3psl I think you can feature test this directly by trying to make a GL context for an OffscreenCanvas - it will error out if this combo is not available.
@othermaciej I tried and it doesn’t error 🙈. I still get a GL context from the OffscreenCanvas but everything renders broken (because the feature is not ready, I guess).
@sto3psl This was a bug in an earlier beta. The intent is that OffscreenCanvas will not support "webgl" contexts regardless of whether it's on a worker. Expect to see that fix in an upcoming beta, it should allow for easier feature detection. (Sorry, I didn't realize it hadn't been in a beta yet). https://bugs.webkit.org/show_bug.cgi?id=253267
@othermaciej that sounds great, thanks. Is there an ETA for „webgl“ OffscreenCanvas? 😅
Oh and I don’t have permission to see the linked issue.
@sto3psl Sorry about that, it’s restricted for technical reasons I can’t fix right now but the upshot is to disable “webgl” for main thread OffscreenCanvas.
I can’t share when actual support for WebGL OffscrenCanvas is coming but it’s something we are interested in.
@othermaciej Please can Apple make sure OffscreenCanvas is finished (supporting WebGL) before shipping it so it doesn't break years worth of web content? https://bugs.webkit.org/show_bug.cgi?id=253431
Releasing a partial implementation passes feature detection and then fails when it tries to use the missing WebGL context. This breaks *all content published in Construct*.
I also have heard nothing so I'm waiting to find out if this is going to cause a disaster for us or not.
@AshleyGullen we are evaluating this, but it’s likely we will still ship the 2D support before 3D. We believe it is conforming per spec to support OffscreenCanvas without WebGL. And it should be feature detectable (just try making a gl context in an OffscreenCanvas and see if it fails). How much is the impact to update the feature test?
@othermaciej We already have updated it, but it affects all content published by users of our app for the past couple of years, and they will all need to re-publish their content to avoid being affected. It's a collossal job to ask everyone to do that and I would be surprised if even 10% of customers did that prior to the Safari release.
@othermaciej We did add feature detection, but only for the existence of OffscreenCanvas, because we did not anticipate anyone shipping only some contexts. Since Safari supports WebGL in OffscreenCanvas in the DOM it is not actually possible to feature detect this prior to creating a worker, which makes feature detection even harder
@othermaciej I can't understand why Apple would do this - what did they expect to happen to all existing OffscreenCanvas WebGL content? Why not postpone it for a release and ship with WebGL support to be on the safe side?
@othermaciej will there be native support for things like actions, icon, and image from the Notification Web APIs?
QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.