5

Firefox has a certain tolerance when rendering bad HTML. This means even if a closing tag is left out, the HTML will be displayed as if everything was fine. This tolerance aspect is particularly relevant when one is using JavaScript to manipulate or add content in the current page.

Since I use Firefox as my main testing/developing browser, I've been troubled more than once by this behavior of which the consequences are loss of functionality in "more strict" browsers. For instance the same code in Microsoft Internet Explorer failed to produce any visible output due to the mentioned missing tag on the added content.

Now the question is, is there any way of telling Firefox to be more strict about the accepted HTML and fail instead of "guessing a fix" for it (specially when the HTML is being added via JavaScript)?

PS: I've tried playing with the DOCTYPE but the results were the same.

unode
  • 9,321
  • 4
  • 33
  • 44
  • 1
    i guess firefox is strict only for XTHML (with correct doctype) – Aprillion Mar 09 '12 at 20:11
  • Can you show an example of a file that is rendered OK by Firefox but breaks (to the point of not displaying anything) in IE? My experience is that errors like missing end tags are handled more of less the same in all major browsers. Sure, different browsers handle errors differently, but usually not this badly. – Mr Lister Mar 09 '12 at 21:01
  • @MrLister will work on it and update the question – unode Mar 09 '12 at 21:22
  • OK. Anyway, the answer to "is there a way of telling FF to be more strict" is yes, use XHTML, including the MIME type. That way, it won't even accept `document.write`. Is that good enough? – Mr Lister Mar 09 '12 at 22:19
  • @MrLister the original problem happened while using Jquery and IE 8. I was using XHTML Strict as doctype but I didn't keep the broken version. At the moment I'm having troubles creating a working example with plain XHTML Strict and DOM methods. Could be that Jquery also shares some of the blame. – unode Mar 10 '12 at 00:06

3 Answers3

2

Don't use browsers to check your HTML; they're very much not designed to do that. Use an actual validator, such as the W3C's validator. There appear to be lots of Firefox extensions which will validate the page with a click or automatically, though I'm not familiar with them since I don't use Firefox as my primary browser.

Kevin Reid
  • 37,492
  • 13
  • 80
  • 108
  • even Notepad++ has plugins for that, e.g. TextFX > `TextFX HTML Tidy` – Aprillion Mar 09 '12 at 20:20
  • The problem is, if the HTML is manipulated with Javascript, the "source code" is no longer a flat file and is instead part of the DOM in the browser. In this case tolerance already took place and any in-browser validation would fail to identify post-JavaScript errors. I use the extension @Variant mentioned and it has a "Validate after JavaScript manipulation", but it can only find a subset of errors which in some conditions were found to be insufficient. – unode Mar 09 '12 at 20:35
  • @deathApril the problem is not the static HTML, it's the one generated via JavaScript. – unode Mar 09 '12 at 20:38
  • @deathApril thanks for the link, but you are missing the point here. HTML retrieved that way may be considerably different from what was actually added using JavaScript. I'll try to work on a simple working example and update the question. – unode Mar 09 '12 at 21:21
1

I've found that it is best to just break down and do your primary work in IE.

If you use a good doctype ( < !DOCTYPE html > ) and set the x-ua-compatible header to IE8 mode, the extra work you have to do to make an app work/look good in other browsers is minimal.

BNL
  • 7,085
  • 4
  • 27
  • 32
  • Working primarily with IE is a difficult solution as Windows is not the development environment. I wasn't familiar with the x-ua-compatible header, seems like black magic :) – unode Mar 09 '12 at 23:57
1

All parsers are forgiving to some degree. Most mainstream sites have errors (not that this makes it excusable, just saying). If you develop with a debugger attached, you will catch script errors much more quickly. I also catch script errors by using a minifier in my build process (which will fail on major syntax issues). I valid my HTML markup using Visual Studio 2010's real-time warnings (which aren't always perfect) and periodically use the w3 validator service.

For browser choice, I usually develop across the board; in one sitting I literally may switch between IE7/8/9 modes, Chrome, and Firefox. Safari and Opera usually work if the aforementioned browsers are covered. This way I don't get too far down an erroneous path.

BTW, DOCTYPE is important (even if it doesn't always seem that way).

Tim M.
  • 53,671
  • 14
  • 120
  • 163
  • How do you validate HTML that is assembled in JavaScript? It doesn't exist before execution... – unode Mar 09 '12 at 20:37
  • @Unode - good question. I rely largely on a framework (like jQuery) to create well-formed markup (though it still may be invalid, e.g. illegally nested tags). If I was generating a large amount of markup, I would probably dump it raw to a console window before the browser formatted/reworked it. I would then visually inspect it or paste it into a validator. Now that you mention it, having a more elegant way to do this would be nice. – Tim M. Mar 09 '12 at 21:01
  • @Unode in Firefox, select all, right-click + "Show selection source" will show the generated content! – Mr Lister Mar 09 '12 at 21:03
  • @MrLister this action has the same output as the one indicated on deathApril's comment in KevinReid's answer. Good for quick check though. Thanks – unode Mar 09 '12 at 21:22