after a while with CSS, I have no problem with IE6, or at least not something that can't be fixed.

It is however unfortunate that often I could get everything done and still see it look dreadful on IE6, thus having to spend a little bit more time fixing it.

IE doesn't have useful tools like FF Web Dev extension, so that adds even more to the trouble-shooting.

Firebug does have a 'Lite' version for non-Firefox browsers. Although not as feature rich as the original version, it's quite good. Microsoft also has IE Developer Toolbar as an addon for IE.

Agree. Speaking of productivity, time is everything. In my situation, the famous question from top management is always "So when do you think you can finish it?" This is a tough question because there are lots of variable to consider out there and most of the time, I'll ended up requesting extra days or weeks. There are things we can control and there are things we cannot. Thing like excluding IE6 support in the tech spec is something we can control. This eventually forcing end user to upgrade for the better. Less headache for us developer fixing f-ucked up technology which is not our fault in the first place and spend more time tackling real problem in our defined project scope. If I can eliminate 1 variable that I know can jeopardize my performance (speed), I think it's a big achievement.

i remember when i first grasp CSS a few years back, some fixes take hours.

nowadays, usually takes about 5 - 10 minutes. nowadays i find IE6 not as much a hassle as before. last time it was nightmare.

if all goes well, i could do a CSS that passes validation and works from IE8/FF down to IE6. if time is an issue, just use the # workaround - doesn't pass CSS validation but gets the work done.

i never said those aren't streaming, but the difference here is life streaming vs stream-lag-lag-lag-disconnected-restream-lag streaming. well, customer would be happy about the demo (if the item requires video/audio streaming like an online surveillance thing) but they'll be unhappy about the product when it runs live. tried msn/skype's video? doesn't the service just being bad from time to time and the response given from TMNut is "lulwut? i dunno..."

i'm still not sure what would be the outcome of the standard since support for ogg as build in standard has been disbanded due to few objections. if there was any progress made, it would not be popular and cause any sensation.

tried download some files without any download manager lately? that's the point i emphasize on. it will not work quite well when comes to streaming video/audio in our country and people will still use Flash objects for seaming lagless blurry video while others is running on clearer HD version, if the whole HTML 5 streaming stuff is finalized.

i know the object has similar functions with <option> tags in unpatched IE6, which ignores whatever layer being put on top of it.

If it is regarding broken downloads, Flash isn't innately better.

YouTube URIs have a start time parameter that specifies where the video starts at. This allows YouTube to resume playback of a broken download by starting another download. I presume that ActionScript event handling was involved. It isn't far-fetched that the same can be implemented with <video> by the way of JavaScript event handling.

I do not know how other video sites handle the problem, but I would guess it would be the same if they did spend the effort.

Am I wrong?

This post has been edited by everling: Aug 10 2009, 10:39 AM

you're not wrong, but we need to see the outcome for the full specification, and it is one heck of a long wait.

XHTML would still live for quite a long time with few large company like macromedia or borland and with the huge IE6 hoarding fan-boy/gurl from M$, it'll be a real headache if HTML 5 really got implemented and some dude in the company who know nuts about it starting to boaster on how great and how useful it can be, that brings unforeseen and unbearable consequences to the whole dev team to quickly adapt the technology in a short time without understanding the fundamental basics while getting b!tched by their customers on 'why tha fook it not working?'

So XHTML going to move into something like MXML (Flex/Flash)? Well ah, what can I say? For me those things just barely the same things, except MXML can have event listener on it too. Well I would be happy if HTML evolve into more 'supportive' in term of action handling.

Changes? Well it would take ages... Why don't we just maximize what we have now?