So I'm using Dessandro's Masonry.js lib which was fully functional a short while ago, however, due to some unknown reason, it has ceased to function in both Safari and Chrome (can't speak to ie yet) but is still working fully in Firefox. If it were working in Chrome rather than Firefox I'd figure it was a css issue of some sort, possibly with transitions, but am at a bit of a loss as to where to diagnose this particular dilemma.
Masonry instantiation in coffeescript
window.presets = () ->
$(".table-header").hide()
$container = $(".employee-list")
window.msnry = $(".employee-list").masonry(columnWidth: 100)
showGrid msnry
loadImages $container
Well I suppose I feel a bit silly but it wound up being transitions. Masonry 'items' apparently will malfunction if adding transitions (no matter the type) onto boxes. I'm still at a loss as to why this would occur for Chroma and Safari but not Firefox so if anyone has any insight on the matter it would be much appreciated.
I'm using Raphael 2.1 to draw 15 lines at the same time. Each lines is made up of 50 2 pixel paths. Performance is best in Safari and Chrome, good in FF, weak in Opera, and chokes in IE9. Microsoft says that SVG will run in IE9, but Raphael.svg returns false in IE9.
I've been reading posts related Raphael and IE all day, and the only solution that I've seen for improving Raphael's performance in IE9 is to install Chrome Frame.
Has anyone encountered any other solutions?
Raphael uses svg in IE9 and work with reasonable performance. You have to be careful that IE is not being forced into IE8 standards mode (which frequently happens). If IE9 falls back to IE8 standards then it will end up using VML, which is very slow, and there is no efficient alternative to SVG in general in IE8 or below.
When faced with this problem using IE8 I ended up using divs and css to achieve rendering of lines, rectangles and text. Since that's all I required it was very fast even in IE8, helped out by buffering the divs inside the container. If your problem is simple enough, you may wish to consider a pure DOM solution. See: https://github.com/Matt-Esch/simpleCanvas.js for inspiration.
I'm hardly trying to find a good solution for creating smooth animations on mobile devices, especially on android.
First I found out that using javascript is no option -> android is SOO sadly slow with it
Then I found CSS-transitions -> android still horrible lagging
Then I found this script and seems to work fine (webkit transformation?)
Can you tell me how to do it right? Maybe there are better ways..
Also I don't really want to use a third-party script, even if it is lightweight.
android supports css transitions since at least version 2.1 http://caniuse.com/#search=transition
what are u exactly aiming at? what browsers, and on what devices are you testing? keep in mind that slowness could be happening because hardware and not software limitations
I'm using Raphael javascript library to make graphics.
I've almost copied the Analytics example from the webpage and I'm getting a white and black color graphic in internet explore and I don't know why.
Please see this is how it works on Firefox, Chrome and Safari:
http://imageshack.us/photo/my-images/861/75172783.png/
And this in InternetExplorer:
http://imageshack.us/photo/my-images/847/94131171.png/
Thanks!
Thanks for the Help.
However, I managed to fix the problem. I don't know why VML didn't like that Raphael object was inside a div with a "-".
This was my structure:
Simply taking the graphic outside the on-data div worked. Very weird actually!
Thanks!
From my answer to another Raphael/IE related problem:
Have you tried using Raphael 2.0? I think it's still in beta stage, but I found that it's got improved VML capabilities.
Also be sure to test browser behavior with an uncompressed version of Raphael, as minified versions seem to have bugs. Instead, I've used Packer by Dean Edwards, which gave me a compressed and bug free version of the lib.
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.