Live data from Hacker News

HTML5 Flash Player (Shumway) lands in Mozilla

gemal.dk

81–90 of 181 posts

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#81
post #74
post #63

Why do we need this? The way that Flash has diminished in significance since high-quality browsers on smartphones and tablets emerged is a good thing. The web is better with Flash gone completely, not dragged along through compatibility layers.

First of all, good old backwards compatibility. There's large codebases still written in Flash, or perhaps things that are in Flash that will never get updated ever again (browser games being a big one), and people would like them to work even after Adobe's dropped out. It also turns out that reimplementing Flash in HTML5 gives you a great idea of what's missing if you want to tell developers to just use HTML5. There…

> First of all, good old backwards compatibility. There's large codebases still written in Flash, or perhaps things that are in Flash that will never get updated ever again (browser games being a big one), and people would like them to work even after Adobe's dropped out.

It's a fair point that wanting to retain the ability to run this content after there is no (working) Adobe plugin is desirable, but is the browser the best place for this? We don't demand that each version of an operating system is able to run all old application software for that OS; the preferred way of being able to do this is through virtualisation, and I'd argue that's probably a better way to do this, too.

> There has been quite a lot missing from the web standards that Shumway helped pushed through.

…such as? (I'm genuinely interested; I wasn't aware of this)

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#82
post #42

Earlier quoted context omitted.

Because is smarter to invest in developing a new tool to create HTML5 content than to invest in a tool that converts the deprecated flash to HTML5.

Smarter for whom? Adobe? It's in their interest to keep the 'depreciated' Flash going as long as possible, whilst it still makes them money.

It actually still makes them money. The Flash authoring environment is still one of the more popular methods of doing production-quality animation. See http://coldhardflash.com for lots of examples.

The Flash authoring environment is the best vector graphics editor I've used, even without the animation and scripting on top. They're still going to continue that, even if the Flash Player plugin is a bit behind.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#83

Does this mean the FSF can cross off 'free flash player' from their high priority list? What will happen to Gnash?

This isn't GPL, so I'm assuming work will go on.

It is Apache v2 licensed, which means that Shumway is free software. So, if Shumway functions adequately then I imagine that the FSF will consider the task complete. Believe it or not, the FSF and the GNU project don't demand that everything be GPL licensed.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#84

Does this mean the FSF can cross off 'free flash player' from their high priority list? What will happen to Gnash?

The Gnash guys have done a lot of good work, but for a native open-source Flash player, Lightspark became the project to watch some time ago: http://lightspark.github.io/

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#85

This is excellent for security. In the same way that Mozilla's PDF.js does PDF rendering in-browser and in-sandbox, doing SWF rendering in-browser and in-sandbox makes the security nightmare that is Flash go away. ADDED: Mozilla blogging about security benefits of PDF.js, which apply here too to http://andreasgal.com/2011/06/15/pdf-js/

I'd be afraid that I lose control of the flash with this. As things are now, I can safely disable the flash plugin and everything is fine. If someone is able to render flash within HTML5, how can I prevent it from doing so?

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#86
post #85

This is excellent for security. In the same way that Mozilla's PDF.js does PDF rendering in-browser and in-sandbox, doing SWF rendering in-browser and in-sandbox makes the security nightmare that is Flash go away. ADDED: Mozilla blogging about security benefits of PDF.js, which apply here too to http://andreasgal.com/2011/06/15/pdf-js/

I'd be afraid that I lose control of the flash with this. As things are now, I can safely disable the flash plugin and everything is fine. If someone is able to render flash within HTML5, how can I prevent it from doing so?

Well you can chose to disable pdf.js already; don't see why Mozilla wouldn't make swf.js configurable too. I'd expect flashblock plugins etc to continue to work also.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#87
post #81
post #74

Earlier quoted context omitted.

First of all, good old backwards compatibility. There's large codebases still written in Flash, or perhaps things that are in Flash that will never get updated ever again (browser games being a big one), and people would like them to work even after Adobe's dropped out. It also turns out that reimplementing Flash in HTML5 gives you a great idea of what's missing if you want to tell developers to just use HTML5. There…

> First of all, good old backwards compatibility. There's large codebases still written in Flash, or perhaps things that are in Flash that will never get updated ever again (browser games being a big one), and people would like them to work even after Adobe's dropped out. It's a fair point that wanting to retain the ability to run this content after there is no (working) Adobe plugin is desirable, but is the browser…

A big one that's being discussed right now is blend modes and filter effects on canvas, as we can't do a GPU blur or convolution filter on canvas contents right now. We're looking to see if it's possible to reuse some of the stuff like CSS filter effects on canvas 2D contents.

We've also helped with a lot of the baggage around audio decoding and synchronization, since Flash files can have MP3 files that require close sync to the timeline, so we need to use together with WebAudio, which is a giant bag of worms. We're still working through that on the web audio mailing list.

And we've also helped with some minor additions to the spec that aren't really too hard to implement, like canvas's isPointInStroke().

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#88
post #75

Earlier quoted context omitted.

There's no real conceptual difference between a element, a element, a WebGL experience, a NaCl app or a Flash on your webpage. They're all somewhat non-semantic, hard to search, rich media black boxes. So what's your particular beef with Flash, especially when rendered via HTML5? Or do you just hate all tools that enable creativity beyond a plain text website equally? Or did you just drink the Flash-should-die KoolAi…

There may not be any conceptual difference, but there is a very significant difference in how these things you describe are used. Flash, when used badly, becomes a self-contained sandbox for the entire experience of a website. Besides security concerns, this approach is damaging to the overall experience of that site, since developers end up needing to re-implement native controls and functionality (scrollbars, form…

Flash, when used badly, becomes a self-contained sandbox for the entire experience of a website.

But if it's rendered as part of the page instead of in a black-box plugin, doesn't that whole problem go away?

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#89

Earlier quoted context omitted.

This isn't GPL, so I'm assuming work will go on.

It is Apache v2 licensed, which means that Shumway is free software. So, if Shumway functions adequately then I imagine that the FSF will consider the task complete. Believe it or not, the FSF and the GNU project don't demand that everything be GPL licensed.

Which is great for the companies that take open source into their products and never return anything back.
Post reply on HN