From 601a9eefc3bc726fc10ddb85db66e4cff9446d88 Mon Sep 17 00:00:00 2001
From: garry-ut99 <72945564+garry-ut99@users.noreply.github.com>
Date: Sun, 27 Oct 2024 18:07:27 +0000
Subject: [PATCH] Updated: ":upward() vs :has()" (2)

---
 Filter-Performance.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Filter-Performance.md b/Filter-Performance.md
index 16624d1..088da19 100644
--- a/Filter-Performance.md
+++ b/Filter-Performance.md
@@ -10,7 +10,7 @@ See:
 - https://reddit.com/r/uBlockOrigin/comments/wxdyfn/comment/ilqyveu/
 - https://reddit.com/r/uBlockOrigin/comments/j4ewg7/comment/g7imasx/
 
-Keep in mind that all major browsers now supports `:has()` natively, so native `:has()` should be more efficient than `:upward()` and procedural `:has()`, which need Javascript code to function. When using `:has()` uBlock will automatically switch to native `:has()` if it's available in browser, if it's unavailable uBlock will fallback to a procedural `:has()`.
+Keep in mind that all major browsers now supports `:has()` natively, so native `:has()` should be more efficient than `:upward()` and procedural `:has()`, which need Javascript code to function. When using `:has()` uBlock will automatically switch to native `:has()` if it's available in browser, if it's unavailable uBlock will fallback to a procedural `:has()`. Using `#?#` (instead of `##` for a procedural cosmetic filter will prevent uBO from trying to convert the filter into a declarative one.
 
 Sometimes using `:upward()` instead of `:has()` _might_ be more performant. `:upward()` is fast, it just lookup ancestors -- there is only one parent per element, `:has()` has to lookup descendants, there can be many children per elements.