hasLayout problems after all these years

Having terrible trouble with all version of IE trying to get some peekaboo text to stay put. In this scenario a div was not paying ball at all, after setting hasLayout on pretty much every element in the entire page I realised that the system was outputting HTML without a DTD, dogh, I feel like i've just called tech support to complain about not being able to print, only to find out that the cleaner unplugged the printer.

Note to self, always check the most obvious thing first!

In IE7 I have a normal input type = button which as the behaviour that when you scroll the text in the button gets visually corrupted. So very slowly scrolling the button into view will wipe the text and the button will appear empty. The offending button is fine in IE6 and IE8, I was tempted to ignore this and mark it down as a bug in the browser but weakened and decided to fix it.

After tinkering with the CSS for a while I couldn't find any hack/fix for this issue, setting the writing-mode style to top to bottom, did fix it but didn't think having the button text written out vertically would go down well!

In the end....

window.attachEvent ('onscroll', function(){
 // layout fix for IE7 disappearing text, element has layout so resorting to this madness!
 document.getElementById('buttonMoreSections').style.backgroundColor=(document.documentElement.scrollTop % 2)? '#fff':'white';
})

total MADNESS !

• More about hasLayout

Expression Web SuperPreview

Having a play with Web SuperPreview from good'ol Microsoft and I have to say i'm a little disappointed.



It very much aimed and a px by px comparison of two browsers, which in my experience is pretty much a waste of time. I've never had a support call were someone is upset about the look and feel being slightly different on a different browser.

Focusing on minor UI display differences results in designers insisting on using graphic buttons and DHTML scrollbars and code forking in the CSS in order to achieve pixel perfect adherence to the visual design on various target browsers. Not a road that I want to go down.

I think I'll be sticking to IETester and VMs, for now anyway.

Also, i may be missing something blatantly obvious but I couldn't workout how to trigger a control or even follow a link in the preview panel so couldn't inspect any dynamic page elements. I assume that's just me being a twat. The product would have no value at all if you can't interact with the page, but it's not immediately obvious how you do (well, not to me anyway!! : ).

Related links...

• http://www.sitepoint.com/blogs/2009/03/19/microsoft-superpreview-website-tester/


• http://www.sitepoint.com/blogs/2008/12/04/adobe-meermeer-will-change-the-way-you-test-web-sites/


• http://www.my-debugbar.com/wiki/IETester/HomePage


• http://browsershots.org/

Are DOM browsers the edge case?

I think the answer might be Yes.

You want your application to work on the web so you write it to output semantic HTML, if you do this without using script (or noscript tags) your site should work on pretty much any browser that understands HTML regardless of platform, OS, browser version etc... that's quite a lot of different user-agents running on, mobiles, iTV, games consols, PCs etc... A subset of these user-agents will understand javascript to some degree, and a sub-set of these will understand DOM. If you then think of DOM browsers as a edge case (albeit an improtant one) everything falls into place.