4 ms·

> 1 - We'll lose the W3C. We'll have to either create another standards body, or go back to the 90's situation when nobody agreed on anything. We already lost

by lambda 13y ago

> 1 - We'll lose the W3C. We'll have to either create another standards body, or go back to the 90's situation when nobody agreed on anything. We already lost the W3C once for about 10 years. Remember XHTML and XHTML2? Those, and a bunch of special purpose not particularly interesting niche XML standards (P3P? XML-FO?) were pretty much all they worked on for a decade or so. It wasn't until the WHATWG was formed by some browser vendors who wanted to start working on a standard for features that users would actually want, rather than what architecture astronauts thought would be a nice design, and the W3C realized that's what people were actually interested in and so replaced XHTML2 with HTML5 based on the WHATWG spec that they actually became relevant again. Now, I will have to give credit that there were still a few groups at the W3C doing work relevant to the actual open web, such as SVG and CSS. But given how the WHATWG took over work on the HTML standard and actually did work towards a standard that was useful and relevant to browser vendors when the W3C went off the rails the last time means that I'm not too worried if it goes off the rails again this time, you can always form another standards body if it becomes irrelevant. You just need to be sure to recognize this early on, so you don't waste too much time and effort waiting for the W3C to get its act together again.

cbhl 13y ago
> W3C realized that's what people were actually interested in So, with XHTML, the main thing is that people just wanted their web pages to work like they always had; they didn't want to deal with adding slashes to make their web pages XML and strict parsers and whatnot. But with P3P, what people want is Netflix and Rdio on all their devices (such as ARM-based Samsung Chromebooks). Frankly, I prefer the sound of standardized DRM to everyone rolling their own ala the 90s; with any luck it'll mean fewer formats/keys that need to be reverse engineered and whatnot.
- lambda 13y ago
  First of all, I think you have gotten P3P confused with EME (or whatever the new term is). P3P, the "platform for privacy protection" was just one of my examples of previous useless stuff the W3C has worked on (it was basically a schema for describing a website's privacy policy, with dubious advantages over simply linking to a privacy policy in the footer). Second, none of the proposals for EME that I've seen actually address the issue of being able to play the same content across devices. They aren't a standardized DRM scheme; they are merely hooks for proprietary DRM schemes, essentially a way to allow proprietary DRM schemes to hook into the HTML5 media player rather than having to use the plugin interface and implement the media player in Flash or Silverlight. It's basically just a plugin API for plugins that provide only DRM, leaving the rest up to the browser. Don't think that this is meant to actually increase interoperability; a large portion of the "value" of DRM, for those who promote it, it the ability to have various lucrative exclusive contracts with particular cable networks, hardware vendors, and so on. You're just going to see more "Live NFL - a Samsung exclusive!", not actually be able to get Netflix on any device you want. If it worked across any device, then it would need to work on open devices as well, but of course if the device is open you can bypass the DRM. So it's always going to be based on licenses, that only certain vendors can get if they promise to implement DRM securely and not give users full access to their own devices.
  - dragonwriter 13y ago
    > They aren't a standardized DRM scheme; they are merely hooks for proprietary DRM schemes, essentially a way to allow proprietary DRM schemes to hook into the HTML5 media player rather than having to use the plugin interface and implement the media player in Flash or Silverlight. It's basically just a plugin API for plugins that provide only DRM, leaving the rest up to the browser. Exactly: its a specification for a constrained plugin API focussed DRM, so that browsers don't have to either maintain a common general purpose plugin API (e.g., NPAPI) or, alternatively, have browser-specific APIs in order to meet content-owners demand for a DRM-supporting delivery channel.
  - cbhl 13y ago
    Yes, I typed the acronym wrong; that's what I get for writing HN comments in the middle of the night. I agree with the rest of what you've said, but I don't think the typical end-user worries about "openness" until it's too late.
johnbm 13y ago
> architecture astronauts That's an awesome term for something I never quite had a word for.
- lambda 13y ago
  I suspect this may be the article that introduced the term: http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html

by lambda 13y ago

cbhl 13y ago

> W3C realized that's what people were actually interested in So, with XHTML, the main thing is that people just wanted their web pages to work like they always had; they didn't want to deal with adding slashes to make their web pages XML and strict parsers and whatnot. But with P3P, what people want is Netflix and Rdio on all their devices (such as ARM-based Samsung Chromebooks). Frankly, I prefer the sound of standardized DRM to everyone rolling their own ala the 90s; with any luck it'll mean fewer formats/keys that need to be reverse engineered and whatnot.

lambda 13y ago
First of all, I think you have gotten P3P confused with EME (or whatever the new term is). P3P, the "platform for privacy protection" was just one of my examples of previous useless stuff the W3C has worked on (it was basically a schema for describing a website's privacy policy, with dubious advantages over simply linking to a privacy policy in the footer). Second, none of the proposals for EME that I've seen actually address the issue of being able to play the same content across devices. They aren't a standardized DRM scheme; they are merely hooks for proprietary DRM schemes, essentially a way to allow proprietary DRM schemes to hook into the HTML5 media player rather than having to use the plugin interface and implement the media player in Flash or Silverlight. It's basically just a plugin API for plugins that provide only DRM, leaving the rest up to the browser. Don't think that this is meant to actually increase interoperability; a large portion of the "value" of DRM, for those who promote it, it the ability to have various lucrative exclusive contracts with particular cable networks, hardware vendors, and so on. You're just going to see more "Live NFL - a Samsung exclusive!", not actually be able to get Netflix on any device you want. If it worked across any device, then it would need to work on open devices as well, but of course if the device is open you can bypass the DRM. So it's always going to be based on licenses, that only certain vendors can get if they promise to implement DRM securely and not give users full access to their own devices.
- dragonwriter 13y ago
  > They aren't a standardized DRM scheme; they are merely hooks for proprietary DRM schemes, essentially a way to allow proprietary DRM schemes to hook into the HTML5 media player rather than having to use the plugin interface and implement the media player in Flash or Silverlight. It's basically just a plugin API for plugins that provide only DRM, leaving the rest up to the browser. Exactly: its a specification for a constrained plugin API focussed DRM, so that browsers don't have to either maintain a common general purpose plugin API (e.g., NPAPI) or, alternatively, have browser-specific APIs in order to meet content-owners demand for a DRM-supporting delivery channel.
- cbhl 13y ago
  Yes, I typed the acronym wrong; that's what I get for writing HN comments in the middle of the night. I agree with the rest of what you've said, but I don't think the typical end-user worries about "openness" until it's too late.

johnbm 13y ago

> architecture astronauts That's an awesome term for something I never quite had a word for.

lambda 13y ago
I suspect this may be the article that introduced the term: http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html