Linked by Thom Holwerda on Wed 20th Apr 2011 09:20 UTC
Google The revolution has begun! Web video will be freed from the shackles of the MPEG-LA and the dreaded claws of patents and incomprehensible licenses! Sorry, I got a little carried away there. Anywho, YouTube has announced all new videos uploaded to the site will be transcoded into WebM, and that the most important part of the site's catalogue is already available in WebM.
Thread beginning with comment 470714
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: What Youtube SHOULD do!!
by galvanash on Wed 20th Apr 2011 19:08 UTC in reply to "RE[4]: What Youtube SHOULD do!!"
Member since:

I think this has more to do with the fact that the html5 standard ISNT FINISHED

Not so much that it isn't finished - more that what people call HTML5 for the most part is not actually HTML5. CSS3, Geolocation, the file api, localDb, simpleWebDb, offline Storage, microData, canvas3D, etc. etc. - none of these technologies are strictly part of HTML5, they are their own individual specs.

HTML5 itself is primarily the new tags (video, audio, article, etc.) plus canvas support. A browser claiming HTML5 support only has to implement this subset to be compliant. True that it is not technically "finished", but it is pretty stable now.

The issue is in reality there are progressive browser engines (webkit, opera, and gecko) and then there is trident (IE). The progressive engines are more or less about the business of proposing, creating, and implementing new APIs by actually building and releasing them. They cooperate with each other. That is after all how this stuff gets done - you don't propose an API and then have committee meetings for a year or two until everyone is happy - you spec and build it and let the standard evolve through cross-implementations (assuming everyone likes the spec). The standard "falls out" of the implementation once things stabilize between engines.

Microsoft used to do that to some degree, but they more or less did it only in one direction and always liked dealing from a position of power. They spec and implement, and then they would say "we like this, you should do it too". If no one else agreed they would happily ignore everyone else and go their own way. And they mostly ignored what everyone else agreed was better solutions to the same problems unless developers screamed bloody murder and they would eventually come around and implement - but they always kept all the crud they built up with their proprietary extensions. They actually encouraged their developers to use their extensions to achieve lock-in.

That is how they ended up with the pile of sh*t that pre-IE9 versions of the engine was. They did not actually participate as an equal because they has such large market share they believed they could dictate by fiat where things would go. They finally figured out they were wrong with IE9.

Imo, they are being cautious with what new specs they implement because they do not want to implement experimental stuff that will end up being a dead end (for example localDb - firefox and chrome both support this, but everyone agrees is is a dead end and wont go anywhere). They are no longer trying to be too progressive either. I think Microsoft being cautious at this point is the smart thing to do, let the other engines hash out the experimental stuff and then implement once things have settled down enough where it is obvious that said feature has legs and is relatively stable. It sucks as a developer because IE will tend to always be a bit behind the curve, but imo that is MUCH better than it being just plain broken (like all pre-IE9 versions were) and actively encouraging developers to embrace new "features" that end up being dead ends in the long run.

The difference with experimental features in the more progressive engines is they rarely implement anything unless there is a strong belief that the other vendors will follow - none of them want to implement a feature that is proprietary to their engine. They want consensus eventually, but will implement to prove it out. This is totally different from what MS used to do - they just did whatever they wanted and f*ck everyone else.

every different engine has its own way of displaying certain tags and no engine supports exactly the same tags as every other engine.

Which is how it should be. Default rendering behavior is only mostly similar in HTML4 because of many years of tweaking to get it that way. The same will probably happen with HTML5, but the standard is not about making everything look the same - it is about making everything mean the same thing. CSS gives you enough control for modern stuff to get pixel perfect rendering, but that is up to you as a developer to use if you want to. Not everyone (or even most people) care about pixel perfect rendering across different engines.

Thus when designing a page that is intended to be used by people using all sorts of browsers devs build the site in html4 to make sure that everyone gets the same experience.

There is nothing about HTML4 that makes it any better in this regard other than its age. I'm not saying your wrong at all, just that it isn't the standard that caused this - it was a slow process between all the engines to converge on a mostly uniform rendering behavior across user agents. I'm just stressing the point because the standard (either 4 or 5) does not dictate this kind of stuff, and as a developer you would be better off to either do layouts that don't require such precise rendering, or using CSS to force it. Relying on the user agents to do the same thing by default will never work in the long run...

Thats not to say that there aren't devs who didn't build because of your reason, it just unlikely that that was the main reason

I think HTML5 will get used more as it becomes necessary. By that I mean when you want some feature on your site that necessitates either a) do some crazy roll your own implementation -or- b) HTML5 already offers some API that will do most of it for you or at least help you greatly - most devs will chose (b). But if you don't need it, there isn't much point using it yet.

I do HTML5 sites - if you are strictly talking about the new tags it is easy enough to get good behavior across all the major browsers (even IE6), but it requires css and javascript shims for the older browsers. Nothing complex, but a new experience for a lot of developers.

Reply Parent Score: 4

modmans2ndcoming Member since:

except HTML5 is all those things. so... yeah.

Reply Parent Score: 2

galvanash Member since:

Want to elaborate a wee bit? Not sure what you are getting at... The HTML5 spec is viewable on the w3c site, and it does not include, nor will it include, anything outside of the markup language itself. The plan going forward is to keep Apis not directly related to markup outside of the "standard" and track them under separate working groups.

Reply Parent Score: 3