Hacker News Reader

Hacker News

Comment by sirn | Hacker News Reader

Full thread

sirn

Since no one already mentioned about it, here's an update to WebKit in Safari 9.0[1]. Just to pick a few:

* Force Touch Trackpad Mouse Events

* Content Blocking Safari Extensions (bytecode-compiled content blocklist for both iOS and OSX)

* SFSafariViewController for iOS (as an alternative to UIWebKit and WKWebKit)

* ECMAScript 6 support

* CSS properties are now unprefixed (including flexbox!)

I'm excited about the content blocking extension; it replaces the existing canLoad API that needs to be called on every request (which may result in some performance hit) with a JSON ruleset that will be bytecode-compiled and blocked by Safari itself. The better news is that an iOS app could also provide the JSON block list, so this works on Mobile Safari too.

[1]: https://developer.apple.com/library/prerelease/mac/releaseno...

View on HN

Looks like some of the most useful ES6 features (such as lambda arrows and rest/spread/destructuring) are still not supported, so Babel isn't going away any time soon.

Also interesting to see that they redesigned Dev Tools again. I'm guessing enough people found the new ones so much harder to use than the original (that Chrome is still iterating on) that they felt the need to make it look more like what people were used to.

Finally, it looks like they're introducing a filter variant called backdrop-filters. It's in the Apple-edited CSS Filters spec, but I don't see any noise about it from the Chrome or Firefox evangelism teams. I wonder if it will be Apple-proprietary, or if other vendors are interested in it:

https://code.google.com/p/chromium/issues/detail?id=497522

I'm very curious about Content Blocking Safari Extensions as well.

The old mechanism, that is the non-standard "beforeload" DOM event + synchronous messaging via canLoad, had it's issues. But the new one is entirely different from the hooks Chrome and Firefox provide to intercept requests. So I'm certainly not a fan of it either, as this makes it even more elaborate to port extensions relying on content blocking to Safari, and massively reduces the amount of code that can be shared between the respective Chrome, Firefox and Safari extension.

But even more importantly, I fear that it will have some shortcomings when it comes to blocking requests depending on its context (e.g. frame hierarchy). At least I'd be very surprised if they do a better job than Google did with Chrome's declarativeWebRequest API.

If somebody knows any more details about that new API please let me know.

Reply on news.ycombinator.com