BlockIt: Flexible Web Element Blocking with Full Control Over Rules

Many websites contain elements you'd rather not see: intrusive banners, pop-ups, advertisements, or simply unnecessary parts of the interface.

Modern ad blockers not only use predefined filter lists but also allow users to manually select elements to block. In most cases, that's enough: select an element, create a rule, and it no longer gets in your way.

But sometimes things are more complicated.

For example, a blocked element may reappear after a page reload because its classes or position in the DOM have changed. Or an automatically generated rule may affect other elements that the user never intended to block.

In these situations, it's important not only to specify which element should be blocked, but also to determine exactly which properties should be used to find it.

To address these challenges, I developed BlockIt — a free Chrome extension that lets users create flexible rules for blocking web page elements.

BlockIt supports standard CSS selectors, XPath, and its own extended syntax, which can take additional properties of elements and their surroundings into account: text, attributes, classes, DOM position, relationships with other elements, and much more.

You can also create and customize rules without knowing selector syntax or specialized expressions. BlockIt provides tools for choosing relevant element properties, excluding unstable attributes and classes, combining search conditions, and checking whether a rule continues to work after a page reload.

This makes BlockIt useful both for advanced users and web developers who need detailed control over element matching, and for anyone who has encountered a particularly annoying element that cannot be reliably removed using conventional methods.

The main idea behind BlockIt is to give users the tools to create precise, reliable rules while letting them decide which properties should be used to identify elements for blocking.

Why a Regular CSS Selector Isn't Always Enough

Imagine a page containing several similar blocks. You need to block just one of them without affecting the others.

Chrome DevTools lets you automatically copy the CSS selector of a selected element. For example:

#app > div:nth-child(2) > div:nth-child(3)

This selector finds a div element that is the third child of another div. That parent div, in turn, must be the second child of the element with the ID app.

The selector may work correctly on the current page. But if the website's developers add another container or change the order of elements, it may start matching a different block or stop working entirely.

Another common problem is dynamically generated classes.

For example, an element might look like this on one page load:

<div class="banner_a8f32">

And like this on the next:

<div class="banner_c91e4">

The selector .banner_a8f32 matches an element with the class banner_a8f32. Once the class changes, it can no longer find the intended block.

Sometimes choosing a more stable CSS selector is enough. But there are situations where precise matching requires additional properties: text content, the number of attributes, position relative to other elements, or a combination of several conditions.

BlockIt provides additional capabilities for exactly these situations.

What Is a BlockIt Rule?

Before exploring the different ways to create rules, it's worth clarifying the terminology.

In the broad sense, a BlockIt rule is a description of how to find page elements that should be blocked.

Several methods can be used to find elements:

• CSS selector — the standard syntax for selecting DOM elements.
• XPath — an expression language for locating elements within a document's structure.
• BlockIt syntax — the extension's own syntax, which adds capabilities beyond standard CSS selectors.

Therefore, even an ordinary CSS selector becomes a BlockIt blocking rule when added to the extension.

However, the extension's interface also uses the term "BlockIt Rule" in a narrower sense — to refer specifically to an expression written using BlockIt's own syntax, as opposed to a standard CSS selector.

For example, after creating a rule, you may see a label such as "CSS Selector" or "BlockIt Rule". In this context, these labels indicate the syntax being used.

Several Ways to Create a Rule

I wanted BlockIt to be suitable for both simple tasks and situations that require detailed control over element matching.

That's why the extension offers several ways to create rules.

1. CSS Selector

The simplest approach is to select an element in Chrome DevTools, copy its CSS selector, and paste it into BlockIt.

But DevTools isn't required: you can write a CSS selector manually or edit an existing one.

For example:

div.notice[data-type="promo"]

This selector matches div elements that have the class notice and a data-type attribute with the value promo.

The extension displays the number of matching elements. This helps you check whether the rule affects any unintended elements.

You can choose one of two actions for matched elements:

• Remove — completely remove the element from the DOM, usually freeing up the space it occupied.
• Hide — make the element invisible while preserving the space it occupies on the page.

The second option is useful when removing an element disrupts the page layout.

2. XPath

BlockIt also supports XPath expressions.

For example:

//div[@data-type='promo']

This expression finds div elements whose data-type attribute has the value promo, regardless of their position in the document.

XPath provides additional ways to locate elements and navigate the DOM.

However, XPath does not guarantee stability by itself. If an expression relies on changing attributes or element positions, it can also stop working.

3. Quick Rule from HTML

One of the most convenient ways to create rules is the Quick Rule tool.

Instead of providing a selector, you can simply copy the HTML of the desired element from Chrome DevTools and paste it into the corresponding field in BlockIt.

The extension parses the HTML and lets you choose which properties should be used for matching.

For example, suppose the original element looks like this:

<div id="cmpbox" class="cmpbox_a8f32" role="dialog">

If the class cmpbox_a8f32 is dynamically generated, you can exclude it and keep only the attributes id="cmpbox" and role="dialog".

Then simply click the "Add Rule" button.

This way, users can decide which attributes and classes to include without having to write a selector manually.

Rule Builder

For more complex cases, BlockIt includes a Rule Builder.

It allows you to define element-matching conditions through a graphical interface without requiring knowledge of CSS, XPath, or BlockIt's own syntax.

The Rule Builder can take into account not only an element's own properties but also its surroundings.

For example:

