Develop Reference

Modernizr, html5shiv, ie7.js, and CSS3 Pie. Which to use and when?

I'm just starting to use HTML5 and CSS3 in my documents.
I understand the need for JavaScript to bring Internet Explorer up to speed with these new tags and styles, but I don't know which to use and when!
My plan was to use html5shiv and IE9.js to look after the HTML5 tags as well as the transparent pngs (and whatever other pesky errors they fix) but then Modernizr and CSS3 Pie were brought to my attention.
My question is, if I use Modernizr, does it look after my need for html5shiv as well as IE9.js? Or should I include these as well? What is the overlap, if any?
And what does CSS3 Pie do that Modernizr or the others doesn't? Or vice versa?
I appreciate your guys help. Let me know what you do!?

I've got extensive experience with all of these, having used them for a few years each.
Modernizr
Includes HTML5shiv functionality
Also does a lot more – if you don't use the other features, then don't use it, it does slow down page loads, but is worth it if you need it!
HTML5shiv
Very small, just fixes html5 elements in IE, nothing else.
CSS3PIE
Lets you use border-radius, gradients and box shadow in older versions of IE. Also can allow PNGs in IE 6. Adds a noticeable delay to page load.
ie7.js (and ie9.js)
Gives you many CSS3 selectors, min and max width, multiple classes and fixed positioning. Also can have a png fix if you like. Doesn't seem to slow things down much.
Conclusion
My advice would fall into two categories:
If you are just using the new (is 2 years new on the internet?!) elements, and CSS3 selectors, then use ie9.js + the html5shiv. This is lightweight, and just lets you get on with things without having to remember that IE6 doesn't support anything.
If you are using a lot of CSS3 stuff, then CSS3PIE will sort out border-radius and box-shadow. The gradient support seems a little flaky, so I've always used a fallback image instead. Modernizr lets you easily deliver different properties to browsers with different support. I've mainly used this for determining whether a browser has CSS transitions and transforms, as they are useful for any image sliders or content carousels. It's worth using the customisation tool to only include the functionality that you want – the webforms stuff shows a textbox with 50 in it for a couple of milliseconds, so it's worth disabling if you don't want it.
Hope that's helpful!

I would recommend you use only what you need. Build your app in a browser that supports the features you are using, and periodically test in other browsers that you support. If something isn't working correctly, find the appropriate fix, whether it be html5shiv, IE9.js, Modernizr, or CSS3 Pie. You are not going to use all of the new features in HTML5 and CSS3 all in one page, so you don't need to include every polyfill library in existence. Wait until you find problems with the features you're trying to use, then try and find the library necessary to do that.

I've used mainly CSS3Pie...it works great. But this afternoon i tested it on my laptop with I.E8 and there was an problem with it...it was disabling some css lines...when i removed the css3pie code my site gained twice the speed...then i came accross the posts with people arguing about the css3 slowdown...So at the moment i'm busy to find another way for IE7 & IE8 to have border-radius and shades.
If you want to use it...please test alot as it is NON-official fixes

building a wysiwyg editor

I need to build a wysiwyg editor for a project I am working on and need some guidance. Some of my key points of confusion are the following:
iframe docs vs. contenteditable divs: which one should I use and why? I hate iframes, is there a clear advantage to using iframes?
cross browser styling: execCommand seems to apply different styles in different browsers. Are there any tricks to making this cross-browser compatible? Should I not use execCommand at all and instead apply my own styles?.
adding items to the undo chain: how can run my own script, such as inserting an image, and allow cntrl+z (undo) to remove it? Is there an array of undo/redo items for contenteditable that I can push items into?
keeping the text selection: how I can maintain text selection while making operations such as selecting the font style, where the focus will leave and remove my selection. Rangy? Google closure? Are there other range/selection libraries worth looking at?
Any tips on these items or anything else related to building a rich text editor would be greatly appreciated!

From personal experience, I recommend against doing this unless your aim is to provide a very limited amount of functionality. The sheer number of browser differences and the complexity of their workarounds makes this a very tricky and time-consuming task if you want to do it well.
If that hasn't put you off, here's my thoughts on your individual questions:
iframe docs vs. contenteditable divs
I recommend the iframe approach, for two main reasons:
You have complete control over the document type, CSS and script within the iframe. This is essential if you want consistent behaviour and appearance and want to use your editor within different pages.
Firefox in particular is quite buggy with contenteditable elements, which they only introduced relatively recently (version 3.0) while designMode has existed on documents for many years (since pre-1.0; around 0.6, if memory serves) and works pretty well.
cross browser styling
If it's important for you to have uniform results from applying styles in different browsers then in general you will need to write your own styling code. However, doing this will break the built-in undo stack and you will need to implement your own undo/redo system.
adding items to the undo chain
There's no programmatic way to interact with the built-in browser undo stack. You'll need to write your own.
Update November 2012
There is a spec in the works for custom undo/redo so this is likely to be possible eventually. Here are the relevant bugs for Mozilla and WebKit.
keeping the text selection
I have to declare my interests here, since I wrote Rangy. I don't think there's a better library out there that does a similar job; Google Closure does have a range/selection API but I think it uses their own proprietary interface rather than emulating DOM Range and common browser Selection objects. IERange is another library that is similar in idea to Rangy but much less fully realized and seemingly abandoned immediately after release by its author.

Don't, seriously don't.
What you are suggesting is a major undertaking. You really should be looking at TinyMCE, http://tinymce.moxiecode.com/, or CKEditor, http://ckeditor.com/. Getting what you are after is a massive amount of effort to get working for one version of one browser, to make it portable will take man-years of investment.
A better solution is to look at things like TinyMCE's plugins, http://tinymce.moxiecode.com/plugins.php. You can get your basics the basics (and portability for free) and concentrate on adding the specific value-add items you need to.

Anti-aliased text with css/javascript for Large font size?

I am using Large fonts in my website at a few places and they don't appear anti-aliased or smooth... I was wondering if their is any way to show large anti-aliased fonts for browsers on windows OS which has anti-aliasing switched off as default... Similar to something they have on this website here

You can't control system anti-alias in CSS.
For that, you would have to use Flash text replacement, like sIFR (they are using h2swf)

If the user's OS or browser does not have anti-alias switched on, there's nothing you can do to force either to use it. You can use other rendering platforms like Flash, or using CCS to replace text with images, to allow fonts to be displayed with anti-aliasing, but it does seem like a kludge for something as simple as rendering text. Technologies like Flash will also alienate certain audiences, either whose devices have no support for them or they simply opt out of using them.
If your user does not have AA enabled, arguably they are displaying a preference or simply don't care about the particulars of how the font is rendered. At the end of the day, you simply cannot directly control the client your users will use to consume your website. On the web you will always be at the mercy of the client application. The best you can do is present it clearly and in such a way that it should be easy for users to get the best experience they can achieve with their client.
Don't lose any sleep over whether your pixels are slightly less pretty on one client.

Cufon is an alternative to sIFR. See comparison here:
http://net.tutsplus.com/tutorials/html-css-techniques/six-ways-to-improve-your-web-typography/

Good news : in IE9 (released 3/14/11) they seem to put much larger text as anti aliased by default. I have hardware acceleration disabled - so it probably has this effect for all users.
Warning: this is an exercise in futility but....
I did notice that the text-shadow css property seems to force anti aliasing in some browsers. Unfortunately I think only Chrome at this time...
Here's a sample...
(each heading is shown first normally - and then with a text shadow).
Best viewed in Chrome!

What Cross-Browser issues have you faced? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
While developing for multiple sets of browsers, what issues have you faced while development due to differences in browser implementation?
To start with I am listing some of those which i faced:
A text node in Firefox allows only 4K data. So an XML Ajax response gets split up into multiple text child nodes instead of only one node. Its fine in Internet Explorer. For Firefox, to get the full data you either need to use node.normalize before you call node.firstChild or use node.textContent, both of which are Mozilla specific methods
Internet Explorer does not replace or HTML char code 160, you need to replace its Unicode equivalent \u00a0
In Firefox a dynamically created input field inside a form (created using document.createElement) does not pass its value on form submit.
document.getElementById in Internet Explorer will return an element even if the element name matches. Mozilla only returns element if id matches.
In Internet Explorer if a select box has a value not represented by any of the options, it will display blank, Firefox displays the first option.

