DocumentFragment#search and #at don't handle CSS selectors properly

[epitron]

Hi there!

I just discovered an odd bit of behaviour for HTML::DocumentFragments. If I try to select elements in the fragment using the #at or #search methods with CSS selectors, no elements are matched. If I use the #css method, however, I do get elements back.

Here's a script to demonstrate the problem:

require 'nokogiri'

puts "Nokogiri version: #{Nokogiri::VERSION}"
puts

a = Nokogiri::HTML.fragment '<em class="testclass">content</em><br /><br /><div id="testid">other content</div>'

puts "The tag: #{a}"
puts
puts "Using at('#testid'): #{a.at("#testid")}"
puts "Using css('#testid'): #{a.css("#testid")}"
puts "Using at('div') #{a.at("div")}"
puts
puts "Using at('.testclass'): #{a.at(".testclass")}"
puts "Using css('.testclass'): #{a.css(".testclass")}"
puts "Using at('em'): #{a.at("em")}"

Note that maching on the tag name does work, for some reason, but classes or IDs don't.

I was expecting the fragments to behave the same as regular Nokogiri documents. Is this a known problem?

Thanks for your time!

[flavorjones]

@epitron,

Thanks for reporting this. Super interesting! I believe this has to do with how we're handling document fragments, and ignoring root nodes. I'll investigate.

[flavorjones]

We're missing an specialization of NodeSet#search. Working on it now.

[flavorjones]

I'd also like to note here that #search is always going to be slower than choosing #xpath or #css, so if you know you have CSS, I'd advise using the appropriate method.

[flavorjones]

Will be in the next release of Nokogiri, hopefully sometime in the next week or so.

[epitron]

Awesome! Thanks!

Good to know about that performance trick as well!