github.com/sparklemotion/nokogiri/issues/530 XHTML formatting can't be turned off
github.com/sparklemotion/nokogiri/issues/415 XML formatting should be no formatting
see fairy wing throwdown - SAX parsing is wicked slow.
github.com/sparklemotion/nokogiri/issues/679 Mixing in Enumerable has some unintended consequences; plus we want to improve the attributes API
Some ideas for a better attributes API?
github.com/sparklemotion/nokogiri/issues/528
support :not()
with a nontrivial argument, like :not(div
p.c)
github.com/sparklemotion/nokogiri/issues/451 chained :not pseudoselectors
better jQuery selector and CSS pseudo-selector support:
github.com/sparklemotion/nokogiri/issues/394 nth-of-type is wrong, and possibly other selectors as well
github.com/sparklemotion/nokogiri/issues/309 incorrect query being executed
github.com/sparklemotion/nokogiri/issues/350 :has is wrong?
there are a few tickets about searches not working properly if you use or do not use the context node as part of the search.
github.com/sparklemotion/nokogiri/issues/572 could we fix this by making DocumentFragment be a subclass of NodeSet?
look at those methods, and use of Node#extract_params in Node#{css,search}
we should standardize on a hash of options for these and other calls
what should NodeSet#xpath return?
We have a lot of issues open around encoding. How bad are things? Somebody who knows encoding well should head this up.
Extract EncodingReader as a real object that can be injected groups.google.com/forum/#!msg/nokogiri-talk/arJeAtMqvkg/tGihB-iBRSAJ
It's fundamentally broken, in that we can't stop people from crashing their application if they want to use object reference unsafely.
There are a few methods, like Nokogiri::XML::Comment.new
that
require a Document object.
We should probably make Document instance methods to wrap this, since it's a non-obvious expectation and thus fails as a convention.
So, instead, let's make alternative methods like
Nokogiri::XML::Document#new_comment
, and recommend those as
the proper convention.