Hacker News Reader

Comment by rimantas | Hacker News Reader

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.

View on HN

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 will take this opportunity to keep plugging for http://crossbrowsertesting.com/

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.

good plug. I'm fairly certain to start using tools like this as managing "test VMs" is a PITA.

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.

Negative text-indent is perfectly normal and I've done it many times myself.

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.

Or use the <button> element with the text-indent background image trick. That works in IE6.

Came to say the same thing. Even better is just leaving out the background-image/text-indent trick altogether, and using the image's alt tag:

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.

Reply on news.ycombinator.com