See also #62113

how common is this?

@seankhliao According to github code search there are about 2,600 places where the for loop from the example in the documentation (for c := n.FirstChild; c != nil; c = c.NextSibling {) is used.

For me personally, it's the first time I'm parsing HTML with Go. It reduced code size once I wrote it.

that search result might support #62113, but doesn't say much about needing a find variant

If I add if c.Type == html.ElementNode to the code search query, it goes does to about 170 files. Not sure if this is the right search.

I think if #62113 is added, then this becomes unnecessary because it would be trivial to write slices.Collect(iter.Filter(doc.All(), pred)). Of course, it is still a good idea for a helper library that smooths out x/net/html and makes it more convenient, but for x/net/html itself, it's just providing the core HTML parsing abilities and other capabilities can be added on top in third party libraries like https://pkg.go.dev/github.com/go-shiori/dom, https://pkg.go.dev/github.com/yhat/scrape, and my own xhtml package.

OTOH, doc.All is a special case of doc.FindAll with a predicate that always returns true.

No, as proposed, doc.All() is an iterator, not a slice, so it’s quite different. It doesn’t allocate a slot for every child.

Once we have iterators, we can implement doc.FindAll as iterator as well.
Since we don't know when (if?) iterators will come, I think we can start with a sliced based implementation.

Iterators are on track to release in February of 2024. The Go team aren't going to change the signature of a method in x/net/html after using it ~six months.