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

It sounds like this is simply a case of you not wanting to take the time to learn the framework and give it a fair chance. jQuery is well documented, and extremely reliable (when you know what you're doing). I admit, it took me a long time to come around to jQuery, but it really is a very elegant and powerful framework. Saying that it's unreliable because someone developed a plug-in that used it, and someone else developed a theme that used it, and the code was messy is not a good argument. The code may have been a mess, but it doesn't need to be, and that has nothing to do with whether the developer used a framework or not. There are plenty of scripts out there using plain old vanilla JavaScript that are just a mess. Whether the code is written using jQuery or not is irrelevant... the blame there sits on the developer.

I think we will simply have to agree to disagree. :)