Giters

tautologistics / node-htmlparser

Forgiving HTML/XML/RSS Parser in JS for *both* Node and Browsers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

crazy IE-generated HTML is not normalized

kirbysayshi opened this issue · comments

commented

IE8 (at least) will take the following HTML:

<!DOCTYPE html>
<html>
    <head></head>
    <body></body>
</html>

And convert it to:

<!DOCTYPE HTML>
<HTML>
    <HEAD></HEAD>
    <BODY></BODY>
</HTML>

The neat part: node-htmlparser handles this just fine!

The bad: libraries like soupselect (https://github.com/harryf/node-soupselect) and the DomUtils included with node-htmlparser will fail when trying to select 'body'. The DomUtils will select 'BODY' properly, but it's a pain to have to try to select BOTH 'body' and 'BODY'.

Should this be handled on the parser-side of things or the selector side of things? I'm not sure. Part of me thinks that the parser should normalize the HTML to an extent, such as make all the tags lowercase. At the same time, a selector engine could do this normalization when searching.

Thoughts?

commented

After doing a bit more research, it appears that the proper way, at least according to the browser vendors, is that element.nodeName and element.tagName should be uppercased. For example, if you run:

<!DOCTYPE html>
<html>
    <head></head>
    <BODY>
        <p></p>
        <P></p>
        <P></P>
        <p></P>
        <script type="text/javascript" charset="utf-8">
            console.log('4 p tags: ', document.querySelectorAll( 'p' ).length);
            console.log('4 P tags: ', document.querySelectorAll( 'P' ).length);

            var p = Array.prototype.slice.call(document.querySelectorAll( 'p' ), 0);
            p.forEach(function(e){
                console.log(e.nodeName, e.tagName);
            });

        </script>
    </BODY>
</html>

It should output:

4 p tags: 4
4 P tags: 4
P P
P P
P P
P P

I attempted to implement this behavior in node-htmlparser, but it broke the RssHandler test case. However... RSS is technically not HTML, but rather XML, which is case-sensitive!

So, perhaps this is where htmlparser has a choice: to support XML or not?

commented

Update: #24