Related
I have a Firefox extension that supports Firefox 3+, and SQLite database is important for my extension. I saw on the MDN that the API might change and it`s "unfrozen", should I be worried about it?
The API is currently "unfrozen", which means it is subject to change
at any time; in fact, it has changed somewhat with each release of
Firefox since it was introduced, and will likely continue to do so for
a while.
This warning is probably outdated, it has been added to the original version of the document years ago and hasn't been updated since. Fact is, starting with Firefox 4 all APIs are unfrozen and could change. But that shouldn't really be a reason to worry. As SQLite access goes, the API seems pretty mature by now and Mozilla developers are mostly tweaking performance without introducing breaking changes. The most important change was the introduction of asynchronous API in Firefox 3.5 and the deprecation of the synchronous API. But as long as you only use asynchronous API you should be on the safe side (I cannot imagine that you really need to support the ancient Firefox 3.0 release, I guess that you actually meant Firefox 3.6).
For something so widely used I doubt it but it's easy enough to write code to work around that and keep your addon backwards compatible (at least in javascript). What I ended up doing is abstracting away methods that did change and wrapping them in my own calls that would do something like
if (methodInFF3) doFF3Method();
else doNewMethod();
or something like that. This way when things changed I only had to change the code in one place instead of many but then again the first time it happened I had to change the code everywhere. For SQLite I probably wouldn't worry too much though but that's just me, just make sure that when a new release comes out you check the docs to see if anything has been changed and you should be fine.
With different browsers choosing to render CSS in their own preferred way , whats the point of having a standard?
Simple stuff like creating a fluid 3 column layout that works across all browsers can be an experience in frustration. How do you deal with this or make cross-browser compatible development not so painful?
As always, there's a reason behind all this.
The standard is not broken (a standard can't be broken), just that some browsers like IE don't adhere to it completely.
This is mainly because IE was developed before any standard was created and in that time it was the best browser around, with almost zero competitors (I read that netscape was the other option and that it was much worse than IE).
Then people realized that a standard was needed, and they created it obviously not including any of IE proprietary code and features. IE was forced to choose backwards compatibility with it's previous versions, or to adhere to this new "standard", they absolutely ruled the browser market so the choice was obvious.
With new versions IE tried to be more and more standards compliant, and they say that IE8 successfully passes the ACID2 test, so the standard utopia is (slowly) coming to reality.
In the mean time, check this site -> quirksmode that contains useful cross browser information. Also try to check any articles about "IE box model" online, and stay away of padding in IE. If you also use a 3rd party javascript library (JQuery, Prototype, Dojo) you should be fine (or as fine as anyone of us can be).
Regards.
One major point of having standards is to keep us out of another browser war. You know the one where Netscape and Microsoft kept adding as many proprietary features as they could to the browsers. Cross browser development is a breeze today compared to then...
Another good reason for having standards is that you know where future versions of the browsers will be heading. Following the standards is the best prediction that you can get for how future browsers will work.
You can find a lot of cross-browser tips in this question: How can I achieve a consistent layout in all browsers?
Standards are emergent, not pre-defined. Well, at least they should be. Many developers I've talked to seem to find my view of Web standards slightly heretical, but stay with me here.
When you try to create the standard before the implementation, you have several problems:
A long delay before useful implementations appear. Nobody has a working implementation to reference, and since nobody is using any of the standard's features (since it doesn't exist yet), there is little impetus to actually implement it. A chicken-and-egg type of problem.
The potential for standards that cannot actually be implemented. Who knows for sure until somebody actually tries it? The HLA standard was a good example of this happening, to the point where the DoD had to write an "interpretations" memo that attempted to set the de facto standard by glossing over some of the errors in the actual standard.
The potential for standards that don't serve any practical need. Do people actually want this? See example at XForms, which has fallen into a weird, server-side niche. Or, I can't think of anybody I've met who found the CSS "width does not including padding" box model to be intuitive.
An inability for implementers of the standard to distinguish their products from their competitors, resulting in a stubborn desire to break with the standard in practical or lock-in-encouraging ways. See example at CORBA.
I think that the W3C learned this the hard way in recent years. Some of the most end-user visible innovation has come from a new browser war: examples would be HTML5 (several vendors), canvas (Apple), XMLHttpRequest (Microsoft's Outlook Web Access team), input range (Safari's built-in RSS reader), and the video element (Firefox)--these came from the proprietary level on up, not from the standards tower on down. And these new "standards" were forged by looking at these past individual implementations (Firefox copied Microsoft largely for XMLHttpRequest, and so on), not by some wide-eyed think tank pondering the future. (ISAPI, the Netscape plugin API, and SQL are all examples of bottom-up standards, where breaking changes are done gradually in a lock-step fashion.)
A standard should be a least common denominator that smooths over the basic differences in implementations, a pidgin language that works across all of them, and not an enumeration of Robert Lowth-style prescriptive rules about a language or system, because then you end up with rules that don't always make sense or apply a non-realistic ideal (like trying to apply Latin-based grammar rules to a Germanic-based language, like trying to apply XML-based grammar rules to an SGML-based language). Oh well, this is what we've got.
Probably the greatest defect in the CSS standard at this point is that there really isn't a good way to specify that a page was written against a particular version of the standard. We can specify DOCTYPEs for our HTML documents, why can't I indicate that a document was written for CSS 2.1? This will only become more important as we start adding more and more bizarre features to CSS that affect the actual content of the page, such as CSS's :before pseudo-elements. A future version of the standard is going to have errors one day that potentially break compatibility, and it'd be nice to let the document author ask for certain behavior rather than have browsers attempt to figure out the intent.
On the lighter side, though, now that IE8 and IE7 are out, things really aren't as bad as they were in, say, 2005. A specific IE6 stylesheet served with conditional comments can really go a long way to making a CSS/standards-based implementation feasible. The other advice is to use Google, to take the 3-column fluid layout example, and hope that someone else has done most of the troubleshooting for you.
Creating a cross-browser compatible Web site is difficult, standard or no standard. You can make it easier on yourself if you accept that there will be some differences in the way different browsers render your site. Don't be afraid of proprietary extensions by any means (it's all right to have CSS3 rounded corners for your non-IE users), but have a fall-back for when they don't exist (eh, the rounded corners aren't critical for using the site), and let your users choose how they'd like to consume your content.
The other answers to this question pretty much cover the ins and outs of why CSS isn't the problem, but as for how I deal with the cross-browser difficulties, it's normally in roughly 4 steps:
Design the site using firefox, as it has lots of useful extensions (most notably Firebug, which tells you which CSS rules are being applied, which are being over-ridden by other rules, etc.)
Check the site quickly in Safari and Opera to make sure design has no flaws there. Normally it'll work fine as - thanks to the CSS web standard - these browsers render web pages in almost identical ways
View the design in ie7 and use the *+html css filter to correct errors
View the design in ie6 and use the * html css filter to correct errors
to do points 3 and 4 yo would have something like this
.box {css rules}
*+html .box {css rules to override in ie7}
* html .box {css rules to override in ie6}
At the end of all this you will still be left with valid css that works across the major browsers.
Hope this helps
*edit - forgot to add that ietester is a great bit of software that allows you to install multuiple versions of ie on windows xp or vista: http://www.my-debugbar.com/wiki/IETester/HomePage
The standard has some shortcomings. It's also quite a difficult thing to implement. The problem is in the implementation more so than the standard.
Use things like YUI where a lot of smart people have done a lot of hard work to make these things work across various browsers.
The standard is there in the open so that the browsers who do not confirm to the standard may look and learn. The standard is important because it is the only way by which you can HOPE to make a webpage that will display correctly on all pages.
Also remember that a standard that is developed is never for the past, it is only for the future. If in the past some browsers did not confirm to the standard it doesn't mean that we should not have standard.
In fact the standard is born because the browsers were all doing their own thingie and there was then a need for the standard.
If you code to the standard the browsers will confirm to it.
Have a hope pal!
It looks to me that You are just starting with CSS. Because even though the browsers do not adhere to the CSS specification perfectly, there is a lot of safe ground that You can use with confidence. This safe ground is nowadays much larger than it used to be about ten years ago, when coding for web was really a royal pain. And new browser releases adhere to the specification more and more, which is exactly why the standard matters. It is a kind of theoretical ideal that the browsers will probably never fully achieve, but even 90–95 percent of it are quite useful in the real world.
I also wish IE would have better implementation of CSS, but once You learn the few things that behave oddly, You can code most of the usual layouts without major hiccups. Most common layouts have also been discussed to death on various CSS forums on the web and there is always some good solution readily available so that You do not have to make it up yourself.
The CSS standard is IMHO not the problem [at least not in the sense of Your question], the problem is the reality of the browser market and the software market in general. As for the frustration, it should mostly go away after You gain some experience. The limits will always be there, but there is a plenty of safe space.
That seems like a non-sequitur. Just because some browsers flout web standards does not mean there's something wrong with the standards themselves. It's a bit like saying that seatbelts are broken because some people choose not to wear them, or that drunk driving laws are pointless because some people don't obey them.
If there were absolutely no standards to conform to, then there would be no World Wide Web, period. Just like an egalitarian society is an unachievable ideal, yet striving for that unattainable ideal has produced tremendous social progress over the decades, so too have W3C recommendations and open web standards produced measurable progress over the lifetime of the web. Without standards like CSS, the interoperability which the web depends on to thrive would not exist.
Yes CSS is broken - though semantically you cannot call it a 'broken standard'. But the question is not really one of semantics.
Experience of aiding in the definition of the UNICODE standard back in the late 80s and early 90s was good training for learning how to write a standard well. I have rolled my eyes so many times W3C write standards documentation that leaves immense holes in the definitions that lead to browsers interpreting things in different ways. There are many mutally exclusive parts to the CSS standard, even in v3, that have come about because we still have to keep compatibility with pre-CSS1.
On the critical side, CSS has three mind-bendingly obvious issues that any computer scientist will tell you are both improperly designed and inconsitent.
The Box Model - there are still huge holes in this even as CSS 3 approaches.
The 'specificity' calculations. 'specificity' was implemented to patch a hole in CSS standard and then later to try and shore-up the ever conflicting rules. If stylesheets are be truely cascading then 'specificity' needs to be scrapped. Until it is CSS should be called SWISMCCS (sometimes-when-it-suits-me-CSS). Of course, in order to scrap this feature all the remaining issues with loose language in the standards need fixing - which in reality means it will never happen.
Naming conventions for classes,selector etc allow the use of characters that are a problem for dynamic processing. The most obvious is allowing '-' symbol to be used in names. If you don't understand why I would encourage you to read up and bytecode compilers and compiler language parsing.
So the answer is the CSS standard is not broken, the premise is sound, but the implementation of the standards documentation (not the browsers, the documentation) shows how conquest by committee will rarely get you something fully fit for purpose.
I suppose this was because CSS was not created for trained programmers, it was created for web-designers - a strange breed who are not really programmers and not really designers. There are real web-developers who are different, but spend less time on pretty graphics.
IMHO: CSS is broken. On the other hand, the alternatives are much worse. Better the devil-we-know. Role on the replacement for HTML.
Developing websites are time-consuming. To improve productivity, I would code a prototype to show to our clients. I don't worry about making the prototype comform to the standard. Most of the time, our clients would approve the prototype and give an unreasonable deadline. I usually end up using the prototype in production (hey, the prototype works. No need to make my job harder.)
I could refactor the code to output valid HTML. But is it worth the effort to output valid HTML?
It is only worth the effort if it gives you a practical benefit. Sticking to standards might make it easier to build a website that works across most browsers. Then again, if you're happy with how a website displays on the browsers you care about (maybe one, maybe all), then going through hoops to make it pass validation is a waste of time.
Also, the difference in SEO between an all-valid html website and a mostly-valid html website is negligible.
So always look for the practical benefit, there are some in some situations, but don't do it just for the sake of it.
Yes. It's hard enough trying to deal with how different browsers will render valid HTML, never mind trying to predict what they'll do with invalid code. Same goes for search engines - enough problems in the HTML may lead to the site not being indexed properly or at all.
I guess the real answer is "it depends on what is invalid about the HTML". If the invalid parts relate to accessibility issues, you might even find your customer has legal problems if they use the site on a commercial basis.
Probably not if you have a non-complying site to begin with and are short on time.
However, and you won't believe me because I didn't believe others to begin with, but it is easier to make a site compliant from the start - it saves you headaches in terms of browser compatibility, CSS behaviour and even JavaScript behavior and it is typically less markup to maintain.
Site compliance (at least to Transitional) is pretty easy.
Producing compliant HTML is similar to ensuring that you have no warnings during a compilation - the warnings are there for a reason, you may not realise what that reason is, but ignore the warnings and, before you know where you are, there as so many, you can't spot the one that's relevant to the problem that you're trying to fix.
If you use Firefox to view your web pages, you'll get a helpful green tick or red cross in the bottom right hand corner, quickly showin you whether you've complied or not. Clicking on a red cross will show you all of the places where you goofed.
Some of the warnings/errors may seem a bit pedantic, but fix them and you'll benefit in many ways.
Your page is much more likely to work with a wider range of browsers.
Accessibility compliance will be easier (You'll have 'alt' attributes on your images, for example)
If you choose XHTML as a standard, your markup will be more likely to be useful in an AJAX environment.
Failure to do this results in unpredictability.
One of the biggest problems with web browsers is that they have perpetuated bad habits (And still do, in some cases) by silently correcting certain markup problems, such as failure to close table cells and/or rows. This single fact has resulted in thousands of web pages that are not compliant but 'work', lulling their developers into a false sense of security.
When you consider how many things there are that can go wrong with a website, being lazy when it comes to compliance is just adding more problems to your workload.
EDIT: having read your original post again, I notice that you say you don't bother with compliance when working on a prototype, then you go on to say that you usually use the prototype in production - this means that it's not strictly a prototype, but a candidate.
The normal situation in such circumstances is that once the customer accepts a candidate, no time is allocated for bug fixing or tidying up, thus strengthening the argument for making the markup compliant in the first place.
If you won't be given time later, do it now.
If you are given time later, then you had the time to do it anyway.
If you want your sight to be accessible to people with and without disabilities, as well as external systems, then yes, you should definitely make sure you output valid HTML.
It's easy to test your HTML with automatic validators.
I'll add to what Mike Edwards said about legal ramifications and remind you that you have a moral obligation too :)
Why not write the prototype in valid (X)HTML in the first place? I've never found that to be more of an effort than using invalid HTML. Producing valid XHTML should be a trivial task. (On the other hand, producing semantically meaningful XHTML might be more taxing.)
In short, I see no advantage whatsoever in using invalid HTML for prototypes.
I honestly dont know why it is extra effort to do standards based HTML. It's not as if it's hard and you should be doing it as a matter of professionalism.
If you paid someone to build you a house and he cut corners out of laziness, that you didnt notice at the time, but in 10 years cracks appeared in your walls, would you be happy?
Valid HTML just to be able to have a badge on your site - no.
Having "valid HTML" in the sense of "HTML that works on every major browser or browser engine" - yes.
Absolutely. Invalid code can cause all sorts of weird behaviors, and errors which don't obscure those that do when you get a validation report.
Case in point:
A yellow background was spilling out of a list of messages and over the heading for the next list of messages - but only in Internet Explorer.
Why? The background was applied to a list item, but the person who wrote the page had written it as a single list with a heading in the middle. Headings are not allowed between list items and different browsers attempted to recover from it in different ways. Internet Explorer ended the list item (with the background colour) when it saw the start of the following item (after the heading), while other browsers ended it when they saw the end tag for the first list item.
It was the only validity error on the page, so it took only a couple of minutes to track down the problem and fix it.
Because, if you stick to standards, your work will be compatible in the future. User Agents will strive for standard compliance and their quirks non-compliance mode will always be subject to change. This is the way is supposed to be.
Unless you're into that whole IE8 broken standards perpetuation thing that they want to enable by default. -- that's another argument.
Webkit, Gecko, Presto? (is that opera's engine?), and the others will always become more compliant with every release.
Unless your html work is in a IE embedded browser control, then there's really no reason to output valid html as long as it renders.
In my opinion the key criterion is "fit for purpose" - If your clients want something for a small/internal market (and don't care if that alienates potential customers who have disabilities or use less-common browsers) then that's their choice.
At the same time I think it's our (as developers) responsibility to make sure they know the implications of their decisions - Some organisations will be bound by legislative requirements that websites be useable by screen readers, which typically means standards-compliant HTML.
i believe making valid html outputs wont hurt your development time that much if you've trained yourself to code valid html from the start. for one, its not that hard to know which tags are not allowed within an elementand the required attributes in a tag are sometimes the ones you'd really need anyway - i believe these are the main errors that makes your html invalid, so why not just learn them as early as now if you plan to stay on the web for long?plus outputting valid html can help boost your sites ranking
There are two rules for writing websites:
The site must work for your users.
The site must work for your users.
To meet the first rule, you have to code such that your site renders correctly when using Internet Explorer. Unless you have the freedom to alter your site design to use only those features that IE renders correctly, this means writing invalid HTML.
To meet the second rule, you have to code such that your site renders correctly when using screen-readers and braille screens. Although some newer screen readers can work with IE-targeted sites, in general this means writing valid HTML.
If you're working on a small project, or you're part of a large team, you can code a site that outputs IE-targeted HTML for IE, and valid HTML otherwise. But if you're taking on a medium-to-large project on your own, you have to decide which rule you're going to follow and which one you're going to ignore.
UPDATE:
This is getting voted down by users who think you can always get away with valid HTML in IE. That may be true if you have the flexibility to change your design to get around IE's shortcomings, but if a client has given you a design and you have to get it working, you may have to resort to invalid HTML. It's sad, but it's true, whatever they might think.
Short version: What is the cleanest and most maintainable technique for consistant presentation and AJAX function across all browsers used by both web developers and web developers' end-users?
IE 6, 7, 8
Firefox 2, 3
Safari
Google Chrome
Opera
Long version: I wrote a web app aimed at other web developers. I want my app to support the major web browsers (plus Google Chrome) in both presentation and AJAX behavior.
I began on Firefox/Firebug, then added conditional comments for a consistent styling under IE 6 and 7. Next, to my amazement, I discovered that jQuery does not behave identically in IE; so I changed my Javascript to be portable on FF and IE using conditionals and less pure jQuery.
Today, I started testing on Webkit and Google Chrome and discovered that, not only are the styles inconsistant with both FF and IE, but Javascript is not executing at all, probably due to a syntax or parse error. I expected some CSS work, but now I have more Javascript debugging to do! At this point, I want to step back and think before writing piles of special cases for all situations.
I am not looking for a silver bullet, just best practices to keep things as understandable and maintainable as possible. I prefer if this works with no server-side intelligence; however if there is a advantage to, for example, check the user-agent and then return different files to different browsers, that is fine if the total comprehensibility and maintainability of the web app is lower. Thank you all very much!
I am in a similar situation, working on a web app that is targeted at IT professionals, and required to support the same set of browsers, minus Opera.
Some general things I've learned so far:
Test often, in as many of your target browsers as you can. Make sure you have time for this in your development schedule.
Toolkits can get you part of the way to cross-browser support, but will eventually miss something on some browser. Plan some time for debugging and researching fixes for specific browsers.
If you need something that's not in a toolkit and can't find a free code snippet, invest some time to write utility functions that encapsulate the browser-dependent behavior.
Educate yourself about known browser bugs, so that you can steer your implementation around them.
A few more-specific things I've learned:
Use conditional code based on the user-agent only as a last resort, because different generations of the "same" browser may have different features. Instead, test for standards-compliant behavior first — e.g., if(node.addEventListener)..., then common non-standard functions — e.g., if(window.attachEvent)..., and then, if you must, look at the user-agent for a specific browser type & version number.
Knowing when the DOM is 'ready' for script access is different in just about every browser. A good toolkit will abstract this for you.
Event handlers are different in just about every browser. A good toolkit will abstract this for you.
Creating DOM elements, particularly form controls or elements with attributes, can be tricky with document.createElement and element.setAttribute. While not standard (and kinda yucky), using node.innerHTML with strings that contain bits of HTML seems to be more reliable across browser types. I have yet to find a toolkit that will let you use element.setAttribute to add a 'name' to a form element in IE.
CSS differences (and bugs) are just as important as JS differences.
The 'core' Javascript features (String, Date, RegExp, Array functions) seem to be pretty reliable and consistent across browsers, especially relative to the DOM/CSS/Window functions. There's some small joy in the fact that the language isn't entirely different on every platform. :-)
I haven't really run into any Chrome-specific JS bugs, but it's always one of the first browsers I test.
HTH
Chrome is actually a little different to Safari, it uses a completely different javascript implementation and problems have been reported with both prototype and jquery. I wouldn't worry about it too much for now, it's still an early beta version of the browser and such inconsistencies will probably be treated as bugs. Here's the bug report.
One "silver bullet" you may consider turning to is Google Web Toolkit (GWT).
I believe it supports all the browsers you are interested in, and gives you the ability to code your UI in a Java-compatible IDE such as Eclipse. The advantage of this is you can use IDE tools for code completion and compile-time error checking, which greatly improves development on large-scale UI projects.
If you use GWT UI components, it will hide a lot of browser-specific nastiness from having to be dealt with, but when you compile, will create a compact, deploy file for each browser platform. This way you never download any IE-specific code if you are viewing the app in Firefox. You will also have a client-side stub generated which will load the appropriate compiled bundle of JS. To sweeten the deal, these files are cacheable, so perceived performance is generally improved for returning visitors.
The landscape has evolved considerably to accommodate cross-browser development. jQuery, Prototype and other frameworks exist for cross-browser Javascript. CSS resets are good for starting on a common blank canvas for all browsers. BluePrint and 960 are both CSS frameworks to help with layouts using CSS grid layouts techniques that seems to be getting very popular these days.
As for other CSS quirks across the different browsers, there is no holy grail here and the only option is to test you website across different browsers and use this awesome resource and definitely join a mailing list to save up soem time.
If you are working on high volume production site then you can use a service like browsercam.com in the end game to ensure the site doesn't break horribly in some browser.
Lastly, don't try to make the site look the same in every browser. Your primary design should target IE/FF and you should be okay with reasonable compromises on others. Use the graded browser chart to narrow in on browser support.
As for best practices, starting using wireframes on blank paper or a service like Balsamiq mockups. I am still surprised how many developers start with an editor instead of a wireframe but then again I only switched a year back before realizing how big a time saver it is. Have clean seperation of layout (HTML), presentation (CSS) and behaviors (Javascript). There should be no styling elements in HTML, no presenation in Javascript (use .addClass('highlight') instead of .css({'background-color': 'red'});).
If you are not familiar with any of the bold terms in this post, Googling them should be fruitful for your web development career and productivity.
If you're starting from a base reset or framework and have accounted for IE and it's still all freaky, you may want to recheck the following:
Everything validates? CSS and HTML?
Any broken links to an included file (js, css, etc?). In Chrome/Safari, if your stylesheet link is busted, all of your links might end up red. (something to do with the default 404 styling I think)
Any odd requirements of your js plugins that you might be using? (does the css file have to come before the js file, like with jquery.thickbox?)
For UI, check out Ext.
It's great as a standalone library, though it can also be used with jQuery, YUI, Prototype and GWT.
Samples: http://extjs.com/deploy/dev/examples/samples.html
I've found four things helpful in developing JavaScript applications:
Feature detection
Libraries
Iterative Development using Virtualization
JavaScript: The Definitive Guide, Douglas Crockford & John Resig
Feature Detection
Use reflection to ask if the browser supports the desired feature. If you want to know what event handling a browser supports, you can if(el.addEventHandler) for W3C compliance, if(el.attachEvent) for the IE-type, and finally fall back on el.['onSomeEvent'].
ONE BIG BUT!
Browsers sometimes lie about what features they support. I can't remember, but I ran into an issues where Firefox implemented a DOM feature, but would return false if you tested for that feature!
Libraries
Since you're already working with jQuery, I'll save the explanation. But if you're running into problems you may want to consider YUI for it's wonderful cross-browser compatibility. They even work together.
Iterative Development with Virtualization
Perhaps my best advice: Run all your test environment's at once. Get a Linux distro, Compiz Fusion and a bunch of RAM. Download a copy of either VMWare's VMWare Server or Sun's Virtual Box and install a few operating systems. Get images for Windows XP, Windows Vista and Mac OS X.
The basic idea is this: Compiz Fusion gives you 4 Desktops mapped onto a Cube. 1 of these desktops is your Linux computer, the next your Virtutual Windows XP box, the one after that Vista, the last Mac OS X. After writing some code, you alt-tab into virtual computer and check out your work. Plus it looks awesome.
JavaScript: The Definitive Guide, Douglas Crockford & John Resig
These three sources provide most of my information for JavaScript development. The Definitive guide is perhaps the best reference book for JavaScript.
Douglas Crockford is a JavaScript guru (I hate the word) at Yahoo. Lookup his series "Douglas Crockford Theory of the DOM", "Douglas Crockford Advanced JavaScript", "Douglas Crockford Theory of the Dom", and ""Douglas Crockford The Good Parts" on Yahoo! Videos.
John Resig (as you know) wrote jQuery. His website at ejohn.org contains a wealth of JavaScript information, and if you dig around on Google you'll find he's given a number of presentations on defensive JavaScript techniques.
... Good luck!
Just so you've got one less browser to worry about, Chrome uses the same rendering engine as Safari. So if it works in Safari, it should work exactly the same in Chrome.
See this post on Matt Cutts' blog.
Google Chrome uses WebKit for rendering, which is the same rendering engine as Apple’s Safari browser, so if your site is compatible with Safari it should work great in Chrome.
Update: Looks like this is now out-dated info. Please see Vox's comment on this answer.
If your very top priority is exactly consistent presentation on all the browsers listed with no disparities, you should probably be looking at AS3 and Flex.
Personally, I use Mootools as a simple lightweight javascript framework. It is simple to use and supports all the browsers above (except Chrome, but that seems to work too as far as I can tell).
Also, to ensure consistency across the browsers, I get a feature/style/behaviour/etc. to work in one browser first (usually Firefox 3 with firebug), then immediately check to make sure it works in all the other browsers (leaving IE6 for last). If it doesn't, I inveset the time to fix it right away, because otherwise I know I won't have time later (in my experience, getting things to work cross-browser takes about 50% of my dev. time ;-) )
Validating your javascript with a "good parts" + browser on JsLint.com makes it less likely to have JavaScripts behaving differently in FF, Safari etc.
Otherwise - using standards and validating your code as well as building on existing techniques like jQuery should make your site behave the same in all browsers except IE - and there's no magic recipe for IE - it's just bugs everywhere...
I've noticed a lot of sites, SO included, use XHTML as their mark-up language and then fail to adhere to the spec. Just browsing the source for SO there are missing closing tags for paragraphs, invalid elements, etc.
So should tools (and developers) use the XHTML doctype if they are going to produce invalid mark up? And should browsers be more firm in their acceptance of poor mark-up?
And before anyone shouts hypocrite, my blog has one piece of invalid mark-up involving the captha (or it did the last time I checked) which involves styling the noscript tag.
There are many reasons to use valid markup. My favorite is that it allows you to use validation as a form of regression testing, preventing the markup equivalent of "delta rot" from leading to real rendering problems once the errors reach some critical mass. And really, it's just plain sloppy to allow "lazy" errors like typos and mis-nested/unclosed tags to accumulate. Valid markup is one way to identify passionate programmers.
There's also the issue of debugging: valid markup also gives you a stable baseline from which to work on the inevitable cross-browser compatibility woes. No web developer who values his time should begin debugging browser compatibility problems without first ensuring that the markup is at least syntactically valid—and any other invalid markup should have a good reason for being there.
(Incidentally, stackoverflow.com fails both these tests, and suggestions to fix the problems were declined.)
All of that said, to answer your specific question, it's probably not worthwhile to use one of the XHTML doctypes unless you plan to produce valid (or at least well-formed) markup. XHTML's primary advantages are derived from the fact that XHTML is XML, allowing it to be processed and transformed by tools and technologies that work with XML. If you don't plan to make your XHTML well-formed XML, then there's little point in choosing that doctype. The latest HTML 4 spec will probably do everything you need, and it's much more forgiving.
We should always try to make it validate according to standards. We'll be sure that the website will display and work fine on current browsers AND future browsers.
I don't think that, if you specify a doctype, there is any reason not to adhere to this doctype.
Using XHTML makes automated error detection easy, every change can be automatically checked for invalid markup. This prevents errors, especially when using automatically generated content. It is really easy for a web developer using a templating engine (JSP, ASP.NET StringTemplate, etcetera) to copy/paste one closing tag too little or too many. When this is your only error, it can be detected and fixed immediately. I once worked for a site that had 165 validation errors per page, of which 2 or 3 were actual bugs. These were hard to find in the clutter of other errors. Automatic validation would have prevented these errors at the source.
Needless to say, choosing a standard and sticking to it can never benefit interoperability with other systems (screen scrapers, screen readers, search engines) and I have never come across a situation where a valid semantic XHTML with CSS solution wasn't possible for all major browsers.
Obviously, when working with complex systems, it's not always possible to stick to your doctype, but this is mostly a result of improper communication between the different teams developing different parts of these systems, or, most likely, legacy systems. In the last case it's probably better to isolate these cases and change your doctype accordingly.
It's good to be pragmatic and not adhere to XHTML just because someone said so, regardless of costs, but with current knowledge about CSS and browsers, testing and validation tools, most of the time the benefits are much greater than the costs.
You can say that I have an OCD on XHTML validity. I find that most of the problems with the code not being valid comes from programmers not knowing the difference between HTML and XHTML. I've been writing 100% valid XHTML and CSS or a while now and have never had any major rendering problems with other browsers. If you keep everything valid, and don't try anything too exotic css wise, you will save yourself a ton of time in fixes.
I wouldn't use XHTML at all just to save myself the philosophical stress. It's not like any browsers are treating it like XHTML anyway.
Browsers will reject poor mark-up if the page is sent as application/xhtml+xml, but they rarely are. This is fine.
I would be more concerned about things like inline use of CSS and JavaScript with Stack Overflow, just because they make maintenance harder.
Though I believe in striving for valid XHTML and CSS, it's often hard to do for a number of reasons.
First, some of the content could be loaded via AJAX. Sometimes, fragments are not properly inserted into the existing DOM.
The HTML that you are viewing may not have all been produced in the same document. For example, the page could be made of up components, or templates, and then thrown together right before the browser renders it. This isn't an excuse, but you can't assume that the HTML you're seeing was hand coded all at once.
What if some of the code generated by Markdown is invalid? You can't blame Stack Overflow for not producing valid code.
Lastly, the purpose of the DOCTYPE is not to simply say "Hey, I'm using valid code" but it's also to give the browser a heads up what you're trying to do so that it can at least come close to correctly parsing that information.
I don't think that most developers specify a DOCTYPE and then explicitly fail to adhere to it.
while I agree with the sentiment of "if it renders fine then don't worry about it" statement, however it's good for follow a standard, even though it may not be fully supported right now. you can still use Table for layout, but it's not good for a reason.
No, you should not use XHTML if you can't guarantee well-formedness, and in practice you can't guarantee it if you don't use XML serializer to generate markup. Read about producing XML.
Well-formedness is the thing that differentiates XHTML from HTML. XHTML with "just one" markup error ceases to be XHTML. It has to be perfect every time.
If "XHTML" site appears to work with some errors, it's because browsers ignore the DOCTYPE and interpret page as HTML.
See XHTML proxy that forces interpretation of pages as XHTML. Most of the time they fail miserably. This is one of the reason why future of XHTML is uncertain and why development of HTML has been resumed.
It depends. I had that issue with my blog where a YouTube video caused invalid XHTML, but it rendered fine. On the other hand, I have a "Valid XHTML" link, and a combination of a "Valid XHTML" claim and invalid XHTML is not professional.
As SO does not claim to be valid, I think it's acceptable, but personally if I were Jeff i would be bothered and try to fix it even if it looks good in modern browsers, but some people rather just move on and actually get things done instead of fixing non-existent bugs.
So long as it works in IE, FF, Safari, (insert other browser here) you should be okay. Validation isn't as important as having it render correctly in multiple browsers. Just because it is valid, doesn't mean it'll work in IE properly, for instance.
Run Google Analytics or similar on your site and see what kind of browsers your users are using and then judge which browsers you need to support the most and worry about the less important ones when you have the spare time to do so.
I say, if it renders OK, then it doesn't matter if it's pixel perfect.
It takes a while to get a site up and running the way you want it, going back and making changes is going to change the way the page renders slightly, then you have to fix those problems.
Now, I'm not saying you should built sloppy web pages, but I see no reason to fix what ain't broke. Browsers aren't going to drop support for error correction anytime in the near future.
I don't understand why everyone get caught up trying to make their websites fit the standard when some browsers sill have problems properly rendering standard code. I've been in web design for something like 10 years and I stopped double codding (read: hacking css), and changing stupid stuff just so I could put a button on my site.
I believe that using a < div> will cause you to be invalid regardless, and it get a bit harder to do any major JavaScript/AJAX without it.
There are so many standards and they are so badly "enforced" or supported that I don't think it matters. Don't get me wrong, I think there should be standards but because they are not enforced, nobody follows them and it's a massive downward spiral.
For 99.999% of the sites out there, it really won't matter. The only time I've had it matter, I ran the HTML input through HTMLTidy to XHTML-ize it, and then ran my processing on it.
Pretty much, it's the old programmer's axiom: trust no input.