Slashdot Mirror

W3schools, which you cited, is in no way associated with W3C.

Thanks for the clarification, much appreciated.

Though it's even more saddening to read W3C's vision on their own site:

Vision

W3C's vision for the Web involves participation, sharing knowledge, and thereby building trust on a global scale. The Web was invented as a communications tool intended to allow anyone, anywhere to share information.

http://www.w3.org/Consortium/mission#principles

I guess they'll need to amend it to "Trust anyone who has the cash, share with anyone who has enough money."

'What do we get for that DRM?'

Did "we" vote on this? Let's look at their members list: Apple, AT&T, Facebook, Csico, Comcast, Cox, Google, Huawei, HP, Intel, LG, Netflix, Verizon, Yahoo!, Zynga and ... The Walt Disney Company. Seriously, are we really so daft that we sit here scratching our heads wondering why a consortium of those players and THE WALT DISNEY COMPANY ended up including DRM? REALLY? There is a bill known as The Mickey Mouse Act in regards to excessive copyright that was passed into US law. And we're wondering how Disney might have influenced DRM as an option in a standard ... they're on the list, folks! Pull your heads out of your asses!

And those are just the companies I recognize that have a serious amount of money to be made on DRM (hello, Netflix?!). If I examine closer, there are much smaller players like, say, Fotosearch Stock Photography and Footage that sound like they would gladly vote for DRM in order to "protect" their products/satiate content owners.

The W3C used to be a member (i.e., company) driven organization, but in 2012 they took a large donation from the Internet Society and were basically brought under ISOCs umbrella (they were running out of money) :

“The Internet Society’s generous donation has fueled deep organizational change at W3C,” said Jeff Jaffe, W3C CEO. “We have strengthened our business model and broadened participation to accelerate the development of the Open Web Platform technology that is transforming industry.”

In 2011, one of the ways in which W3C reached out to new stakeholders was through new Community Groups and Business Groups. A W3C Community Group is an open forum, without fees, where Web developers and other stakeholders develop specifications, hold discussions, develop test suites, and connect with W3C's international community of Web experts. A W3C Business Group gives innovators that want to have an impact on the development of the Web in the near-term, a vendor-neutral forum for collaborating with like-minded stakeholders, including W3C Members and non-Members. In just four months, more than fifty groups have been created or proposed.

This does not sound like "deep organizational change at W3C," or particularly open in nature. I think that interested parties should comment / complain to the ISOC Board of Trustees.

He said, "Internet," which predates Berners-Lee's contributions by fifteen years. And we all know Al Gore invented it! Although some maintain it was Vint Cerf and Bob Kahn.

No, it is not validly cached, at least not in any useful sense given the sea of caching proxies and user agents in the field. The headers presented merely hint that discretionary caching is okay, and do nothing to encourage caching either by proxies nor end user agents, nor inform such recipients of additional criteria which affects these factors. Please read RFC 2616 and come back when you're done.

I'm not confusing anything. I've actually written a caching proxy from scratch, and there's a difference between saying the content could be cached and aggressively encouraging it. The headers are incomplete in this regard. Please refer to RFC 2616.

Indeed. Encrypted Media Extensions, W3C First Public Working Draft 10 May 2013:

This proposal extends HTMLMediaElement providing APIs to control playback of protected content.

The API supports use cases ranging from simple clear key decryption to high value video (given an appropriate user agent implementation). License/key exchange is controlled by the application, facilitating the development of robust playback applications supporting a range of content decryption and protection technologies.

This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems. Implementation of Digital Rights Management is not required for compliance with this specification: only the simple clear key system is required to be implemented as a common baseline.

