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.
Regards
Graham
------- 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
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.
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.
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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
