Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fails with has and direct child selector #43

Open
ViRb3 opened this issue Jan 10, 2020 · 9 comments
Open

Fails with has and direct child selector #43

ViRb3 opened this issue Jan 10, 2020 · 9 comments

Comments

@ViRb3
Copy link

ViRb3 commented Jan 10, 2020

Problem

Cascadia seems to fail with the has psudo-class and a direct child selector

From MDN

The following selector matches only elements that directly contain an child:
a:has(> img)

Cascadia test

var selectorTests = []selectorTest{
	{
		`<html><a><img></img></a></html>`,
		"a:has(> img)",
		[]string{
			"<a><img></img></a>",
		},
	},
        ...
}

Result

selector_test.go:651: error compiling "a:has(> img)": expected identifier, found > instead

Is there any chance to get this implemented?
Thanks!

@ViRb3
Copy link
Author

ViRb3 commented Jan 10, 2020

I just noticed an alternative way to do this, using the :scope psuedo-class. According to MDN, equivalent usage would be as follows:

var selected = context.querySelectorAll(':scope > img');

Unfortunately, Cascadia doesn't support this psuedo-class. Is there an existing way to achieve what I want?

@andybalholm
Copy link
Owner

No, Cascadia has no concept of scope at all. A selector either matches an element or it doesn't. There is no provision for matching an element relative to a given scope. In this sense it's like the Selectors "live profile"—but I copied :has from jQuery.

@mitar
Copy link

mitar commented Apr 28, 2022

In the context of goquery it would be really useful if one could do something like:

table.Find(":scope > tbody > tr > th")

To find only th directly under the top-level table, and not find some nested table. But it seems this is currently not possible.

I made an goquery issue as well: PuerkitoBio/goquery#414

@mitar
Copy link

mitar commented Apr 28, 2022

I was thinking, :scope in the context of cascadia could just be the node from which the selector starts?

@andybalholm
Copy link
Owner

Yes, that's what it would be. But Cascadia selectors don't know where they start. The basic interface of the Cascadia package is Matcher:

type Matcher interface {
	Match(n *html.Node) bool
}

A Matcher can be called on to match a node from anywhere in the page, in no particular order. It has no concept of a "starting point".

@mitar
Copy link

mitar commented Apr 28, 2022

But it would work for MatchAll and Query.

@andybalholm
Copy link
Owner

No, because those are implemented as wrappers around Match. Almost everything in Cascadia is built around the Match interface.

Support for scope would require such an extensive rewrite that the result wouldn't really be Cascadia any more. It would be an all-new CSS selector package.

@erkie
Copy link

erkie commented Jan 4, 2023

Just so I understand this thread, support for div:has(> article) will not and cannot be support in Cascadias current form?

@andybalholm
Copy link
Owner

Right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants