Posted
by
Soulskill
on Tuesday February 15, 2011 @09:12AM
from the no-it's-ok-take-your-time dept.

CWmike writes "Those curious about the final release date for the hotly debated HTML5 need wonder no more: the W3C plans to finalize the standard by July 2014, the consortium said on Monday. 'This is the first time we've been able to answer people's questions of when it will be done,' said W3C's Ian Jacobs. 'More and more people from more and more industries are asking when it will be done. They require stability in the standard and very high levels of interoperability.' Meanwhile, as Apple dismisses the value of the Flash Player in favor of HTML5 for its smartphones and tablets, Adobe said on Monday that it predicts 600% growth in the number of smartphones having the Flash 10.1 Player installed in 2011, reaching 132 million smartphones and more than 50 tablet models with either the player installed or available for download. For the six months following the launch of Flash 10.1, more than 20 million smartphones were shipped or upgraded with it."

Shame about flash - whereas I don't like Apple's draconian banning of the whole technology it leads to a lot of real, heavyweight web pages, and really preentation should be dealt with via the browser and not a plugin (via HTML5)

It's not so much "banning" as "your implementation is piss poor, even on Windows, try again later". If Adobe actually grave a crap about flash performance they would work on it and they have made some inroads with 10.1 - it's a world better on OS X, for example, compared to Flash 10.0, but it's still nowhere near good enough for a mobile device that doesn't have a ton of extra CPU to throw at it to make performance acceptable. If there was actually a properly decent flash player for mobiles that could run o

The root problem is commerical software vendors sell their software on new features.

That is fine for a field with little exposure to security threats but for basic infrastructure it leads to features that seemed like a good idea at the time but cause big problems down the road. For example putting scripting in pdf opened up massive cans of worms. Besides the plain and simple exploits it opened the possibility for fraud through the authoring of PDFs that displayed different content on different systems.

Also nonsense. Do they also block Firefox and Chrome and browsers they do not control? Flash performance is equally is bad in all browsers.

Also, how do they "block access from the browser"? The Safari main process handles input from the keyboard and mouse, but other than that the plugin has access to the same core features of OS X. Safari doesn't "block" anything. Flash performance actually got better when they put it in a separate process of its own.

Oh, please stop repeating this crap. Apple didn't let Adobe have access to the low-level decoder interface on the hardware. Instead, they gave them access to a heavily-optimised H.264 CODEC which had the ability to output to an OpenGL surface. Everything that flash needs to do was possible with existing OS X APIs. With OS X 10.6.4, Apple added the exact APIs that Adobe requested. The result? Flash still uses twice as much CPU power as other apps.

Also remember, Apple doesn't play nice and doesn't let Adobe have access to all the resources for Flash to utilize in order to perform nicely.

So why the hell are Flash Apps so much slower on Flash 10.x than on 9.x? Does Apple block access to the CPU? The lame "we don't get access to video acceleration" doesn't cut it for me when everything is slow.

It's not so much "banning" as "your implementation is piss poor, even on Windows, try again later".

No, it's banned. It's banned just like Java. The base reason that Flash is not on the iPhone is because they do not allow non-Apple apps the run their own code on the iPhone, probably for security reasons. That Flash is a resource hog, the cause of most Apple browser crashes, and probably wouldn't provide a good experience because most apps aren't built for a touchscreen interface, is just additional reasons

I was talking about the size *when running*. For example I have Firefox open right now and it's using 500Meg, versus Non-google Chromium which hovers around 40Meg (but also does not have built-in video support - it launches external apps or plugins).

>>>relies on the OS for support for thousands of different codecs

That's just great (not). My Windows XP doesn't have the newer codecs built in. Neither does Ubuntu or Puppy Linux. Or Commodore Amiga OS.

For example I have Firefox open right now and it's using 500Meg, versus Non-google Chromium which hovers around 40Meg (but also does not have built-in video support - it launches external apps or plugins).

I find it hard to believe that Chromium is so much more RAM-efficient than Chrome - because the latter uses about 20-40MB per tab on my machines...

People still worry about RAM? Unused memory is wasted memory. I also dispute the claim that Chromium is only using 40MB of memory on your system.

That's just great (not). My Windows XP doesn't have the newer codecs built in.