The only one that really gets to me:
IE6 is still used by ~18% of the web -- that's nearly 1 in 5 -- and addressing its issues is time consuming, hackish, and frustrating. ;) The issues are really too numerous to list here.
If you're interested in the issues themselves, QuirksMode.org is an amazing resource I used every day before making the leap to client-side libraries. Also check out John Resig's The DOM is a Mess presentation at yahoo, which gives a lot of theory about how to deal with cross-browser topics efficiently.
However, if you're interested in simply having them solved, your question is an excellent example of why many consider using client-side libraries like jQuery, YahooUI, MooTools, Dojo, etc. With a thriving community, talented people and corporate backing projects like those allow you to focus on your app rather than these issues.
Here are some jQuery examples that avoid much of the cross-browser frustration and can really make all of this.. fun.
Cross-browser mouse click binding
$('#select anything + you[want=using] ~ css:selectors').click(
function(){
alert('hi');
}
);
Cross-browser HTML Injection
$('#anElementWithThisId').html('<span>anything you want</span>');
Cross-browser Ajax (all request objects are still made available to you)
$('p.message').load('/folder/file.html');
And what really blows me away, load a data subset with selectors (see manual for details)
$('p.message').load('/folder/file.html body p:first-child');
Now, how all this really starts to get fun: chaining methods together
$('ul.menu a').click( // bind click event to all matched objects
function(evt){ // stnd event object is the first parameter
evt.preventDefault(); // method is cross-browser thx to jquery
$(this) // this = the clicked 'a' tag, like raw js
.addClass('selected') // add a 'selected' css class to it
.closest('ul.menu') // climb the dom tree back up to the ul
.find('a.selected') // find any existing selected dom children
.not(this) // filter out this element from matches
.removeClass('selected'); // remove 'selected' css class
}
)
Reminds me of Joel's Can Your Programming Language Do This? article.
Taking all this to a theoretical level, true advancement doesn't come from what you can do with conscious thought and effort, but rather what you can do automatically (without thought or effort). Joel has a segment on this in Smart And Gets Things Done regarding interviewing questions and smart developers, completely changed my approach to programming.
Similar to a pianist who can just 'play' the music because she knows all the keys, your advancement comes not from doing more things that require thought but rather more things that require no thought. The goal then becomes making all the basics easy.. natural.. subconscious.. so we can all geek out on our higher level goals.
Client side libraries, in a way, help us do just that. ;)

