Discover Top Posts Tagged with #ppapi

PPAPI

Am I the only one concerned about PPAPI?

While standardizing, updating and bringing the Browser Plugin architecture closer to the new technologies is ostensibly a Good Thing™, I though the whole point of HTML5 was moving away from plugins and towards platform agnostic web applications.

Certainly I can see the benefits. An universal API for native plugins, enabling plugins to work consistently in all browsers. And certain plugins are definitely useful, like handler for various uncommon media-types. But the whole problem with the latter, is the “Flash-problem”. Due to plugins, the web became littered with proprietary formats requiring plugins, and plugins went from “useful” to “must-have” extensions to be able to properly surf the net when said media formats became “de-facto” standards. Just try to navigate to a random restaurant webpage with your iPad, odds are you’ll not get very far before being instructed to download the newest version of Flash.

It would not be a problem if people followed the best practices, e.g something like1:

Unfortunately, what you generally find in the wild is something like:

Not only can’t I view the content in any form, I risk not being able to use the page at all, even to get content which would be perfectly presentable in the most basic of text-browsers.

HTML5 promised us an escape from this, by providing richer semantics and capabilities, as well as well-defined fall-back paths. A page written in HTML5, should be viewable in any HTML5 capable browser.

But wouldn’t a cross-browser/platform API mean that plugins would be available for anybody who’d need them? In theory yes, but you’d still have to compile the plugins for a target platform, and people won’t. If you’re lucky, plugins would be compiled for the most common OS’es (Windows, MacOSX and Linux), and of course those devices pushed by Google. But most other platforms are unlikely to have the plugins compiled for them, and since many plugins are bound to be proprietary, the community can’t pick up the slack. It would be no different from the “flash-problem” today.

I’m afraid that by promoting PPAPI, Google is sending a message that it’s okay to provide main content using plugins, thus propagating the “flash-problem”. And while this would be good for Google, as it would give Google backed devices supporting PPAPI an edge, it would not be good for anybody else. It would just maintain the status quo, perhaps with less buggy plugins, rather than moving towards an more open web.

As an aside, in an ideal world you could take this one step further. In the HTML5 draft, it allows the img element to display images in any formats as long as they’re non-interactive. You should therefore be able to just use <img src="/images/photo" />, and have the server return an image in an appropriate format based on the Accept header of the HTTP request.

E.g. the browser tells the server “I want this image, and I can display it in ‘PNG’, ‘JPEG’, ‘GIF’ and (through plugin) ‘OpenEXR’. I would prefer it in ‘OpenEXR’.” The server then returns an image in an appropriate format based on the image source and available output filters.

Unfortunately, browsers are really bad at using proper Accept headers, probably because so few people know how to properly handle HTTP-headers. I did a quick check (IE, Chrome and Opera), it seems browsers either tell the server they’ll accept anything (*/*) and/or just send the default accept values they use for webpages. ↩

#Google #HTML5 #HTTP #PPAPI