HTML 5 and XHTML confusion

Firefox 3.5 must be like me - doesn't like reading too many comments because it's cut off the page about halfway down the comments. :?

The page is getting pretty long, maybe FF ran out of available memory

Cuts of for me too, fine in Opera! as I've said recently FF starts to worry me slightly in it's minor buggy behaviour.

I do love Zeldman he has the ability to speak plainly and not come across as an elitist developer, a group of people that imho don't really serve the working developer.

So we wait till 2022 for full implementation of html5

oh and last comment in that list was:

CSS Creator HTML 5 and XHTML confusion said on 8 July 2009 at 1:18 am:

[...] Seems like this is causing a lot of controversy around the web. Zeldman in defense of web developers [...]

Zeldman has tracked down the Firefox error http://www.zeldman.com/2009/07/08/firefox-forces-red-background-flash/

Ah that's an interesting read, shame it can't actually pinpoint what FF is falling over on , why after a certain page length it considers it's had enough and will take overflow:hidden literally.

One of the last comments probably had the best fix to prevent the flash of background and one I have to admit I would have tried; if the fix was to state overflow:visible rather than overflow:hidden then replacing both of those with the easyclearing clearfix technique should almost certainly cure the problem.

Again it worries me that FF is showing buggy behaviour. We know that there are, from time to time, bugs that require fixing, and that this has always been the case, but just recently I have been aware of a feeling that I hit issues far more frequently, and that when checked against other browsers said issue has not manifested, of course generally I have wasted too much time hunting for an issue in my work :rolleyes:

It seems, if I read the comments correctly, that it is a combination of some (bad?) choice made by a Moz programmer and the workings of the MSFT os. I saw a comment that the effect occurred at the 16,384^th vertical pixel, which would imply 16 bit widgets. Not sure how that happens. A 16 bit bit of data gives ±32,768 values as a signed integer, and 65,536 unsigned. But what do I know? Back in the 8 bit cpu days, with 16 bit address lines, we would use 16kB memory boards (14 bit addy), with the top two lines/bits used to page up to four boards.

I could not duplicate the issue running in Linux. If a bug depends on the os, is it really a browser bug, or an os bug that Moz needs to accommodate?

cheers,

gary

Bug occurs on Mac in Camino but not FF3. If its the same one I know about its been around for ages and was supposed to be fixed in Gecko 1.9 - ie. FF3.

Internal values to the program aren't likely to be anything to do with the OS. Its sounds like Mozilla chose a 16 bit signed int. I can't imagine Windows is so bad that it would limit screen constructs to 15bits of pixels.

PS. Sorry, its not the same bug that afflicted Gecko 1.8. example. The page works in FF3 but not latest Camino. Its similar though, overflow:hidden on a very tall page. I'm too lazy to dig out the original bug report, but I recall it being triggered at a height of 32767px.

Cripes you two have given me a headache with your 16 bits on int thingies. So still wondering if that comment suggesting that clearfix would cure issue holds true, certainly not going to test it though, far too lazy.

If you don't use overflow:hidden then the bug won't affect you (at least for the one I mentioned). What you use instead of overflow:hidden is, I guess, up to you.