In case you weren't already aware, Microsoft provides free images of XP and Vista with IE 6, 7 and 8. You have to get a new image every few months but they work great for making sure this doesn't happen. Only takes a few seconds to boot up the virtual pc and check your layout and functionality.
But last I tried to use them (a month or so ago) they no longer work in anything other than MS Virtual PC. VirtualBox, VMWare, etc wouldn't work. So, now you need to be on a Windows PC to use their images.
Super Preview sucks - its basically an app wrapped around a service like browsershots.org. All you get are flat screenshots, which isn't enough.
You're going to need to find a way to test on a real version of the app. Xenocode(.com) used to have sandboxed versions of all the browsers available, which was perfect, but they've since removed the page. So now the images provided by MS (referenced in parent) are your best best.
Unfortunately they now require a plugin and launch from the web, they used to offer an exe of each browser you could download. Its too bad, was one of the best tools available for browser testing.
Ah - I'd always used the browser launch version, I wasn't aware they had .exe downloads.
I still think it's invaluable - rather than setting up three separate VMs, I can just have one on IE6, and launch 7/8 as needed (I usually just save-state at that point so I'm not constantly launching them).
What about running virtual pc from my parallels xp virtual machine? Two levels of indirection might kill my performance but should be ok to just test basic sites.
I tried this with VMWare Fusion on a Mac running XP and couldn't get the MS VirtualPC images to work. Anyone have success running VPC with these test images in a VM (VirtualBox, Parallels, Fusion?) on OS X?
Unfortunately the images from the site have activation issues because they see it as being installed on new hardware, someone from MS posted on the VirtualBox forum suggesting an email to see if the demand was high enough and I guess it hasn't reached that point yet. http://forums.virtualbox.org/viewtopic.php?f=2&t=21712&#...
For my own system I used MSDN to get working installs of XP on my Mac in VirtualBox.
You also need to convert the VHD to VDI. I've done this on Mac using Q (http://www.kju-app.org/) and these simple commands.
/Applications/Q.app/Contents/MacOS/qemu-img convert -O raw -f vpc "input.vhd" temp.bin
That sucks. I'm not sure how the images are supposed to expire - I'm using year old images in VirtualBox and while I occasionally get messages saying Windows cannot be authenticated I'm still able to use them.
To prevent that in he future:
1) Test in all browsers you are supporting
2) Learn about <input type="img"…>
BTW article linked in OP suggest you can use any format for the image, and suggests .jpg. This is very bad choice—save jpegs for larger photos, this format does not work well for icons/buttons, PNG (preferred) or GIF would be much better option.
There's really no excuse for not testing in all browsers but I can understand the impulse to "get the change out the door" too.
For myself I tend to iplement a change in a separate file and leave the old page in place. Then as I test each browser I use the browser ID to redirect people to the changed page as I test their browser. Then when I'm done I replace the old page and remove the redirect.
It sounds strange but I've found it's a good way to get changes out as soon as possible while not risking what happen to the author here.
The excuse for not testing on all browsers is that its incredibly time consuming. It also requires you to be at your main workstation that has all those test VMs.
I'm not affiliated with them in any way, they've just made my one of my jobs much easier for not much money, and they hang out on HN sometimes besides.
Not sure if you have tried the new bookmarklet we released, but it changes the way you interact with the service. In two clicks (click on the bookmarklet, click on the browser / platform you want to test in), the page you are currently viewing is launched in the remote configuration and the browser is opened to your current page. It really improves the work flow. You can read more about it at http://crossbrowsertesting.com/blog/new-cool-bookmarklet.
Appreciate the plug!
Tony
Founder - CrossBrowserTesting.com
Others: Adobe BrowserLab and LitmusApp. BrowserLab is fast and free. LitmusApp is much slower and costs us $49/month but it has some advantages - it has a good series processing UI, it links to w3c html and css validation results, and it doesn't crop the bottom of the page.
3) realize that even in the absence of <input type="img"…>, if you are doing things like:
"...the HTML input element had a background image specified and a text-indent:-9000px property applied to it, which puts the standard text for the button way off the screen, leaving only the background image visible."
then you're doing it wrong. What the hell?
Also regarding the PNG/JPEG rule of thumb, it should be: JPEG for photographic images, PNG or GIF for everything else on the web. Large doesn't and shouldn't necessitate JPEG. Then you end up with ugly, artifacted, JPEG screenshots, and these already exist aplenty.
I think you failed to recognized what's wrong with the section I quoted. Negative text indent is fine. Negative text indent for the purposes of "[putting] the standard text for the button way off the screen, leaving only the background image visible," is a ridiculous misuse of that CSS property.
The versatility of the <button> element is really remarkable, and it works fine in all browsers. I highly recommend anyone currently using <input type="submit"> to change to <button type="submit">
I recommend just staying away from the button element unless you are really careful now and in the future. I started using it a couple years ago almost exclusively and quickly ran into problem #1 below and not until just recently #2 which probably resulted in a lot of bugs that just never got reported or we just got lucky.
1. IE does not honor the value attribute of the button tag, rather it submits the button html content as the value.
2. IE6 passes ALL button elements to the action page of the form, not just the one clicked.
There are javascript onsubmit hacks to work around both of these issues but it is just really annoying to have to do so, and easy to over look. It might work fine at first with one button but then you add a second or rely on the button value a year later and don't test in IE6 and you are screwed.
The button element has some issues with what it submits as its value, which might not be a problem if you're using it as a substitute for a single submit button in a form, as in this case, but it's still worth noting.
About a year ago a blog post dissecting a minor-but-critical bug on my site was pretty popular here. ( http://news.ycombinator.com/item?id=383108 ) I discovered another one today, which was so frustratingly infuriating (mostly at myself) that I had to write about it, if for no other reason than to keep pulling my hair out.
The beauty of IE is that once you've found a bug, there's nothing you can do about it. I gave up trying to bring the bug I stumbled across - http://crashie8.com/ - to Microsoft's attention after I kept hearing "oh, your HTML isn't valid."
grumbles about Netscape letting go of its mantle...
Ouch. I sympathize with the author -- various CSS quirks have cost me an awful lot of time and money over the years.
I'm currently solving this with two approaches:
First, use crossbrowsertesting.com -- they are really great people, I was among their first users, they keep improving their site and service, it's easy, and for the money it's absolutely worth it. Every time I make changes to my libraries which might even possibly be handled differently by different browsers, I log in to CBT and test the browsers. (I've found the best order to be FF -> Safari -> Chrome -> IE 8 -> IE 7 -> IE 6; usually by the time I get to IE 6, everything's working OK.)
Second, stop using CSS for (fancy) layout. It wasn't really intended to do it, and I don't expect CSS3 support to fix the usual problems I have with CSS2. So, one of my more recent projects is a simplified layout language parsed in JavaScript that makes certain things very easy. It's also very fast.
If you don't want to set up Selenium yourself, you can use http://saucelabs.com/, which does it in the cloud for you. hugs (Jason Huggins) pops up here on HN from time to time, as well.
Scripted client testing isn't a panacea. A while back we had a similar IE6-only issue which thankfully lasted only a day before we noticed the metric dip.
A push button was, in IE6 only, positioned behind an image with a higher z-index. The (Watir) automated test worked fine, because the button was there and a scripted event could hit it. But human users couldn't see it.
Thanks, that looks like exactly what the doctor ordered. It will still take me a while until I a) understand Selenium well enough to use it productively and b) can write a comprehensive test suite for the high-value customer-visible stuff and c) can figure out how to have the test suite not break (unnecessarily) every time I do an A/B test.
A little while ago I had a similarly silly bug in Mibbit.
The advertising is specifically setup to refresh every few minutes with new adverts relevant to the discussion.
Only problem is, I had typo'd:
setTimeout instead of setInterval = only one refresh!
Bugs like that and patio's are a little hard to spot, since everything is still working, money is still being made, just not as well as it should be :)
Yeah. Its like filling a bucket with a hole in it -- the water level is still rising, so you don't notice that you're losing half of what you're putting in.
Except in my case, the bucket was used to stop a shotgun blast and then I started filling it from a fire hydrant.
Thanks, Patrick, for your unceasing dedication to A/B testing for web signup interfaces. Why--if you hadn't actually bothered to track how well users that don't see buttons convert, well, let's just say I don't think anyone else would have done it. [knowingly. :)]
Thanks for taking one for the team. Many dollars died to get this information.
Using text-indent: -1000px is a terrible hack anyway. Some hacks are necessary but when you're moving elements off the page to achieve an effect, you're definitely doing it wrong.
I want to downvote you but I'll reply instead: I've noticed this sort of response on HN more lately, where someone is criticized for the way they did a thing, or their approach in solving a problem, but the criticism is completely unhelpful.
patio11 clearly said in his blog post that CSS wasn't his bailiwick. Instead of simply saying, "You did it wrong!", you might say:
Let's not be excessively gentle here: text-indent -1000 is a terrible hack (try input type="img" instead) and while I'm not mean enough to think the author deserved what he got, I also don't think we should feel overly sorry for him learning about how HTML works the hard way.
If you've been at it for a few (and I do mean "a few") years, building sites that work in all major browsers (FF, IE 6 - 8, well, alright, Safari) turns out to be not the most difficult thing in the world.
To add to this: The reason the text-indent trick is used was normally for header replacement, navigation replacement, et cetera, and was a method of providing strong naming that didn't clutter markup and fed screen readers or CSS disabled browsers.
Also to expand on it a little more, I use(ed) this trick a lot, and I've never had the image shifted off the page. I'd be interested to see the HTML that actually broke.
I didn't mean to comment directly to the author but make a general statement of the current state of the art in CSS: to achieve an effect use the craziest hacks one can find. As you said, patio probably just found that code on the web and used it.
<input type="img"> with the appropriate alt-text. Of course, your code has to be handle both regular submit buttons and image submit buttons interchangeably (it's a good thing to add). That also requires changing the markup but if you've got a template engine that's easy enough.
There's nothing wrong with designing in Chrome or Firefox, but I think you have to have IE 7 open as well and at least give it a look every few minutes to make sure it matches what you see in your primary browser.
(Then, of course, check how it looks in IE 6 and 8. I say keep IE 7 open because surveys have said it has the most users of any IE version at the moment.)
Indeed. The emacs on my production server is the same emacs I use on my desktop. If an emergency fix needs to be made, I have the same comfortable environment as always. With a 256-color xterm, I don't really even notice that I am not using X either.
I would like to be smug and say, "vim can't do this", but that's not true. If editing files on your production server sucks, it's because you didn't set things up appropriately. (Yes, I agree with the comment below that you shouldn't edit your production app. But if you are in a coffee shop at 2 am and a CSS problem is preventing half your users from using your site, you might just want to make a quick hack that fixes the problem and worry about "best practices" when you get up in the morning.)
It's nothing to do with the server environment; a Linux install is a Linux install. Hacking your live application is generally still a bad idea regardless.
I was being facitious suggesting that somehow a Linux install would be substantially different from one VPS provider to the next (likewise that Python would be any easier or harder to hack on than Ruby).
While I agree that playing with production code is generally a bad idea, there are certainly times it's called for (granted, 2AM may not be one of those times, if a few hours later you can be in your "normal" development environment)
You could turn the lessons learned here into a service, something that you give a url and it will render it in all browsers known to man, then highlight the differences between the various renderings.
I just don't like the design of the site and how you have to wait for an email. There is no instant gratification so there is room for improvement, albeit difficult to execute.
Have you looked at how they have it set up? Your link goes into a queue for the servers that are called "Factories." It is a massive distributed computing environment like SETI where people volunteer their computers to take the screen shots and upload them to the web for you to view.
The last doesn't work for me (Mac using either FF or Safari) but the other two seem to. I haven't used any of these personally, and am not affiliated with them, just listing some options for others to check out.
Every possible build of IE that you might want to test against. It is too bad he got hit by this bug, but he and/or his designer should be looking at the site with the same tools as his customers. Thanks to non-standard standards you really can't trust that anything you make is cross-browser until you confirm it.
> However, IE6/IE7 treat text-indent as moving the background image as well
Great post - any chance you could also post the css that caused the problem? I use negative text indent all the time to do exactly this and haven't noticed any IE problems - it'd be handy to know what combination of styles causes this for future reference!
The CSS links in that are good, but the relevant snippet is the following. The second definition is the one that, when added on top of the first, fixes it for IE.
The site's down for me right now, so I don't know exactly what it's about. But since everyone's mentioning cross-platform testing, here's how I test for (basic) design differences:
This post inspired me to re-check my app on Safari & IE, and discovered it no longer worked on either. Reason: if you say "thingy.attribute === undefined", and thingy itself happens to be undefined, then it works on Firefox only. Ooopsie.
IE8's IE7 compatibility mode is not perfect, especially when it comes to JavaScript. If it really matters that your site work in IE7, you need to actually test it in IE7.
http://www.microsoft.com/Downloads/details.aspx?FamilyID=21e...