That rationale (as I've heard it explained) is that media (video/audio) content distributors are going to implement DRM, so the Hobson's choice is between giving them a standard interface (HTML EME) or having every distributor create their own proprietary media player (probably platform-specific with embedded rootkit).

If you believe that all media should be gratis, or you believe that all media should be open and consumers should be trusted to pay for non-gratis media absent any technological protection, then you will view EME as a bad thing.

If you believe that Copyright should be able to exist on media and that authors and/or distributors should be able to charge for the video/audio, and you believe that technological protection measures may have some impact to reduce non-paid use of such media, and you believe that it is in the interest of consumers to have standards for these sort of things, then you may view EME as a good thing.

It is programmed by a set of open standards which gives any person or organization the tools to build support for the content which is relevant to society.

I think you need to lay off the koolaid man.

JPEG and GIF both have licensing issues; They are not free. The intended replacement for these, PNG, hasn't seen widespread adoption, can't do animations, but has no licensing issues. In fact, if you take a walk down a list of all the multimedia technologies commonly used on the web, MP3, MPEG4, h.264, AAC, surround sound... you will find yourself in a veritable desert when it comes to truly free standards. The standards may be 'open', that is, published... but a loose coalition of companies control all the key pieces.

In fact, the W3C, responsible for HTML, XML, CSS, etc., standards only two days ago decided to make documents about those standards available under an 'open source' license... optionally. Oh, but it gets worse. They're planning on introducing DRM and proprietary tech directly into the HTML5 standard; While you could conceivably use free technology, only the proprietary codec that will eventually be chosen for audio and video is guaranteed to be available on any HTML5-compliant browser.

A video game, designed in web standards, could be preserved for centuries by whoever deems it culturally relevant.

Copyright though means that they won't be able to even consider preservation for centuries, however. Many software licenses don't allow for backup copies... and it is highly doubtful you'll be able to keep that DVD you purchased it on alive for the next "150 years plus the life of the author", along with the equipment to read it, and some kind of adapter technology so that when the copyright finally expires, it might actually have a shot at being preserved.

If the W3C, or an industry body like them, creates an equivalent pseudo-native app platform... then great. For now, the web is the best we have.

What we have is a dystopian nightmare world of competing proprietary technologies, very little free/open alternatives, and billions being poured into the working groups responsible for setting these standards to ensure that every company involved gets a slice of the pie... meaning by the time they've gotten fat off their fill, you, the artist, will be starving. Again. Because before you can create art, you better pay a licensing fee, publishing fee, content storage fee, protection fee (for the drm to protect your art, of course), and ongoing monthly fees to your ISP.

No. Sorry, "the best we have" is not the web... it's stone tablets. Because those are about the only things someone doesn't have a patent on.

I think you are mistaken. Here's a 1992 draft of HTML without IMG support:

http://lists.w3.org/Archives/Public/www-talk/1992MayJun/0020.html

Here's another in November 1992 still without IMG tags:

http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html

By early 1993 NCSA was working on Mosaic and it now included IMG support.

I think you are mistaken. Here's a 1992 draft of HTML without IMG support:

http://lists.w3.org/Archives/Public/www-talk/1992MayJun/0020.html

Here's another in November 1992 still without IMG tags:

http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html

By early 1993 NCSA was working on Mosaic and it now included IMG support.

So FTP (ftp:) and Email (mailto:) and Gopher (gopher:) are all the WWW?

Anything with a URI is on the WWW.

The WWW is the service that uses hyperlinks and URLs (which point away from the WWW).

URIs do not point away from the WWW, they reference resources on the WWW. Anything with a URI is part of the WWW, a URI pointing "away" from the WWW doesn't make sense. By giving something a URI, you are incorporating it into the WWW.

Since I can't follow a hyperlink from my POTS phone, it's not part of the WWW.

No, it just means that it's a leaf node. You can't follow a hyperlink from a JPEG image, does that mean that there are no JPEG images on the WWW?

Even Berners-Lee described it as a service running on the internet.

Go read Architecture of the World Wide Web , which was part-authored by Tim Berners-Lee. Or read some of his earlier work that this document was based upon, for instance Universal Resource Identifiers -- Axioms of Web Architecture , where he writes:

The Web is a universal information space. It is a space in the sense that things in it have an address. The "addresses", "names", or as we call them here identifiers, are the subject of this article. They are called Universal Resource Identifiers (URIs).

An information object is "on the web" if it has a URI.

So FTP (ftp:) and Email (mailto:) and Gopher (gopher:) are all the WWW?

Anything with a URI is on the WWW.

The WWW is the service that uses hyperlinks and URLs (which point away from the WWW).

URIs do not point away from the WWW, they reference resources on the WWW. Anything with a URI is part of the WWW, a URI pointing "away" from the WWW doesn't make sense. By giving something a URI, you are incorporating it into the WWW.

Since I can't follow a hyperlink from my POTS phone, it's not part of the WWW.

No, it just means that it's a leaf node. You can't follow a hyperlink from a JPEG image, does that mean that there are no JPEG images on the WWW?

Even Berners-Lee described it as a service running on the internet.

Go read Architecture of the World Wide Web , which was part-authored by Tim Berners-Lee. Or read some of his earlier work that this document was based upon, for instance Universal Resource Identifiers -- Axioms of Web Architecture , where he writes:

The Web is a universal information space. It is a space in the sense that things in it have an address. The "addresses", "names", or as we call them here identifiers, are the subject of this article. They are called Universal Resource Identifiers (URIs).

An information object is "on the web" if it has a URI.

Sorry, WWW is the web - nothing else.

Of course. It's a tautology - the WWW is the WWW. That doesn't contradict anything I said and I'm not sure what you think you are pointing out.

tel URLs may be part of 'the web' in the sense that you may put tel:-links in your web pages -- but that doesn't make tel: or ftp: or telnet: or gopher: whatever other protocol identifier you may have "the web".

Anything addressable by URI is part of the web. All of those things are leaf nodes in the information space that is the web.

By listing those things, it sounds like you are thinking that the WWW is HTTP. The WWW is not a protocol. It's an abstract information space. This is the misconception I was trying to clear up in my earlier comment. HTTP is not the defining technical aspect of the web - URIs are, and URIs are not limited to HTTP.

The Web was invented at Cern, not the Internet - the Internet has been around long before then.

I know this. This doesn't contradict anything I said. The fact that something predates the web does not mean that the web cannot encompass it. Would you say that The Colosseum isn't in Italy because it existed before Italy?

I really don't think you understood what I was trying to explain. The WWW is an information space that describes a web of interconnected resources. Just because something is older than the web or just because it uses a particular protocol that isn't HTTP, it doesn't mean it can't be an entity in that information space. Read Architecture of the World Wide Web for more information on this.

Actually, the fact that HTML1 doesn't exist stops you. HTML2 was an attempt to document what browsers of the time rendered (i.e. it was descriptive, as opposed to the prescriptive HTML3 and later), but there was no HTML1.

HTML1 is the generally-accepted modern name for the format that was called "HTML" when it was originally designed, and is described in this document. Yes, it isn't a W3C recommendation, because W3C didn't exist when it was written. Nor is it an RFC, like HTML2 was. But that doesn't mean it didn't ever exist.

The real problem is everyone has been coming up with "Go buttons" but there was no decent "Stop button". So to stop some stuff but not others you have to make sure ALL the unwanted Go buttons" are not pressed. And that is not easy to do. Some people say "Use a library" the problem is how do you make sure future "Go buttons" that haven't been invented yet are not pressed either? And how about different browsers behaving differently?

So more than 10 years ago I proposed that a "Stop" "button" be created: http://lists.w3.org/Archives/Public/www-html/2002May/0021.html
http://www.mail-archive.com/mozilla-security@mozilla.org/msg01448.html

But there was no interest in such a thing till recent years with CSP: https://developer.mozilla.org/en/docs/Security/CSP

If the major browsers had implemented my simple suggestion years ago it would have been harder for the Yahoo, MySpace and other worms.

I had not heard about this new style sheet standard. Do I need to start to use it on my web sites ? Does it protect my sensitive information from the commies/taliban/mafia/... ? Which browsers support it ?

Firefox is making their own HTML5 APIs for manipulating the camera in Firefox OS and I believe they're trying to make it a w3c standard.

Except that Apple has the right to (and will likely) choose not to implement the proposed W3C photography API in Safari, just as it chose not to implement WebGL, to encourage developers to buy a Mac and pay the $99 + 30%. Apple has the power to prevent the technology from becoming mainstream.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Error codes are meant to be for technical reasons. Who cares WHY the page is not available. It's not available. That's technical & that's all.

I think the Wikipedia article is wrong. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Actually APNG is explicitly mentioned as a supported format for the image tag in the HTML5 spec.
http://www.w3.org/TR/html5/embedded-content-0.html#the-img-element
Search for "APNG".

You're repeating yourself when you could easily test your hypothesis. I just tried and got a 17% improvement. W3C says "PNG also compresses better than GIF in almost every case (5% to 25% in typical cases)."

No, I was referring to the standard as specified 5 months before IE10 came to be

Yes, that's correct. Now ask yourself why JavaScript need enter in to it at all? (Are you going to advocate browser detection? You'll find more than enough on comp.lang.javascript about that bad practice!)

