Fotiman - 6:01 pm on Oct 21, 2010 (gmt 0)
1.) It only takes a little PHP and basic understanding of headers to get XHTML to work in all browsers and degrade to regular HTML for IE8 and older...
But why bother? If you're going to serve it as HTML, then it *IS* HTML and therefore should use an HTML DOCTYPE. Also, you've now added a server side dependency that future developers might not be aware exists. And not everyone is running PHP. You've made the simple task of delivering HTML content overly complicated.
2.) document.write does not work with XHTML and if you use it then you cut yourself off from using XHTML easily as well as being stuck in the position of having junk code.
That's a fair point. And again, I don't condone the use of document.write. But again, there are very few sites that serve up actual XHTML content. I think we both agree that document.write should be avoided and I would just leave it at "You should avoid document.write because it's timing sensitive, and also it won't work at all for XHTML documents (if for some reason your application requires XHTML)"
3.) No, innerHTML is horribly unreliable and does not correctly process things in to the DOM which makes scripting with AJAX loaded content a 50/50 and I only prefer 100% chance of things working in normal circumstances.
Can you provide an example? I'm not exactly sure what you're describing. What do you mean by "does not correctly process things in the DOM"?
Stick to using importNode and other node related methods. I don't see why anyone who values standards would promote the use of an unreliable proprietary Microsoft method?
Note, it is not a proprietary Microsoft method. It is supported by all current browsers. Also, innerHTML was added to HTML5, and therefore is now part of the standards.
That or maybe you've been lucky to have it work well enough in your given situations though I really stress the browsers out so it probably comes down to the context of what we're working on.
I think for a large majority of what developers are doing, innerHTML is going to work for them. I know you've done some unique work, and your mileage may vary. :)
26KB is not small, that's over six seconds on dial-up.
Ok, lets do some math here just to clarify. I was referring to a 56k dial up connection. A 56k dial up connection means 56 kilobits per second.
1 KB/s = 8.192 kb/s
So 56kbps / 8.192b = 6.836 KiloBytes per second. 26KB / 6.836KB = 3.8 seconds.
If we assume a slower 33.6kbps connection, then 4.1 KiloBytes per second, 26/4.1 = 6.34 seconds.
Neither of which I consider to be too long for a dial up connection. Admittedly, that is my opinion, and you are entitled to to have a differing one. :)
Given that the average web page takes up 320 KB on the wire [code.google.com], a 26KB file is only 8.125% of the AVERAGE web page. In other words, this is a very minor percentage of what users will experience on average, and IS relatively small.
In addition, a recent survey showed that as of Oct. 2009, 68.7% of Americans had internet access, with 63.5% having broadband internet. That means 5.2% of internet users were using dial up. The only point I'm making here is that the number of dial up users is relatively small (at least in the US... I don't know about numbers in other countries).
don't have time to deal with code that can't be used reliably once much less not used over and over again
I think we will simply have to agree to disagree. :)