You want to dynamically enable xmlMode? That will require further changes to the tokenizer. Otherwise, I'd prefer to just add another attribute to the instance (instead of the method).

I am just looking for more fine-grained control over the parser and no changes to the tokenizer are required. I updated the parser to allow the option to recognize self-closing tags and CDATA while still in "HTML mode". The issue was that "xmlMode" was a single option that was being used to control a lot of different parsing behaviors. In my case, I have HTML files that may include XML constructs such as self-closing tags and CDATA sections. The changes I made will not impact existing code at all because there will only be an impact on parsing if the new options are enabled.

As a separate fix, I fixed the bug where the "lowerCaseTags" and "lowerCaseAttributeNames" options were not working as expected. I pushed to the same branch so that commit was merged into this Pull Request.

Please let me know if you need more clarification. Thanks for looking into this Pull Request

What I was saying is this: If you don't want dynamic xmlMode (which you apparently don't): Add a _lowerCaseTagNames attribute to the instance and get rid of the isLowerCaseTagsEnabled() method.

I'll make the change and add a new commit. Thanks.

I have updated my Pull Request with the suggested change. Please review and let me know if you find any issues. Thanks.

I think we are close. I updated the code to handle the case where options is null and verified that tests passed. I also updated the code to allow truthy values for the lowerCaseTags and lowerCaseAttributeNames options. However, I chose not to use "in" since that only checks for the property being in the options and would evaluate to true even if one of the option values was set to false. Please review the updated code and let me know if you would like me to make any additional updates. Thanks

I reviewed the changes independently and they look good. I like the fine-grain control over XML-like parsing behavior instead of having only a single "xmlMode" flag. The only line that didn't need to be changed was "this._options = options || {};" (which was split into two lines).

Are there any other changes that need to be made before this can be merged?

I don't really understand why the in operator shouldn't be used. == null does pretty much the same, but ignores properties with the values null and undefined. I would also prefer to avoid polymorphic variables (ie. options).

The reason in is not a good choice is because the following code would not work as expected when using in:

var parser = new htmlparser.Parser(handlers, {
        lowerCaseTags: false
    });

The user would expect the lowerCaseTags option to be set to be false, but because that property is in the options it actually is set to true because:

("lowerCaseTags" in options) === true

The following expression will result in the correct boolean value:

(!!options.lowerCaseTags) === false

For your second point, why would you want to avoid polymorphic options argument? The parser already supported an options argument so I don't see the harm in extending it with new options.

I updated the code to use the in operator as suggested.

Feel free to merge my change and make any additional syntactic changes if you think they're necessary. My end-goal is to have additional control over parsing behavior in HTML parsing mode via the new options.

Thanks.

It would also be great if you could update the wiki page to reflect these changes.

Please review the latest change with the options init code merged into a single line.

Also, I think it would be beneficial to move the documentation on the Wiki into the README so that the documentation is versioned with the code. Thoughts? Would you like me to make that change?

Merged and done! Thanks a lot, @patrick-steele-idem!

It would probably be beneficial to move the documentation to the module, but eg. the cheerio docs link to the page & I doubt it's worth the effort.