I don't know, dynamically change the element's CSS depending on the resolution and orientation?

If that becomes a need, chances are you've already failed. When it makes sense, which is rare, you'll find mobile browsers more than capable thanks to long-standing and broad CSS3 support across the major platforms.

As for the handheld media type, your article is woefully out-of-date. CSS3 Media Queries are far from "non-standard" in case you didn't know. (I should also point out that for mobile devices, in virtually all cases, it's not necessary to change your CSS at all. If you found some bizarre case where that was necessary, using the outdated handheld media type wouldn't make sense anyway!)

And you want to use a heavy-weight JavaScript library to "fill in the gaps" (that likely don't exist) on a subset of antique devices where you might find a minor layout problem? That's insane. I'll take it a step farther and guarantee that you'll find more "gaps" using JavaScript for layout on old mobile devices than you will with CSS.

Anyhow, I'm not going to argue with you about this. It's clearly going to be a huge a waste of my time. Unless your incompetent, you'll figure this out on your own eventually.

Good luck.

Wrong. Since I follow the situation closely, let me explain.

The HTML5 Web Notifications API is in Chrome since forever under webKitNotifications.

The first draft spec of Notifications API included both icon-and-text simplistic notifications, and HTML notifications which were in fact just tiny windows that popped up.
Chrome implemented both, extension authors happily started using it.

Next, W3C drops HTML notifications from the draft. Chrome then drops it from the web context, but keeps it for extensions: they didn't want to suddenly break legacy apps, I guess. They didn't even mark it as deprecated until not long ago.

Fast forward a few releases. Chrome wants its own notifications center, and drafts a new Rich Notifications API. Long experimental, this finally hit Stable.

However.. Despite being touted as a replacement for HTML notifications, those don't come even close to customization possibilities of an arbitrary HTML page, with its own code running. And Google decided to make a hard switch: a browser version has either Rich or HTML notifications enabled. So, if the feature hit you, your old notifications keel over and die immediately.

But that's not the worst problem here. The worst problem is sudden fragmentation. Windows and Chrome OS have the new Rich notifications and do not have HTML ones anymore. OS X and Linux do not have Rich notifications but support HTML ones. See the problem? And despite saying that it will come to other platforms "soon" this isn't in Beta yet for sure, and possibly not even in the Dev branch, but don't quote me on that. So to even maintain both systems I now need two OSes.

Because the whole point of the W3C is to make the web more accessible by forging out standards.
Like you don't need to install a Jpeg or Png* plugin for Firefox.

By adopting a standard that relies on vendor specific Content Decryption Modules (CDMs) the EME "standard" is not better then a Flash pugin. It does not improve the open web. It actually integrated the status quo in the web and gets the blessing of the W3C. The status quo in this case is that you need to have a binary proprietary patent infected plugin in order to enjoy "premium" content.

*Png http://www.w3.org/Graphics/PNG/
*Jpeg http://www.w3.org/Graphics/JPEG/

Because the whole point of the W3C is to make the web more accessible by forging out standards.
Like you don't need to install a Jpeg or Png* plugin for Firefox.

By adopting a standard that relies on vendor specific Content Decryption Modules (CDMs) the EME "standard" is not better then a Flash pugin. It does not improve the open web. It actually integrated the status quo in the web and gets the blessing of the W3C. The status quo in this case is that you need to have a binary proprietary patent infected plugin in order to enjoy "premium" content.

*Png http://www.w3.org/Graphics/PNG/
*Jpeg http://www.w3.org/Graphics/JPEG/

It appears that others in the W3C mailing lists have in fact objected to the implementation of DRM in HTML5.

They were instead shunted off to 'more appropriate forums' to discuss their objections.

There are literally hundreds of emails there to plow through. Although there are many strong objections raised by different parties, the one who really seems to be pushing DRM is Netflix.

Even the EFF have formally objected to the DRM scheme.

It also appears that the CEO of W3C is the one who made the decision.

Are concerns taken seriously on the other mailing list, or is it a spot
to send people to voice their concerns with other likeminded people?

This discussion has gone all the way up to the CEO of the W3C, and
that's where he has requested that the discussion take place. Given
that this is ultimately a CEO decision, if you want to effect a change,
following his advice makes the most sense.

The current W3C CEO is Dr. Jeffrey Jaffe.

So in a nutshell, if you're wondering who to blame for EME in HTML5, thats the story.

It appears that others in the W3C mailing lists have in fact objected to the implementation of DRM in HTML5.

They were instead shunted off to 'more appropriate forums' to discuss their objections.

There are literally hundreds of emails there to plow through. Although there are many strong objections raised by different parties, the one who really seems to be pushing DRM is Netflix.

Even the EFF have formally objected to the DRM scheme.

It also appears that the CEO of W3C is the one who made the decision.

Are concerns taken seriously on the other mailing list, or is it a spot
to send people to voice their concerns with other likeminded people?

This discussion has gone all the way up to the CEO of the W3C, and
that's where he has requested that the discussion take place. Given
that this is ultimately a CEO decision, if you want to effect a change,
following his advice makes the most sense.

The current W3C CEO is Dr. Jeffrey Jaffe.

So in a nutshell, if you're wondering who to blame for EME in HTML5, thats the story.

It appears that others in the W3C mailing lists have in fact objected to the implementation of DRM in HTML5.

They were instead shunted off to 'more appropriate forums' to discuss their objections.

There are literally hundreds of emails there to plow through. Although there are many strong objections raised by different parties, the one who really seems to be pushing DRM is Netflix.

Even the EFF have formally objected to the DRM scheme.

It also appears that the CEO of W3C is the one who made the decision.

Are concerns taken seriously on the other mailing list, or is it a spot
to send people to voice their concerns with other likeminded people?

This discussion has gone all the way up to the CEO of the W3C, and
that's where he has requested that the discussion take place. Given
that this is ultimately a CEO decision, if you want to effect a change,
following his advice makes the most sense.

The current W3C CEO is Dr. Jeffrey Jaffe.

So in a nutshell, if you're wondering who to blame for EME in HTML5, thats the story.

It appears that others in the W3C mailing lists have in fact objected to the implementation of DRM in HTML5.

They were instead shunted off to 'more appropriate forums' to discuss their objections.

There are literally hundreds of emails there to plow through. Although there are many strong objections raised by different parties, the one who really seems to be pushing DRM is Netflix.

Even the EFF have formally objected to the DRM scheme.

It also appears that the CEO of W3C is the one who made the decision.

Are concerns taken seriously on the other mailing list, or is it a spot
to send people to voice their concerns with other likeminded people?

This discussion has gone all the way up to the CEO of the W3C, and
that's where he has requested that the discussion take place. Given
that this is ultimately a CEO decision, if you want to effect a change,
following his advice makes the most sense.

The current W3C CEO is Dr. Jeffrey Jaffe.

So in a nutshell, if you're wondering who to blame for EME in HTML5, thats the story.

It appears that others in the W3C mailing lists have in fact objected to the implementation of DRM in HTML5.

They were instead shunted off to 'more appropriate forums' to discuss their objections.

There are literally hundreds of emails there to plow through. Although there are many strong objections raised by different parties, the one who really seems to be pushing DRM is Netflix.

Even the EFF have formally objected to the DRM scheme.

It also appears that the CEO of W3C is the one who made the decision.

Are concerns taken seriously on the other mailing list, or is it a spot
to send people to voice their concerns with other likeminded people?

This discussion has gone all the way up to the CEO of the W3C, and
that's where he has requested that the discussion take place. Given
that this is ultimately a CEO decision, if you want to effect a change,
following his advice makes the most sense.

The current W3C CEO is Dr. Jeffrey Jaffe.

So in a nutshell, if you're wondering who to blame for EME in HTML5, thats the story.

http://www.w3.org/People/Jeff/ I'm emailing him to tell him that DRM content is walled off from the web. DRM is not open content and has no place on the web. Let content providers who do not adapt die off. Doesn't matter if they are large movie studios or not.

This has been discussed before. The idea is to provide extensions to allow DRM to be implemented without plugins. See:
http://arstechnica.com/business/2013/05/drm-in-html5-is-a-victory-for-the-open-web-not-a-defeat/
http://www.w3.org/TR/2013/WD-encrypted-media-20130510/

Sounds like this is locked into windows via the Media Foundation APIs

There may be lock in, but it's not exclusive to Microsoft:

Media Source Extensions (MSE) This specification extends HTMLMediaElement to allow JavaScript to generate media streams for playback. Allowing JavaScript to generate streams facilitates a variety of use cases like adaptive streaming and time shifting live streams.

Encrypted Media Extensions (EME) This proposal extends HTMLMediaElement providing APIs to control playback of protected content.

Web Cryptography API (WebCrypto) This specification describes a JavaScript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption.

They're all W3C standards track specifications. The first two have editors from the same three corporations; Google, Microsoft and Netflix. Google, in particular, can't tolerate not being capable of playing Netflix (10% of the population of the US subscribes to this) on its platforms (Android and Chrome OS.) It already works on both and you can take it for granted that Google expects to achieve parity with these specifications.

The last specification is not specific to streaming; it's a general purpose Javascript API to perform common cryptographic operations.

Sounds like this is locked into windows via the Media Foundation APIs

There may be lock in, but it's not exclusive to Microsoft:

Media Source Extensions (MSE) This specification extends HTMLMediaElement to allow JavaScript to generate media streams for playback. Allowing JavaScript to generate streams facilitates a variety of use cases like adaptive streaming and time shifting live streams.

Encrypted Media Extensions (EME) This proposal extends HTMLMediaElement providing APIs to control playback of protected content.

Web Cryptography API (WebCrypto) This specification describes a JavaScript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption.

They're all W3C standards track specifications. The first two have editors from the same three corporations; Google, Microsoft and Netflix. Google, in particular, can't tolerate not being capable of playing Netflix (10% of the population of the US subscribes to this) on its platforms (Android and Chrome OS.) It already works on both and you can take it for granted that Google expects to achieve parity with these specifications.

The last specification is not specific to streaming; it's a general purpose Javascript API to perform common cryptographic operations.

Sounds like this is locked into windows via the Media Foundation APIs

There may be lock in, but it's not exclusive to Microsoft:

Media Source Extensions (MSE) This specification extends HTMLMediaElement to allow JavaScript to generate media streams for playback. Allowing JavaScript to generate streams facilitates a variety of use cases like adaptive streaming and time shifting live streams.

Encrypted Media Extensions (EME) This proposal extends HTMLMediaElement providing APIs to control playback of protected content.

Web Cryptography API (WebCrypto) This specification describes a JavaScript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption.

They're all W3C standards track specifications. The first two have editors from the same three corporations; Google, Microsoft and Netflix. Google, in particular, can't tolerate not being capable of playing Netflix (10% of the population of the US subscribes to this) on its platforms (Android and Chrome OS.) It already works on both and you can take it for granted that Google expects to achieve parity with these specifications.

The last specification is not specific to streaming; it's a general purpose Javascript API to perform common cryptographic operations.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2

Seems like it's mentioned there to me...

Maybe you should try reading the second link from the summary and take a look at the standard heads. What you would find is that the standard is "no-cache". Chrome and Firefox use the non-standard "no-store". But, guess which browser supports three different headers, and the only one to actually support the standard? IE.

Phil was one of the authors of the NNTP protocol. http://www.w3.org/Protocols/rfc977/rfc977

Wikipedia is the only site I know that does.

Which isn't surprising: none of the major browsers support srcset yet. Not even Safari, despite srcset being an Apple-designed standard. (The editor is an Apple employee and is the person who came up with this standard that no one except Samsung implements.)

Of course, there's very little point to implementing srcset as the use case for "hi-DPI images" is basically non-existent, so I suppose it's just as well that almost no one has bothered implementing a nearly worthless spec.

But I don't want these add-ons polluting a standard. This is what we have plug-ins for.

The plug ins that are... part of the standard? Because plugins are part of the HTML standard, the standard is already "polluted." I'm not sure how one could be fine with plugins in HTML, but freak out when we talk about plugins for video decoding. I mean, that's already the biggest use of the current plugin standard: decoding of videos.

http://www.w3.org/TR/html401/struct/objects.html

https://dvcs.w3.org/hg/html-media/raw-file/eme-v0.1/encrypted-media/encrypted-media.html

Note the line between CDM and Platform in the image.

The truckload of validation errors in iTunes web pages (to continue down the Call Me Maybe path, I checked the page for the album) don't help. The page has all the keywords it would need and is fairly well structured, so any search-placement improvements would have to come from valid HTML and fetid SEO.

But yeah, Google and friends can treat that problem by calling up Apple and negotiating to link iTunes directly to the crawler, something like how Google and Adobe got all loveydovey and *wham* now Google can read Flash. (I said treat; the cure would be to make the song files downloadable from the page, if for a fee, and be done with the whole RIAA love and general non-webbyness of iTunes and whatnot.)

No... I'm right.

Try this

That is only if there is a case where the media stack isn't overtaken and the frames are decrypted by the CDM and returned to the browser but the content producer has some requirement over protecting that pipeline too, the answer is for the CDM to also provide the container. You don't need to go closed-source.

It's standardising breakage... as I've already said, let the content companies and their flunkies do their own work. It shouldn't be part of HTML 5 and it is fundamentally at odds with open source browsers.

It's like any other plugin, just standardizing a plugin interface and not requiring an application to run in a whole platform like Flash or Silverlight which then runs in the browser. None of the DRM is part of HTML5.

No... I'm right.

Try this

You need to look at what this scheme actually is... not what they say it is.

It's standardising breakage... as I've already said, let the content companies and their flunkies do their own work. It shouldn't be part of HTML 5 and it is fundamentally at odds with open source browsers.

JS and HTML can't write files to the clients computer.

This may be true of JavaScript and HTML in IE pre-10, but the draft File API allows JavaScript programs to ask the browser to present a "Save As" file chooser and write to the file that the user chose. And because JavaScript's File API does access control through the file chooser, it doesn't require a code signing certificate from a commercial CA in order to be able to write such a file

So I ask again, what is the difference with EME? Sounds like you describe EME in detail.

EME is an API, and while open(ish), you can not implement it without carrying forward a ton of proprietary stuff (CDM).
Don't believe me? Prove me wrong. https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

The EME proposal don't even make it mandatory to return the decrypted content back to the browser.
"CDM implementations may return decrypted frames or rendered them directly."
Meaning, the CDM can just open a third application to show you the "protected" content.

Why would the people implementing web products listen to a standards body that didn't represent them? In any case w3c is fairly broad: http://www.w3.org/Consortium/Member/List

http://www.w3.org/TR/2013/WD-encrypted-media-20130510/#introduction

Pretty much everything in the picture is standardized and can be implemented by any browser, but the Content Decryption Module (CDM) can be anything, and is selected by keySystem from the DOM data. There is a single reference system that merely decrypts blocks of the stream. But you can pretty much just dump the decrypted blocks into a file. I'm sure all this will really accomplish is requiring people to download proprietary CDMs, or only allow browsers that ship with them like IE or Chrome to play content. This is a shit solution.

If the company has a system that works on IE6 but not on IE10, then they should not try to change IE6 for IE10 for that system. They should stick to that. It works, it will continue to work.

A better approach than changing for IE10 would be to aim for a standard that is supported by multiple vendors. For instance, HTML4 and JavaScript. See also
http://www.w3.org/TR/REC-html40/
http://en.wikipedia.org/wiki/JavaScript#Standardization
Of course there may still be minor quirks of the chosen browser, but accomodating those should be a much lesser task the next time the company needs to switch platforms.

Also, they might be able to use virtualized instances of XP as others have suggested. That may have its own drawbacks, but I guess it is worth a try before sinking lots of development money into redesigning the application.