Title: Samsung Enterprise Portal mySingle

I think the objections to this are reasonable and it's probably worth a note on why we proposed this.

The problem with the HbbTV standard is that it's not just a paper spec anymore, it's now widely deployed in several European countries.

Germany is the leading market for HbbTV, but there are many other countries lining up to follow suit.

As a result, there are probably millions of CE devices out there which support HbbTV - and I'm pretty sure it will be tens of millions soon (if it isn't already).

There are also a large number of live apps now, with plenty more in development. I'm not sure if that qualifies as a "wealth of existing content", but it's there.

So for better or worse, as the developers of TV software we have to build HbbTV capability into our stack. And I know we aren't the only CE device maker using WebKit to do this, so we offered up the patches to see if there was any interest in incorporating them.

Now we have a definitive answer, we'll have to find a plan B.

Given your points about the direction of WebKit in general, we will raise these issues with the group that develops the standard. Maybe there are things that can be made more WebKit friendly in HbbTV 2.0.






------- Original Message -------

Sender : Randall Bennett<randall.benn...@gmail.com>

Date : Oct 12, 2012 21:20 (GMT+01:00)

Title : Re: [webkit-dev] HbbTV support within Webkit


On Thu, Oct 11, 2012 at 12:16 PM, Maciej Stachowiak <m...@apple.com> wrote:

On Oct 11, 2012, at 7:40 AM, Mark Toller <mark.tol...@samsung.com> wrote:

>> -----Original Message-----
>> From: Dominik Röttsches [mailto:dominik.rottsc...@intel.com]
>> On 10/10/2012 10:26 AM, Mark Toller wrote:
>>> What we would like to see initially is Webkit based browsers (Chrome,
>>> Safari, Minibrowser, etc) actually load HbbTV pages instead of asking
>>> the user to download the content - this would indirectly benefit the
>>> end goal of Webkit (to get everyone to support standard W3C/HTML5)...
>> This particular change is just a matter of adding one more displayable
>> mime-type, right?
> Almost. I've created a bug and patch for this particular change:
> https://bugs.webkit.org/show_bug.cgi?id=99049
> As someone else stated, I think the best approach is to create
> a bug for each change we consider worthwhile, and then they can be
> considered individually.

I don't think we should take this change or accept this feature in general. It seems that of those who have spoken up, the WebKit community is not in favor of this direction.

Even though the specific change in that patch is relatively small, supporting custom MIME types has significant disadvantages:

- Creates interoperability issues with other browsers.
- Fragments the web
- Opens us up to further requests to add support for similarly niche MIME types in the future

If CE-HTML and HbbTV content is fine to process as ordinary HTML, then it should be served with text/html MIME type. That would avoid all of these problems. If a consortium decided to create custom mime types instead, then they made a mistake and should fix it. In some cases, when the technology is compelling or there is a wealth of existing content, we live with arguable errors in the standard. But neither of those considerations applies here.


webkit-dev mailing list

 +1. As someone who builds applications specifically for TV producers, I feel that this custom mime type is the first in a series of bad moves.

Why doesn't the HBB group form its own W3 style group? I think this is just heading in the wrong direction.





webkit-dev mailing list

Reply via email to