Most of the problems I have are with IE, specifically IE6. Problems I personally deal with that have left a memorable impression (in no particular order):
Having to use frameworks to do basic things because each browser implements the DOM a little differently. This is especially heinous with IE and AJAX, which necessitates multiple if-blocks just to get the call started. In an ideal world I'd be able to work in JavaScript without the framework to do basic things.
onChange on selects in IE are implemented wrong, and fire before the select loses focus (which is incorrect). This means you can never use onChange with selects due to IE, since keyboard-only users will be crippled by this implementation issue.
You mentioned it in your post, but it's a huge pain when IE grabs an element by name when using getElementById().
When in an RTL locale (Arabic, Hebrew, etc.), Firefox implements "text-align: right;" incorrectly. If the container overflows for some reason, the text aligns to the right side of the viewable container, rather than the right side of the container itself (even if it makes part of it invisible).
Different browsers have differing levels of pickiness with regards to how you end arrays and objects. For example, Firefox is more than okay with an array looking like this: [ item0, item1, ]". However, this same code will make Opera barf because it hates the trailing comma. IE will make the array a three-item array, with the third item undefined! This is bad code for sure, but there's been dynamically generated javascript I've worked on that was a huge pain to rewrite - would've been nice if this just worked.
Everything having to do with IE's hasLayout. So much awful pain has revolved around this attribute, especially when I didn't know it existed. So many problems fixed by using hacks to add hasLayout. So many more problems created as a result of the hacks.
Floats in IE rarely work the way you hope they do. They also tend to be annoying in other browsers, but they at least conform to a particular behavior. ;)
IE adding extra white space between list items has caused me no end of pain, since YUI uses lists to make their menus. (To fully grasp the issue, you have to view that link in IE and another browser side by side.)
I have lots of issues getting text not to wrap in containers in IE. Other browsers listen to "white-space: nowrap" a lot better. This has been a problem with a UI I worked on that has a resizable sidebar; in IE, the sidebar items will start to wrap if you resize it too much.
The lack of many CSS selector types in IE6 means you have to class-up your DOM more than necessary. For example, the lack of +, :hover, :first-child.
Different browsers treat empty text nodes differently. Specifically, when traversing the DOM with Opera, I have to worry about empty text nodes when browsing a node's children. This isn't a problem if you're looking for a particular item, but it is if you're writing code that expects a particular input and the way the browser views that input differs.
In IE6, when you dynamically generate an iframe via javascript, the iframe sometimes doesn't fill its container automatically (even with width and height set to max). I still don't know how to solve this issue, and have been thinking of posting a question about it.
In IE, you can't set overflow CSS on the <tbody> element. This means that scrollable tables (with a concrete <thead> and <tfoot>) are impossible to make in a simple manner.
I will probably add more to this list later, since (to me) the worst part of web development are cross-browser issues. Also, I doubt I'll ever edit out the "I will probably add more to this list later", since these problems are endless. :)

IE6? Meh. You guys have got it easy! You've never had to make CSS layout work in Netscape 4 (without crashing the entire browser)? You've never had to write for appliance browsers that don't support tables? You've never had to write for IE Mobile?
there is no support for JavaScript-assigned event handlers; you can only write an event handler through setting “onclick="somestring"” in innerHTML;
most basic DOM Level 1 properties (eg. nodeName, nodeType, nodeValue, firstChild, lastChild, nextSibling, previousSibling, data, value, HTMLElement.getElementsByTagName, all HTMLTableElement members, most CSSStyleDeclaration members) simply do not exist;
most CSS layout properties do not work; many simply CSS properties like ‘width’ don't work on some elements such as form fields;
setting many other CSS properties on elements like tables and form fields causes an instant browser hang, which, since Windows Mobile has no built-in task manager, means you have to soft-reset the device;
oh, and putting anything but text inside a <button> is insta-crash too;
huge chunks of basic JavaScript methods and “DOM Level 0” methods going back as far as Netscape 2 (!) are missing.
And this is the most up-to-date release of Microsoft's flagship Windows Mobile browser in 2009.
Sure, it supports XMLHttpRequest, but writing AJAX code on a browser whose CSS and script support is less than IE3 (!) is bizarrely schizophrenic, like you're working with a weird amalgam of 21st-century and 19th-century technologies.
I wouldn't recommend it.

Been doing this too long to have many problems, but it still drives me nuts that I have to hack around IE's non-support for CSS things like display:table, :last-child, and :hover outside of anchors.
All the IE stuff is still insane, but it's just background insanity now :)

Biggest Cross-Browser Issue? - Internet Explorer!
<start_grumpy>
IE is solely responsible for "holding back the web" - us developers can't create amazing sites using HTML5, or SVG, or XFORMS, or CANVAS... not because of Firefox,Safari or Chrome, but because 2/3s of the Internet is still stuck on IE. Not to mention that ~20% of the web is still stuck on IE6! IE8 is the first version of IE to at least try to be standards compatible (2001's standards that is), which means it will be at least 2018 before we can finally start dropping all support for IE7.
</start_grumpy>
Otherwise name a DOM method that IE fully supports... the fact that this is a hard question to answer is my biggest CrossBrowser issue.
getElementById() - badly broken
getElementsByName() - buggy
getElementsByTagName() - buggy
getAttribute() - buggy
setAttribute() - majorly broken
createElement() - buggy
appendChild() - buggy
even things IE invented are messed up...
innerHTML (getting) - returns the worst markup possible
innerHTML (setting) - doesn't work on the elements you'd want to dump a bunch of data into (e.g. Tables and Selects)

