Remake :upward() after Sizzle replacement

[slavaleleka]

Limited to work properly only at the end of selector, except of pseudo-class :remove().

What is the reason of this limitation?
I mean that in third party filters there are few rules like this #?#selector:upward(1) + anotherSelector, so these rules will not work.

For example in Swedish filter:

tidningen.nu##span:has-text(/^Annons$/):upward(1) + .textwidget
viafree.se##.vjs-playing:upward(1) ~ .no-autoplay-overlay

https://github.com/AdguardTeam/FiltersRegistry/blob/6cce7c92672856220f256e85a26a2494196e35c3/filters/ThirdParty/filter_243_FrellwitSwedish/diff.txt#L200

Originally posted by @AdamWr in #102 (comment)

[slavaleleka]

merged into #110

[krystian3w]

I have another one idea with upward:

mail.yahoo.com#?#div[data-test-id="efv-subheader"]:has(:upward(1) ~ div[data-test-id="video-container"])

and this is needed for AdGuard only:

mail.yahoo.com#?#div[data-test-id="efv-header"]:has(~ div[data-test-id="video-container"]) > div[data-test-id="efv-subheader"]

[Yuki2718]

It's hard for a layman like me to understand why supporting :upward is so hard when AG already supports :nth-ancestor.

[krystian3w]

Sizzle block use in other place as end in filter.

[ameshkov]

Pseudo-classes like :nth-ancestor, :remove and :xpath break the semantics of CSS selectors and that's why they are not compatible with a general-purpose CSS selectors engine we're using (Sizzle). We implement them using some rather ugly workarounds, but the only real solution would be to get rid of Sizzle and implement the parts we need by ourselves.

[Yuki2718]

@ameshkov Thx for clarification!