So install them. Your original argument was that you preferred having a "lightweight browser" in which you installed plug-ins to augment functionality. How is that different from installing system-wide codecs and allowing the browser to use them?

A browser that relies on the OS for support for thousands of different codecs

Such a browser could not run correctly on a free operating system because most popular audio and video codecs used on the Internet are covered by one or more patents licensed incompatibly with free software. Case in point: In Ubuntu, Software Center and Synaptic put up a big scary warning of potential patent infringement when the user tries to install anything related to FFmpeg.

A browser that relies on the OS for support for thousands of different codecs

Such a browser could not run correctly on a free operating system because most popular audio and video codecs used on the Internet are covered by one or more patents licensed incompatibly with free software. Case in point: In Ubuntu, Software Center and Synaptic put up a big scary warning of potential patent infringement when the user tries to install anything related to FFmpeg.

So? If you need the codec, it has to come from somewhere, not the magical codec fairy in the sky. Either its in the OS (once), in each app (a few times), or provided as software as part of your stream (every video), but its coming from somewhere either way.

Do you expect every application to come with its own set of printer drivers, too?

Do you expect every application to come with its own set of printer drivers, too?

Often, each app does come with its own routines to generate a PostScript file that it uses the operating system's facilities to send to the printer or to Ghostscript, just as each browser might come with its own routines to generate a stream of decoded frames that it uses the operating system's facilities to send to the video card.

Forget the "Free Operating System" for a sec. 99% of people use a non-free operating system. Should we forget streamlining for those people because a few FOSS people don't like the idea?

Windows XP Home Edition, Windows XP Professional, Windows Vista Home Basic, Windows Vista Business, and Windows 7 Starter are proprietary. They lack a built-in AVC decoder just as much as any free operating system does.

Well that is the hope in HTML5... one of its most pivotal features is the Video tag. Although there's no guarantee that browser makers will want to scale things down resource-wise after HTML5 becomes ubiquitous (especially the IE/Safari bunch, for obvious reasons).

Even better, how about a lightweight browser that doesn't require plugins to view videos?

Developments that affect the web and the browser move along many tracks.

The Flash based game can be as elegant as "Machinarium" and it can be here today and not something we have to wait for until 2014.

Media codecs in particular are a moving target.

HEVC, aka H.265, should be ready in about two to three years. HEVC is not exclusively or evenprimarilyy a web or smartphone codec - it has a lot to offer to a streaming media service like Netflix or an HDTV manufacturer like Mitsubishi,Samsung or Panasonic.

Ah, I see, so the browser couldn't use some scheme whereby it would support whatever video codecs are supported natively by your OS, allowing you to simply update a playback library when/if a codec changes, or install a new library to support a new codec?

What is it with people having some sort of fetish for putting EVERYTHING into the frigging browser?

And that probably explains why I stick with vim for text editing, and have never understood the appeal of emacs - I don't want my text editor to also do a million other things, I'm happy with pretty simple text-editing.

You have to update your browser all the time to fix security holes. Because it's so complex that it contains lots of bugs, which are potentially exploitable. Because it has to implement loads of features. Like video decoding...

That is flash. it is also why it is not very portable. it is also why the arm versions don't implement the full flash feature set even though adobe says it does. There are many flash websites that simply don't work with 10.1 mobile flash.

Plugins have existed since the earliest days of browsers (like quicktime plugin to view embedded movies)(or wav plugin to deal with sounds). Why do you think that is an inferior method?

Because only root can install plug-ins,

Bullshit.

OK, only anyone with permission to write to an executable folder can install plug-ins. I assume that you're referring to installation of plug-ins to a single user's account by that user, but in a tightly secured system (/home mounted noexec under UNIX or Software Restriction Policies under Windows), this is root (under UNIX) or a member of the Administrators group (under Windows). On some devices, even the owner of the machine might not have permission to install executable files that the device's manufactu

> Plugins have existed since the earliest days of browsers (like quicktime plugin to> view embedded movies)(or wav plugin to deal with sounds). Why do you think> that is an inferior method?

Because the Web is hardware and platform independent, and plugins are not. Because there is a way now to give the browser the audio or video via HTML and the browser renders it, cutting out the middleman. Because today's Web user is a consumer who doesn't know what a plugin is and doesn't want to manually update it or install a collection of them or be told they don't have the right one. Because there is an almost 10 year old ISO/IEC video standard that is available in the hardware of every PC and mobile, so that they can play the same video that FlashPlayer and QuickTime player play but without having to have the software players. Because hardware playback takes much less battery power and less expensive hardware than software playback. Because little plugin makers like Adobe become tin pot dictators and they to play gatekeeper with Web content that should be universally accessible. Because plugins are an accessibility nightmare compared to HTML. Because plugins are a security nightmare compared to HTML. Because plugins limit hardware innovation, for example, the "smartbook" ARM notebook was rejected by PC makers because it did not have a FlashPlayer, furthering Intel's hegemony. driving up hardware prices and reducing battery life.

That is just off the top of my head. I'm sure I missed some.

> Personally I'd rather have the lightweight browser and then add features (like video)> only as I need them.

Video is a feature of your operating system and hardware. Your lightweight browser just passes the HTML video to the OS. HTML5 just standardizes how to do this. It's more lightweight than plugins.

While I agree with that in principle I have a LOT more problems with Flash (probably poor job of the browser handling it) than I do with any native HTML/javascript. I've never had an HTML heavy site hang or crash.

Hate to break it to you, but we have a numberless HTML zombie right now. Are Google, Microsoft, Mozilla, and Apple waiting patiently for the specification to be complete? No, HTML 5 is here today. Officially it's HTML 4 + stuff in HTML 5 that's already been agreed on. The vendors know where they want to go with the markup and with the exception of Microsoft, they all produce several releases a year. All of the engines have undergone complete revisions in the last few years to better position themselves

The problem is that it's not a finalized standard and as we've seen in the tag, there is anything but a consensus about what it should support. If each vendor goes their own way, then we'll be back to the IE6 glory days where sites either had conditionals for IE or they didn't support any other browser.

Maybe you're comfortable supporting a non-standard, but I'm not. I'm currently aiming for xhtml 1.0 strict compliance and if it doesn't validate, it doesn't get published. The reason is simple. I want th

I've had this argument before, and it's pointless...HTML will become like the meaningless term "Web 2.0"... With no standard, it will become a buzzword open to interpretation and won't actually mean anything. Google, Microsoft, Mozilla and Apple are going to fuck this up thoroughly in hope that a clear winner of the new browser war emerges.

The battle ground is the web and casualties will be our websites.

It isn't like any vendor is going to retract rendering support for an older version of (X)HTML. If this "browser war" fud-analogy is correct, it would mean certain failure for the first browser to stop supporting HTML in any of its old forms.

So yeah, moving forward with a non-standard may not be best, like, on paper, but bickering and fighting over new markup/codecs/resource allocation moving forward won't take away from the power us web developers have in using a slightly older but universally-supported

HTML has never been the problem. It's trivial to make a page that is HTML compliant. The problem has always been (and will always be) CSS, DOM, and scripting, which are not covered by HTML and have already been defined and standardized well beyond the capabilities of current browsers. And as long as there are patents and royalties involved , things like embedded video will never be settled on, largely due to the intractability of the open source community on such topics.

Do the video tags adequately support live streaming media yet? I've read, and probably experienced unknowingly, that the video tags do a good job of streaming normal media, but some of the stuff I've been reading suggests that live streaming for sporting events and such is fubar?

HTML5 does not specify a streaming mechanism yet. While this is being worked on (W3C: Fragments, Media Multitrack API), it means that live, DVR and long-form video content cannot be played using a video tag. Most browsers do provide an alternative, such as utilizing the range request header to do pseudo-streaming, but this is no long-term solution.

The tag doesn't actually define much, most browser implementations are choosing to concentrating on HTTP streaming of h.264 or WebM, as such are still fairly limited. I think Safari streams MPEG TS files rather well, but given the is still no video support at all in Internet Explorer, the lowest common denominator is a problem.

It'll kind of suck though if the HTML5 video tag is useful for only youtube-esque sites, it would be nice if it was thought out enough to also work with live streams, as other wise we're still going to need all manner of plugins and things, and might as well just stick to flash and not bother with it?

Oh, right, because everything on the Internet takes about 5 years to come out. Everyone will wait for you, W3C. We've got Livejournals to keep us amused till then.

Seriously, though -- wouldn't we be that much better off if they would release the standard right now as, "final pending revisions for bugs", or similar, so the world can move on and not fall into 14 different camps of what is official and what isn't?

(I realize in a lot of ways this is all about terminology, but terminology matters, too.

Nope. An incomplete standard would lead into incompatible extensions by each browser, which would lead into the same fragmentation we've got right now except the devs document their extensions properly in hopes they'd eventually get adopted as the official standard, incentive they'd lack if said standard were 'final'.

And btw, what we've got to entertain us in the meantime isn't LiveJournal, but Flash;)

Don't forget that Flash on mobiles is basically a scam: Flash is only free of charge for "computers" (RTFEULA for definition). Adobe is charging a license fee to mobile device manufacturers who want to include Flash player. AFAIK, that even includes updates, meaning that Flash updates stop for devices that are no longer supported by a manufacturer, like the N900. Of course, Adobe can hold people to ransom over paid updates by making sure that content created with their newest authoring tools won't play on old versions...

Your post was intended as sarcasm, but in fact, SWF has been open for about two years since the Open Screen Project changed the licensing terms for the SWF spec.

H.264 and HTML5 are closed, and require onerous patent licensing terms of pennies per unit, with a hard cap.

What royalty-bearing technology is included in HTML5 and WebM? If you're referring to the patent on the 2D canvas, Apple has agreed to license that without royalty, as has Google with respect to its VP8 patents.

Nice straw man, I never mentioned WebM, champ. But, since you brought it up:

With the exception of Youtube, which will convert because Google owns them, no content producer of any size will re-encode their entire library and double their disk space allocation simply to support WebM, *especially* because they will not freeze out the entire existing ecosystem of H.264-in-hardware-capable devices - there's no appreciable benefit to shifting formats

This can be done gradually, as YouTube did when it reencoded all its videos after the iPhone came out to add AVC alongside its existing FLV.

and double their disk space allocation

Disk space is cheap.

*especially* because they will not freeze out the entire existing ecosystem

Sites already licensed to encode and serve AVC will continue to use AVC, even if they adopt WebM alongside it. New sites not needing to target iDevices or devices with old versions of Android OS may use WebM exclusively.

of H.264-in-hardware-capable devices

VP8 is so similar to AVC (see article 377 [google.com]) that any programmable DSP capable of AVC can likely be reprogrammed for VP8.

Sites already licensed to encode and serve AVC will continue to use AVC, even if they adopt WebM alongside it. New sites not needing to target iDevices or devices with old versions of Android OS may use WebM exclusively.

They won't adopt WebM along side it. They can serve Flash-wrapped AVC, after all that's one of the big selling points of Android - "It runs flash!"

New sites that don't take iDevices into account? Only if they don't want to make money. Why, when a single alternative format exists, would yo

Why, when a single alternative format exists, would you encode in such a way that deliberately cuts out 10's of millions of people who have enough money to buy an iOS device

Because iPhone users aren't going to want to stream your 1 GB feature-length video on a 2 GB/mo data plan, and users on Wi-Fi likely have a substantially bigger PC monitor in the same room. Or are you talking about a rental that doesn't doesn't expire, in which one downloads a video on Wi-Fi and watches later?

You could, instead, encode to H.264 / AVC, and serve that up natively to the devices that support it, and then wrap that same H.264 content in Flash for devices that need Flash to play H.264.

Then what do you do for devices that report no AVC support and Gnash instead of Flash Player?

It just makes no sense, when there is no compelling benefit to switch to WebM for any online/streaming use - it's already royalty free for them

This is true, as I understand it, if your videos are ad-supported or otherwise free as in beer. But if you'r

H.264 and HTML5 are closed, and require onerous patent licensing terms of pennies per unit, with a hard cap.

What royalty-bearing technology is included in HTML5 and WebM? If you're referring to the patent on the 2D canvas, Apple has agreed to license that without royalty, as has Google with respect to its VP8 patents.

Looks like Apple learned their lesson from the Firewire licensing fiasco, which lit a fire under the USB2 standard and pushed the decidedly superior technology into irrelevance.

For what it's worth, Flash is open. I wrote a few simple apps in raw flex, and some much more complex ones with Open Laszlo [openlaszlo.org]. True, Adobe opened it up in a desperate (and largely successful) bid to survive Silverlight. The openness of Flash made it possible for me to write this [mozilla.org], so all and all I can't complain. Not as a developer anyway.

The other issue, aside from Adobe squeezing the sector for all it is worth, is that a fair amount of the Flash out there was really built with the performance of fairly beefy wintels in mind. Aside from Atoms, basically the cheapest and nastiest computer you can find on the shelf these days is running an A64 derivative in the 2GHz range, backed by a couple gigs of RAM, and an embedded video chip that probably has the same die area as your phone's entire ARM SoC.

Having flash is useful in certain legacy cases(if you must have StrongBad on the go, that was running fine on 600MHz P3s, a decade ago...) or just plain maldesigned websites(Hey! instead of providing an HTML link on our useless flash-splash page, let's embed the link in the flash!), or use cases that just dump a video stream right to the hardware decoder(though using flash to do this is comparatively pointless).

For things like games, though, (or even just ghastly banner ads), your battery life and system responsiveness will quickly inform you that most Flash out there was really designed for a much more powerful system.

Actually it is even more stupid. They no longer charge a license fee, but only 'trust' vendors to release working players.
http://www.openscreenproject.org/partners/apply.html [openscreenproject.org]
Given the quality and length of support any hardware vendor gives compared to the community this is just spiteful.

Do you want to continue supporting old hardware. Cell phones have a 2 yr life cycle. By that point, they're obsolescent. Sure, people are still using them. But does ANYONE really expect them to get, and run the latest updates.

Sorry, that's a very weak argument....

As for the cost of mobile device makers using Flash. I think this is going to come down to platform. If you are running an ARM processor with a standard graphic. There will be little cost involved in porting Flash to your device. Some QA testing, e

The only reason iPhone Clones are running Flash is the developers believe that will give them a competitive edge over Apple.Unfortunately, all Flash compatibility on a Mobile Device does is dilute native development. BBC iPlayer is a native App on the iPhone while it is a Flash App on Android.Android currently has a competitive edge due to misinterpretation of Market Share figures, They could have hundreds of native Apps and actually be a viable alternative to iOS on higher end devices, but instead will pis

In the context of the mobile phone market, where the end user is rather limited control over the firmware(without resorting to quite-unencouraged hackery), the scamminess is arguably much greater, in practical impact.

On a PC, say, it is quite likely that many, likely most, of the hardware components have a mess of patents and licenced code baked into their firmware. The same thing would apply to a phone's cellular baseband components. While the "free hardware" hard line might find that philosophically pr

3 years is an eternity in web time. By 2014, the web will have evolved once again into something nobody can foresee today.

It's a BAD thing when standards bodies cannot keep up with the technology they're attempting to regulate. Fortunately, the only outcome is that the standards body becomes irrelevant, which is what should happen to most of them.

3 years is an eternity in web time. By 2014, the web will have evolved once again into something nobody can foresee today.

In three years, the W3C HMTL5 standard will probably document a safe, nearly universally available, baseline standard. It won't document anything interesting or cutting edge, but that's not really the point, that's what the "living standard" for HTML maintained by WHATWG, which "actually now defines the next generation of HTML after HTML5." [whatwg.org]

Nope. You've never been able to write pages against the HTML4 standard, and you certainly can't now. No browser "properly" implements HTML4, and to the best of my knowledge, never has, and never will. Just you try writing a document that looks like the below, and see if you can find a browser that renders it properly. Of course, if you do find such a browser, it probably can't render actual webpages properly...This *is* valid HTML4 syntax:<html<head<title/Foo/</><body<p<a href="foo"/

So, just to clarify for all you people who haven't realized yet, there are two different groups working on HTML at the moment.

The W3C HTML Working Group, which is putting together the final HTML 5 spec. (Which will consist of various things that have at least two independent implementations.)

The Web Hypertext Application Technology Working Group is working on various new HTML stuff, and is getting new stuff into browsers as soon as possible. Experimenting with new tags and so on.

For all you professional corporate/big org types, I strongly suggest continuing to work with HTML 4.01 Strict (and/or XHTML 1.1 as appropriate). OK, you could go with HTML 5 if you really want to, but the difference is, that it isn't stable yet. And is it really sensible/professional to create corporate/big org pages that might not get touched for five years if the "standard" you are basing the pages on, isn't even standard?

For your personal website, use whatever you want. But if you aren't using features of the new HTML5, I suggest you don't use it. (Personally, I think the new form stuff is awesome, but haven't noticed much else that I would use as yet.)

The people that create these flash, create flash slow enough to eat the 60% of the CPU of a Double Core 2 GHz.How much horsepower is the 60% of a Double Core 2 GHz: more than the horsepower than a mobile decide have. So that flash with almost stop the mobile device.

The only way so flash is usable in mobile devices, is if the people that make these flash test then in slow mobile devices, and decide to remove some effect, be conservative. Good luck with that, has the same problem hit PC's, and these people don't learn.

Adobe could, somehow, help here creating a special mode for the flash player called "Emulate slow device", so people could experience how shitty is his flash creation in a mobile device, but Adobe itself is lazy and will not provide that.

Tei mentions that Flash takes a lot of processor power even in a dual-core system, and believes that this amount of usage would overly tax less capable mobile devices. His (her?) idea is to have a mobile emulation mode available to allow developers to model Flash on those devices, and in the process perhaps streamline some of the extra effects to improve mobile device performance. (That's a pretty damn good idea, BTW.)

The 10.2 update was a security fix for "all platforms". I don't know if that included Android. Do these mobile systems have better sandboxxing than desktops? http://www.adobe.com/support/security/bulletins/apsb11-02.html [adobe.com]Then again, "all platforms" apparently does not include Mac OSX on PPC, which I read elsewhere is no longer supported AND not affected by the security problems.

Alright, I know it's popular to bash Flash on Slashdot and as much as I love open standards, it pains me to say that HTML5 by itself is NOT a Flash replacement. In order to get all of the features of Flash, you have to cobble together HTML5 + CSS + SVG + ECMAScript + Javascript + Canvas. To make matters worse, I have not seen a WYSIWYG tool for any of these technologies that comes even close to the development environment of Flash. Until this changes, I can't fault any developers for choosing to use Flash over HTML5 for their feature-rich content. That's why God invented ClickToFlash.

Alright, I know it's popular to bash Flash on Slashdot and as much as I love open standards, it pains me to say that HTML5 by itself is NOT a Flash replacement. In order to get all of the features of Flash, you have to cobble together HTML5 + CSS + SVG + ECMAScript + Javascript + Canvas.

Wow, that's redundant. You made that sound really big, but if you remove the redundant parts, that's just HTML5 + CSS + SVG + JavaScript, and ECMAScript & JavaScript are the same thing, and Canvas is an HTML element with a defined JavaScript API.

HTML (content) + CSS (presentation) + JavaScript (behavior) is pretty much the standard way for doing stuff on the web anyhow, even for things much simpler than you'd use Flash for.

Flash isn't going anywhere as YouTube will not drop it due to limitations with the HTML5 video tag. Such as as no caching, no data protection, the difficulty in embedding the videos into other websites, no full-screen display, and a heap of other things that Google mentioned. [youtube.com]

That'as just wrong. You can define applicationcache to do it. You define it in your manifest.

Yeah I know, there isn't a great big shiny button for you to just click without thinking, so you probably missed it.

And full screen in the API is not a good idea, it should be handled by the browser. It opens up a myriad of security issues, as well as opened up an avenue for full screen video ads that the browser has minimal control over.

Who cares what the W3C says? This doesn't really make any sense. Remember how HTML5 signifies the shift to "Versionless"? The W3C is essentially trying to undermine WhatWG's guidance.

HTML5 is already largely stable and in production use with incredible interoperability.

So the real question is this:
what do we do about the W3C now that they are not just impeding progress with their absurdly slow pace or conflated bureaucracy, but are actually engaging in FUD to steal the thunder from people who are actuall

Who cares what the W3C says? This doesn't really make any sense. Remember how HTML5 signifies the shift to "Versionless"? The W3C is essentially trying to undermine WhatWG's guidance.

No, W3C is documenting stable standards, and WhatWG is coordinated collaboration on forward looking development. The processes have different needs, but integrate reasonably well together. The WhatWG HTML living standard documents, essentially, features that browser vendors are willing to work toward implementing, the W3C HTML5 standard will document a subset of a point-in-time version of that standard for which interoperable complete implementations actually exist.