Open SamGerber-zz opened 7 years ago
So I think we should probably add is
and isNot
, which match the root node. Then has
and hasNot
are for children only. What do we think? @rtfeldman
Based on this example, it sounds like it's making assertions against the node itself, but in practice, it looks like it traverses all of the node's children. Is this expected behavior?
I think this is unexpected, and a bug.
I think it'll be nicest if it works like this:
has
only applies to the root node.Query.children
/Query.find
/Query.findAll
to get them, and then use Query.each (Query.has [ ... ])
This keeps the API the same size as it is today, and supports either behavior.
This would be a breaking bugfix though. I think it might be too surprising for a patch release.
Here's what I think we should do:
has
and hasNot
to work this way.Thoughts?
Query.has is documented as follows:
Here's the example given:
https://github.com/eeue56/elm-html-test/blob/5.1.0/src/Test/Html/Query.elm#L394-L405
Based on this example, it sounds like it's making assertions against the node itself, but in practice, it looks like it traverses all of the node's children. Is this expected behavior? If so, perhaps the docs could be clearer.
Here's an example test that I'm not sure should fail or pass (it does pass currently):
@stoeffel and I ran up against this earlier, as this behavior causes the test used as documentation for
Query.children
to be a false positive. Children was returning theul
, and the test was still passing because there wereli
elements within theul
:http://package.elm-lang.org/packages/eeue56/elm-html-test/5.1.0/Test-Html-Query#children
Also, it's not clear whether it enforces that a single element must match all the selectors, as this version of the example also passes: