Interesting, in the Messages and Proxies[1] page, Apple has ad-blocking as an example which actually blocks the ads from being loaded using the `beforeload` event (as oppose to hide them after they're loaded):
> Safari 5.0 and later (and other Webkit-based browsers) generates a “beforeload” event before loading each sub-resource belonging to a webpage. The “beforeload” event is generated before loading every script, iframe, image, or stylesheet specified in the webpage, for example.
Isn't this exactly what the NoScript's author says Chrome extension was lacking[2]?
Can I be honest and not be thought less of for it?
I actually like Chrome's "load then hide" version of AdBlock because the ad impression counts. It doesn't do much for PPC ads, but for PPI, the website owner has "made an impression" with the ad unit.
Of course, it's robbing the advertiser at the same time....
I'd rather it not count. AdBlock originated out of a deep annoyance/hatred for distracting, exploitative ads - but has since grown to cover just about every advertiser out there, good and bad.
Many people install AdBlock without seemingly realizing this difference. What I would like to see a much more discerning ad-blocking solution that punishes scammy, distracting, or otherwise abusive ads, and rewards advertisers that create consumer-friendly ads.
With a load-then-hide system the website owner has fewer effective metrics on whether or not people are actively blocking his ads. Perhaps when his impressions start dropping precipitously he would be much more compelled to act.
Of course, all of this hinges on the existence of a trusted adblock source that takes upon itself great pains to maintain a list that bans only abusive advertisers. I'm not holding my breath.
On the flip side, it still leaves you vulnerable to Flash-based exploits and consumes related resources (thus increasing overall load time), which is one of the biggest benefits of a pre-block system.
Even if it was, I can't say I've ever understood the people for whom blocking ads was so paramount they'd rather have a page load slower so the ads would never even be glanced, versus a page that loads fast and hides them afterwards.
My experience is exactly to the contrary. Often ads are loaded from some horribly slow server and it slows down the browser which has to wait for them, reflowing the content after each one. Not to mention that ads often change when the page is reloaded, so they're not cache-friendly either.
Compared to downloading the ads, the overhead of running a blocker is negligible, no matter how fast your connection is.
I think it's the main reason Chrome (even with the ad blocker) actually feels slower on many sites compared to Firefox with AdBlock. It may win in terms of raw speed, but Firefox actually has to spend less effort loading the resources, which is a larger gain.
I think the event will include inline contents too, but there's no way to test it right now since it doesn't seems to be enabled in the the current release of Safari 5.
For those who want to see a naive extension in action, I did a quick version of Helvetireader to the Safari extension format. It's trivial, but it also is a good template for further injection projects:
You then must find extensions to install. They can be downloaded from any website, and installed by the browser. Here's one repository of Safari 5 extensions I was able to find:
I wrote a really simple extension that injects jQuery into the current webpage. Not very practical as the same features can be found in a bookmarklet, but fun to make nonetheless.
Is it possible for chrome and safari extensions to be interoperable, especially as they both have the same underlying web-kit technology? Surely, we do not want another platform fragmentation and battle. I am sure developers would love do no more work than recompiling the extension they built for Chrome. It will be a win for everyone.
There is no technical reason why this couldn't work, but my guess is that abstraction libraries will be necessary because Apple and Google won't be able to a agree on a common API. I kinda agree because having to standardise HTML, CSS and JS is hard enough and the browser makers don't wanna open up another battle front. Also, being able to tailor the API tightly to the underlying browser will attract developers and therefore enable more competition.
Nope, different interfaces to the underlying webkit functionality. And they're packed up differently.
I suppose the core functionality of more advanced extensions could be shared, with only different interface glue, but with simple ones, it won't be worth the bother to try to share.
Before this, how did third parties add functionality to Safari? For instance, the button 1Passwoed puts in the toolbar and the item it adds to the context menu for form fields?
Using InputManager[1] or SIMBL[2]. There are several things Safari Extension is not capable of due to lack of API (anything not involving webpage data) so InputManager/SIMBL-plugins are still necessary.
They used other OS X features that weren't meant for browser extensions. That means they tend to break when Safari is updated, and Apple killed a whole class of them in Snow Leopard. And they didn't work on Windows Safari, of course.
It would be nice if you could listen for events, specifically I want to know when a tab is closed so I can add a action to re-open the last closed tab.
They're just packages that you download and install, so they could feasibly be charged for. I'm pretty sure it's impossible to hide the source code, however, so a copy would emerge almost immediately if you tried to make a market for yourself. So yes, effectively all Safari 5 extensions will be free.
> Safari 5.0 and later (and other Webkit-based browsers) generates a “beforeload” event before loading each sub-resource belonging to a webpage. The “beforeload” event is generated before loading every script, iframe, image, or stylesheet specified in the webpage, for example.
Isn't this exactly what the NoScript's author says Chrome extension was lacking[2]?
[1]: http://developer.apple.com/safari/library/documentation/Tool...
[2]: http://hackademix.net/2009/12/10/why-chrome-has-no-noscript/