While developing a system tests framework for a web app we had to simulate various events such as clicks. I remember that we couldn't find any normal way to do it in IE and FF and had to implement it in two different ways with a lot of voodoo around.
I don't remember the specifics, but I remember that it was really annoying.

This, basically.
Modern javascript frameworks (jQuery, prototype, etc) have done wonders for getting code working in lots of browsers at once.
The biggest problem I have now is the fact that any sort of rich UI behaviour runs amazingly slowly. IE7 is bad. IE6 is worse. IE8 is buggy, half finished, and really no better than IE7.
The worst thing is that I don't think we'll ever be free of IE6. It was so ubiquitous, and so damn quirky. Loads of 'enterprise' (and by that I mean big web apps made by one big company for another big company) applications used highly specific IE6 javascript that doesn't even work in IE7, never mind anything else.
Companies can't afford to completely replace these apps - we're trying to sell them new ones and that means IE6 support is mandatory. The way it is right now, with credit-crunched companies cutting costs, I reckon we'll still be supporting IE6 in 2015 :-(

In internet explorer (note: older versions of IE, not necessarily versions 9/10+), if you create form elements using document.createElement, the field won't be submitted with the form. The only workaround is to use
element.innerHTML = "<input type='text' value="+val+" name="+name+">";

In IE, you can not hide select option elements, only the select element itself. This makes it difficult to dynamically change the contents of select options using Javascript.
This problem also exists in Safari and Chrome.
There are many other issues with IE, but this one has caused me the most frustration recently.

IE's restrictions on using DOM manipulations on tables forced me to take a completely different approach to something. Very frustrating at the start, but the positive out of it was that the second approach was ultimately better, so I suppose I should be grateful to IE. ;)

For Firefox, to get the full data you either need to use node.normalize before you call node.firstChild or use node.textContent, both of which are Mozilla specific methods
Actually all of those are W3C DOM methods supported by the vast majority of browsers. I think you'll find they also work in IE.
My biggest cross-browser issue is that there are people out there still using IE.
Second biggest is that even in standards-following browsers, doing some things in CSS is still impossible; for instance tbody {overflow:auto} does nothing useful in anything but Gecko, and even there it has bugs.

Firefox and IE ahve different table setups in the DOM, in one, all siblings of a cell are the other cells, whilst the other has elements between the cells. I can't remember which way around it is, but it gave me a real headache in one application.

My biggest problem are browser makers. Arrogant little *^&%s. I mean, you can't sell a browser to anybody, yet everyone is in their little corner trying to out do each other, only creating division. Oh and Chrome. Chrome still doesn't know what it wants to be, Safari or Firefox. Aside from its one parlor trick, its practically useless. I blame all you guys who kept googling just because you hate monopolies. Guess what, they're the monopoly now. Now we can all enjoy second rate, prematurely launched software.
This mostly stems from a bug* I had in Chrome today, it never dawned on me to query the browser. Both Safari and Chrome were failing so I figured hey, once I fixed the Safari problem Chrome would be fixed automatically, but oh no no. Mr."I run tabs in seperate processes" AKA "Sr. No full screen" just had to hold me in the lizard lock with its mind boggling implementation.
I also detest Firefox. I can't tell whether I have a virus infestation or Firebug running. Now until Adobe decides to release a browser that makes Flash practical for things other than movie clips I'm pretty much going to have something to bitch about for a long time. And we all know that's what life is all about.
Also, I only enjoy programming when I encounter ridiculous bugs that make my brain juices run.

Inconsistencies in the CSS box model when dealing with forms. In particular it's irritating how each browser handles the <select> Box

my only nightmare is IE6 you should always look for hacks but everytime you face a problem with it there is someone who ran into it before you and blogged about it (and we will never get away from it )

