The problem is: the semantics of when link-blocking would be useful are tenuous, at best.

Images can be removed without destroying their surrounding context -- a block of self-contained information might be missing, but the rest remains intact. With Text, there is no such luxury. Examine a test-case: a news-article mentions "doubleclick.net", and the text of the company's name is linked. If you'd set the appropriate filter, Adblock would remove that section of text. That's no longer ad-blocking, it's content alteration. There would be no restrictions: anything you read could have missing blocks of text... and you'd never know.

It's just one line of code to add this in. But, if you really think about it, I think you'll agree- it's best left out.

I agree that removing the entire contents of a link regardless of what they are would be bad.
But what about just removing an image if it is in a link, or if it is the only tag inside a link? I still think this would be useful, although it would require more logic...

I agree that removing the entire contents of a link regardless of what they are would be bad.
But what about just removing an image if it is in a link, or if it is the only tag inside a link? I still think this would be useful, although it would require more logic...

I agree with David Fraser in that it would be really useful if HTML hyperlink elements ("a" tag) could be completely removed if they only contain a graphic.

If I am as a user deciding I don't want to see specific links then I should be free to censor myself in what I get on the screen. If I don't care about any link to doubleshit.net, I can wipe any reference to them out on my screen. So far, we are still mostly living in societies where the recepient is free to look at what I wants to, and are not forced by companies or the government to read that someone other thinks I have to read.

Well, we might consider a conditional for only one image within an anchor-tag.

Which means, if the image had a caption, nothing would block. Also, you'd have to fish the anchor's url out of source yourself. Altering the dialogs to accomodate such a rare condition doesn't seem reasonable.

Examine a test-case: a news-article mentions "doubleclick.net", and the text of the company's name is linked. If you'd set the appropriate filter, Adblock would remove that section of text. That's no longer ad-blocking, it's content alteration.

Wait wait wait... sorry I'm late in here but I guess David did not ment that the content text should be filterd by rules, the rule should only be applied to the link destination: (a href="doubleclick.net/whatever")This will be removed(/a). I think this is reasonable, even if it is text or images... If it is a link and it point to a typical adv.site I would definatley like to block the link content.

Would it be easier if Adblock allows the user to filter either a link (with whatever it is in) or image/object but not both in the same time? From the user perspective it will be something like an extra checkbox next to each entry in the filters list, indicating do we filter link or object by URL.
It is part of another discussion how do we filter a link, but my point is, that it is better not to mix filtering the content enclosed in a link with the filtering of images/objects.

Link-checking for images / objects has landed -- you can grab it off the Dev. page. But there's some caveats:
.
For now, it must be manually-enabled. Type "about:config" into your browser and right-click to create the new pref-boolean: adblock.linkcheck. Set it true. You'll also have to manually locate and enter the link-filters: right-click, Copy Link Location, open Adblock prefs, paste.
.
On graphic-intense sites, the overhead for this is noticeable. For every image / object that loads, Adblock traveserves the dom-hierarchy looking for a containing link.
.
I might update "List Adblock-able" to show containing-links; I'm not sure. If I do, I'll add a corresponding context-item.

Yes I would really like it. When I started to use the linkblock functionality I've practically halved the amount of filterentries. I guess this makes a good speed compensation for the loss in the dom-traversal.

I would really like to see them in the Blockable item list and in the rightclickmenu too if that is not too much hassle.

ryde:
Almost forgot- a few builds back, I landed parsing for JavaScript urls.
.
I tried to account for the range of methods urls can be included in script-links, but unfortunately, there are a few which would slip through. If a script created a global-var with the url *after* Adblock parsed the element, and the element's script-link referenced this, Adblock wouldn't have any way of knowing.
.
Of course, this is uncommonly complicated, so probably few ads link this way.

TO reduce the number of images within the A tags to check, you may consider only checking links whose image isn't already being blocked by the image blocking mechanism. Also you may want to add the option of only applying the block image by link filter if the link is external to the site. If the link is pointing to the current host, leave it alone. This should help with some speed issues.

Hope that helps and keep up the great work. I love AdBlock. Actually, I was using IE yesterday and I got bored then tried out Firebird and the only reason I am still using Firebird is because of the Adbock extension.

Tazan007:
I do appreciate the feedback. Unfortunately, none of the suggestions will really help with speed.
.
Locating the link itself is where the overhead lies. Adblock doesn't inherently "know" if an element is contained by a link, so it crawls up the DOM-hierarchy, checking each parent for an href-property.
.
Also, Adblock takes precedence over the image-blocker, and elements matching any blacklist-filter are all rightly blocked. Preferred functionality, naturally.

Hm, in that case, could it be suggested to the mozilla developers to generate an href list while parsing the html? That may be easier to just implement a check during parsing to add a reference to any object that contains an href.

rue:
Yeah, works fine here. But do you really have to figure out the URL? I intended it to be more like a freetext search of script language content. Then I can make a filter even if the site has a script link obfuscator, by filtering on the script text itself. I bit faster too, I guess.