• HTML tag, classes, and attributes;
• text content, including substring matching and regular expressions;
• number of classes and attributes;
• position among sibling elements;
• properties of parents, ancestors, descendants, and siblings;
• distance to a sibling and the absence of certain related elements.

These conditions can be combined.

Suppose a page contains several elements with identical classes, but the one you need is inside a container with a particular attribute. Instead of relying on the element's position, you can use properties of its surrounding elements.

Or, if classes keep changing, you can try identifying the element by its text and other more stable characteristics.

The Rule Builder displays a human-readable description of the generated rule. This helps users understand which properties are involved in matching, even if they aren't familiar with selector syntax.

Testing After a Page Reload

Finding the correct element once doesn't necessarily mean you've created a reliable rule.

On dynamic websites, it's important to make sure the rule continues to work on subsequent page loads.

That's why the Rule Builder includes a test after page reload feature.

It lets you compare the number of matching elements before and after reloading the page.

If matches disappear or their number changes, this may indicate that the selected conditions are unstable.

You can adjust the rule and run the test again.

Of course, matching the same number of elements doesn't guarantee that the rule will always find exactly what you intended. But this test helps identify certain problems while the rule is still being created.

BlockIt's Extended Syntax

Not all conditions available in the Rule Builder can be expressed using standard CSS selectors.

For example, standard CSS does not support matching elements by arbitrary text content or checking the number of attributes an element has.

For these situations, I developed BlockIt's own syntax, which extends the capabilities of CSS selectors.

For example, you can match elements by their own text while ignoring text inside nested elements, check the number of classes and attributes, or define additional conditions involving surrounding elements.

If the conditions selected in the Rule Builder can be expressed using standard CSS, the result will be an ordinary CSS selector.

If additional capabilities are required, the Rule Builder generates a "BlockIt Rule" — here, the term is used in its narrower sense, meaning an expression written using the extended syntax.

In either case, the user gets a ready-to-use rule for finding and blocking elements.

And there's no need to learn BlockIt's syntax: complex conditions can be configured directly in the Rule Builder.

For those who prefer writing expressions manually, the BlockIt syntax documentation is also available.

When a Regular Element-Blocking Tool Isn't Enough

Imagine a situation: an annoying element appears on a website, and the standard filters of your installed ad blocker don't remove it.

You decide to block it manually using the ad blocker's built-in element picker. You select the unwanted block, create a rule, and the element disappears.

But after reloading the page, it comes back.

The reason may be that the automatically generated selector relied on a dynamically generated class or a changing DOM structure.

In this situation, BlockIt offers several possible approaches.

You can manually choose a more stable CSS selector, use XPath, or create a more complex rule with additional conditions through the Rule Builder.

For example, you can stop relying on a dynamic class and instead use the element's text, attributes, or properties of surrounding containers.

You can then test the rule in the Rule Builder after reloading the page.

This can help block certain complex elements for which an automatically suggested selector wasn't reliable enough.

Of course, similar problems can be solved using other tools. For example, uBlock Origin supports advanced cosmetic filters that can express complex matching conditions.

What makes BlockIt distinctive is its combination of multiple ways to create rules, detailed control over matching conditions, and tools that make complex rules accessible without requiring users to learn specialized syntax.

At the same time, the extension doesn't promise to automatically find the perfect properties for every element.

A rule's reliability depends on the characteristics of the particular page and how well its matching conditions are chosen. BlockIt provides the tools to tackle this problem, but the final choice remains with the user.

Working with iframes and Shadow DOM

Some page elements are not located in the main DOM document.

For example, content may be placed inside an iframe or use Shadow DOM.

This introduces additional challenges when finding and blocking elements.

BlockIt supports applying rules inside iframes and Shadow DOM, although different matching methods have certain technical limitations.

In particular, XPath cannot cross a Shadow DOM boundary. For such cases, rules based on CSS or BlockIt's extended syntax can be used.

In addition, BlockIt's own syntax provides special conditions related to iframes and Shadow DOM.

This expands the possibilities for finding elements in complex web page structures.

How BlockIt Relates to StableHTMLFinder

In my previous article about StableHTMLFinder, I discussed the problem of unstable CSS selectors and how to analyze DOM changes across page loads.

StableHTMLFinder and BlockIt solve different but related problems.

StableHTMLFinder helps identify which elements and properties remain stable across repeated page loads.

BlockIt lets you use those properties to find and block unwanted elements.

For example, if a block's classes keep changing, you can first analyze the page using StableHTMLFinder, identify stable properties of the element itself or its surroundings, and then use them to create a rule in BlockIt.

StableHTMLFinder can also generate CSS selectors and expressions using BlockIt's syntax, which you can copy into the blocking extension.

However, using both tools together is entirely optional: BlockIt works independently.

Managing Rules

Once you've created a rule, you can also manage it.

BlockIt lets you disable rules without deleting them, organizes them by website, and supports exporting and importing settings.

This is useful when you've accumulated many rules for different websites.

All rules are stored locally in the browser and are not sent to a server.

BlockIt's source code is open and available on GitHub under the BSD-3-Clause license.

Try BlockIt

BlockIt is a free Chrome extension.

If you'd like to try it yourself, visit the official BlockIt page, where you'll find a link to install the extension from the Chrome Web Store.

I've also prepared a detailed guide with examples and screenshots to help you explore the extension's features. It covers different ways to create rules, from a simple CSS selector to the Rule Builder with complex conditions.

If you've encountered elements that were difficult to block using ordinary CSS selectors, I'd be interested to hear how you approached the problem.