I was working on CSS layout written by someone who thought that the size given to an element is size+padding+border like in IE5 and not only the content box as explained in official specification. It was written only a few month ago so he did dirty hacks to make it look well in IE7. It took me several hours with FireBug to track down the source of the problem and by the time I realized it I was really annoyed.
If you open site with "floating" CSS written for IE5 in Firefox the boxes just do not have enough space to fit and fall down the page. If you open it in IE7 it looks nice as IE7 lets the borders overlap so it looks almost correct. For someone as inexperienced as me it was hard to note.

To remove iframe borders in Internet Explorer you have to specify the frameborder attribute as camelCase format, which is non xhtml compliant.
<iframe frameBorder="0"/>

An easy way to help with the pesky IE display issues is to use firebug, Yep enen in IE 6/7/8 Just use Firebug Lite
If you add the following as a bookmark and stick it on your tool bar it will enable firebug lite off any webpage with a single click. (only check this in IE and it works fine.)
javascript:var%20firebug=document.createElement('script');firebug.setAttribute('src','http://getfirebug.com/releases/lite/1.2/firebug-lite-compressed.js');document.body.appendChild(firebug);(function(){if(window.firebug.version){firebug.init();}else{setTimeout(arguments.callee);}})();void(firebug);

How are programmers tackling ie6 bugs these days?

I have been using dean edwards ie7/8 script. Not sure if it's my implementation or not but sometimes I would experience ie6 issues that weren't quite fixed or required special handling which meant I would be back where I started, caring about ie6. So, I was wondering if ie7/8 is still the go or if some other practice/solution was better.

Update: I expanded my answer here with a tutorial on my site, which will probably be more helpful than my answer here. Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs
Here's how I tackle IE6:
I validate both my XHTML and CSS.
I keep my designs simple, even the complicated ones.
I don't use hacks that invalidate my
CSS.
I use a JavaScript framework/library
(I like MooTools, but you'll get a
lot of votes for jQuery, Prototype,
YUI, Dojo, and many others) that
handles most of my cross-browser
JavaScript problems.
I progressively enhance my pages so
that they first work without
JavaScript and then add all the bells
and whistles.
For some of the double margin
problems, I use display:inline;
If I absolutely have to, I use a
separate stylesheet, though I'm
finding I have to do this less and
less.
I try to avoid transparent images in
my layouts. If I absolutely need
them, I use a PNG8 with alpha
transparency, which IE6 actually does
support.
To get at the min-height problem, I
do the following:
This for IE6, which interprets height as min-height:
.classNameHere {height:300px;}
This for for everything else:
div>div .classNameHere {min-height:300px; height:auto;}
Incidentally, if you need to isolate IE6 with CSS, that's a good way to do it, as it doesn't support child selectors.

I try not to support IE6

YUI reset and YUI grids have allowed me to keep my sanity when support IE6.
IE 6 is an "A-grade" browser, which means that bugs and errors get priority.

I'm using:
"Reset.css" to minify the difference between the browsers default CSS computed styles (e.g. YUI reset.css)
Conditional Comments to put additional css file into the scope ;) (e.g. ./ieFix.css)
W3C Validator to tell if the difference in rendering is caused by bad nesting or it's just IE ;)
if that fails, jQuery helps a lot ;)

To be completely honest, I don't really handle IE6-issues much lately. My design-process is simple:
Reset margin/padding on everything. I mean everything.
Test my page layout every few minutes. Takes one tap on F5.
If any change breaks the page, I stop everything and evaluate the change.
If the desired method cannot be used, I research alternative methods, excluding 'hacks'.
I validate both markup and css. And always use XHTML 1.0 Strict.
I make sure my site works first without Javascript, and then later use jQuery.
These basic practices have kept me from having to work around IE6 issues a lot over the years. The only issue I still get upset over is IE6's support for PNG24 with Transparency, but IEPNGFix takes care of those - usually without breaking my layouts too.
It may be the opinion of a foolish man:Great developers don't find complaints, they find solutions.

