“Inspect element” is not the same as “View source” | Hacker News Reader

“Inspect element” is not the same as “View source”

456bereastreet.com

20 pointsjoshuacc11 comments

> When you choose “Inspect element” or otherwise bring up one your browser’s DOM inspector, what you’re looking at is the document tree after the browser has applied its error correction and after any JavaScripts have manipulated the DOM.

Isn't this fairly obvious?

Being unable to inspect elements after you've fiddled with them via javascript would eliminate about 99% of the usefuless...

I think the article was making the point that someone debugging a HTML page would do well to look at both "Inspect Element" and "View Source," as there might be errors only visible in the latter.

For example, a few weeks ago, I was testing a website. It worked fine in Firefox, Chrome, and Safari, but broke horribly in Internet Explorer. A look at the source made me realize that a syntax error in my templates was causing the first few lines of the source (including <html><head>, etc.) to render. The other browsers all ignored this.

I can't, of course, speak to your issue directly but the chrome/webkit debugger usually shows these errors in the console?

It is obvious if you think about it, but often overlooked by developers attempting to debug websites.

True, I suppose. I work with AJAX and the DOM quite a bit, so as soon as I started using Firebug to debug that stuff, it became pretty obvious that it's showing me the DOM as it is, not as it was.

Related question: is there a "gold standard" parsing library for html, like webkit is becoming the standard DOM engine?

I don't know about a parsing library, but the HTML5 spec defines how parsers for it should behave, so at least at some point in the not-too-distant future, it shouldn't matter too much. I think Chrome/Safari already implement it (or at least are fairly close) and Firefox has its own implementation coming in Firefox 4.

If you're looking for one to do HTML scraping, I think it really depends on the language you're using, and I don't think there's a single gold standard.

There's Amaya (http://www.w3.org/Amaya/), the browser that the W3C uses for experimentation.

I'm confused by your question, though; are you implying that webkit is a standard DOM engine, or asking? Webkit isn't a standard, it's merely broadly used. And a standard DOM parser and a standard HTML parser would be one and the same.

I'm playing around with scraping, and one of the first things to do is parse the html.

I was just wondering if there was a standard way to parse it. Right now I'm using HtmlAgilityPack, but I'm not adverse to hooking into a third-party dll (or writing my own parser) if necessary. Just wondering what was out there.

As an example, today I ran into a website with opening <p> tags but no closing </p> tags

Wreaks havoc with the DOM on the parser I'm using. Before I start hosing around with that I was just trying to make sure I wasn't re-inventing the wheel.

Are you asking for something like Hpricot (http://hpricot.com/) or Nokogiri (http://nokogiri.org/)? They will let you parse and search HTML and XML using CSS or XPath selectors.

Xerces isn't bad http://xerces.apache.org/xerces-j/

Reply on news.ycombinator.com