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

Reply via email to