Conditional comments, patience and sometimes ie7-js.

I agree with the responses that talk about a process involving clean code, conditional comments, keeping ie6 happy but not perfect, etc etc. But it's a very cautious, little by little process which is still, at the heart, quite time consuming when really it's all for one browser.
I am reluctant to tick any response as answered because all the responses talk about existing methods I am familiar with. It may be that my question is answered "No" :) because essentially I was after a framework that meant you didn't even have to worry about ie6's nuances, just code in a modern way - something I thought ie7/8's js would do but even just today I realise that min-height isn't being fixed!!.
Thanks anyway for the replies - it's helped re-enforce that my approach is still the status quo and I am using my time as efficiently as I can.

I instituted a policy recently with regards to IE6, basically, as long as it does not break the site on IE6, don't spend time on it.
I don't think IMHO, that IE6 still has enough use to make it worthwhile for my company to continue spending money fixing small issues with it.
Here is a quick sample of data from several of the sites that my company has tracking data on. This is a combination of recent data (today) and some data from about 1 year ago, so there is a higher percentage of IE6 than we actually get now, and even then all but 3% of the hits are to 1 of the 8 sites included in the data.
alt text http://unkwndesign.com/browerUsage.png
**Note Chrome is built on webkit but its numbers are not included in webkit, just to show how fast it has grown. The total percentage is 100.5% because of rounding.

I don't think there is ever a standard as to what browser you can or can't ignore. It depends on the organization -- or the audience in the case of your start-up. Any JS you write should "gracefully degrade" but making sure that actually happens requires some artfulness at times.

There is really just one "fix" for IE-problems which is to help facilitate its suicide. The only way I've discovered to help IE commit suicide is to educate my visitors. This can be done by sniffing the browser and if IE is detected you display a "help upgrade the web" banner.
Kind of like GMail does...
We're doing this at ra-ajax and stacked (visit the site with any versions of IE)

Build for firefox first, nuke or downgrade design elements experience tells you IE6 can't handle at the outset, and not spend more time than the client spec warrants
TBH experience is the #1 preventative measure for IE6 problems

Make it work in Firefox;
Check to see if it looks and works the same in IE7;
Check to see if it sorta works in IE6 (because that's good enough).
If you can't do the layout with simple CSS (no crazy relative+absolute positioning or float:after fixes) then just do it with tables;
Put a DOCTYPE in to force the browser into compliance (rather than quirks) mode;
Minimize box model issues by minimizing the use of contained borders (or by giving invisible borders to other similar elements) and nesting elements to minimize padding/margin/border combos, which will just cause you grief;
Don't bother trying to get a CSS menu to work across all browsers. It isn't 2003 anymore. Just use Javascript (eg jQuery/superfish).
Only use :hover on links. If necessary change them with display: block.

Kill ALL default styling before starting.
Throw Dean Edwards script at it.
If problems persist to tell users to upgrade.
If IE6 is vital, use an IE stylesheet that removes whatever doesn't work and replaces them with less complex styles.
jQuery :hover etc. to .hover, input[type=submit] to input.submit etc. Helps with older versions of FF and Opera aswell occasionally.

I've decided yesterday to not support it anymore. There's a movement starting trying to kill IE 6.
Thanks to IE's conditional comments it's easy to show a message for just those users.

I build it for Chrome, then I optimize for Firefox most of the time its just little things then I go into IE 8 and then I go into IE 7 since most bugs I will have eliminated by then. After IE 7 I take a brief look at Opera and am finished for the day. Who cares about IE 6 anymore?
Are you complaining to the Intel manufaturers that the cpu doesn't fit into your comodore? There are technology advancements and I think IE 6 should be killed the best way to do that is to tell the the user he has to upgrade and let the site look like crap thats the only way to force them to switch. Some will eventually ask their children why the internets are broken and then the son will come along install all updates and the mom or dad can be happy again.
My answer in short: No more optization at all is how I handle it.

By encouraging users to upgrade to something—ANYTHING—better.