Re: [webkit-dev] HbbTV support within Webkit
A good start would be a freely available, free to implement, open standard. Adam On Oct 13, 2012 7:19 PM, "Graham Mudd" wrote: > 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 > > *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 wrote: > >> >> On Oct 11, 2012, at 7:40 AM, Mark Toller >> 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. >> >> Regards, >> Maciej >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev >> > > > +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. > > rb > > > > > > > > ___ > 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
Re: [webkit-dev] HbbTV support within Webkit
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. Regards Graham --- Original Message --- Sender : Randall Bennett 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev +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. rb ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
On Thu, Oct 11, 2012 at 12:16 PM, Maciej Stachowiak wrote: > > On Oct 11, 2012, at 7:40 AM, Mark Toller 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. > > Regards, > Maciej > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > +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. rb ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
On Oct 11, 2012, at 7:40 AM, Mark Toller 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
> -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. Regards, Mark. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
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? Dominik -- Dominik Röttsches ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
On Wed, Oct 10, 2012 at 3:50 PM, Kenneth Rohde Christiansen < kenneth.christian...@gmail.com> wrote: > Hi, > > I still don't get it. CE-HTML is a closed standard and not something > we ever want in WebKit as we are pushing HTML5/Living Standard. > Just to provide some additional input. CE-HMTL, more formally known as CEA-2014, is *not* a closed standard. It is available to anyone who wishes to pay CEA for a copy. In that respect, it is no different from ISO/ITU standards that sometimes cost money to obtain a copy. > > I understand that you need some execution and security model, but > apart from that I don't see why you don't aim at supporting HTML5 > instead of some custom dialect that is moving in another direction > that they rest of the industry. Even with the System Applications > working group [1], which Samsung is co-chairing, the execution and > security model will get solved with proper participation. > > Also the need for using XHTML isn't that big anymore, now that HTML5 > defines how to actually parse the document. > Rather than delving deeper into this proposal, I would suggest the original commenter should make some very specific technical proposals (accompanied by actual patches) that may satisfy his requirements, instead of simply propose support for the higher level notion of this profile. The merit of such individual technical proposals (patches) can be evaluated on a case by case basis, as is the case with other features proposed for addition to WK. Regards, Glenn ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
Hi, I still don't get it. CE-HTML is a closed standard and not something we ever want in WebKit as we are pushing HTML5/Living Standard. I understand that you need some execution and security model, but apart from that I don't see why you don't aim at supporting HTML5 instead of some custom dialect that is moving in another direction that they rest of the industry. Even with the System Applications working group [1], which Samsung is co-chairing, the execution and security model will get solved with proper participation. Also the need for using XHTML isn't that big anymore, now that HTML5 defines how to actually parse the document. Cheers Kenneth [1] http://www.w3.org/2012/05/sysapps-wg-charter.html On Wed, Oct 10, 2012 at 9:26 AM, Mark Toller wrote: > Hi, > > HbbTV and OIPF specifications are available to download from the HbbTV and > OIPF sites: > > http://www.hbbtv.org/pages/about_hbbtv/specification.php > http://www.oipf.tv/specifications > > The closed standard is the CE-HTML standard, which is referenced by OIPF. > The portions of CE-HTML used by HbbTV and OIPF are essentially a profile of > W3C standards and the AV Control plugin. > > We're currently looking at our changes to identify areas that can be > delivered back which can provide benefit to Webkit without causing any > additional maintenance overhead. > > 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)... As you can > imagine, most application authors are web developers, and do not necessarily > have experience with HbbTV, OIPF or CE-HTML, so they use the standard > W3C/HTML5/XHTML constructs they are familiar with, except for the TV > specific API's or plugins. More often than not, they'll write their > application so that it can also run on a PC browser, because they have far > better debugging facilities than TVs! However, as soon as the application is > signalled correctly with an HbbTV or CE-HTML mime type, most browsers then > just ask to download the page. Also, many test with a browser in 'HTML' > mode, and not the stricter 'XHTML' mode. > > Regards, > > Mark. > > -Original Message- > From: aba...@gmail.com [mailto:aba...@gmail.com] On Behalf Of Adam Barth > Sent: 08 October 2012 19:36 > To: Mark Toller > Cc: webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] HbbTV support within Webkit > > From your message, it sounds like HbbTV is still not an open standard. > I'm skeptical that we should support closed standards in WebKit. > > Adam > > > On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller wrote: >> Hi, >> >> >> >> I'd like to ask the Webkit developers their opinion on providing some >> support for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or >> "HbbTV", is a major new pan-European initiative aimed at harmonising the >> broadcast and broadband delivery of entertainment to the end consumer >> through connected TVs and set-top boxes. The HbbTV standard is proving to >> be very popular, TVs and STBs supporting HbbTV are shipping in huge > numbers >> throughout Europe. HbbTV is built on top of OIPF [2], which in turn is >> based on portions of CE-HTML [3]. >> >> >> >> Our lab, Samsung Electronics Research Institute (SERI), has been heavily >> involved in HbbTV and our current solution is based on Webkit. We would > like >> to provide our changes back to the community. >> >> >> >> I know that support requests for CE-HTML have been briefly touched upon in >> the past. As I understand it, the main objection to providing support > within >> WebKit is that the CE-HTML specification is not freely available, and thus >> restricts the number of developers who can fully understand it and > therefore >> provide fixes / support. >> >> >> >> In reality, much of the CE-HTML specification simply profiles which parts > of >> the W3C standard behaviour are mandatory, optional and/or recommended. > OIPF >> then profiles CE-HTML (dropping some requirements, extending others to > match >> W3C/HTML5), HbbTV profiles out even more of CE-HTML. >> >> >> >> Other parts of OIPF and CE-HTML do not need to be implemented within > Webkit >> itself. Some can be implemented as object plugins (e.g. AV Control and > local >> video), while others, such as the JavaScript classes required, can be >> inserted into the JavaScriptC
Re: [webkit-dev] HbbTV support within Webkit
Hi, HbbTV and OIPF specifications are available to download from the HbbTV and OIPF sites: http://www.hbbtv.org/pages/about_hbbtv/specification.php http://www.oipf.tv/specifications The closed standard is the CE-HTML standard, which is referenced by OIPF. The portions of CE-HTML used by HbbTV and OIPF are essentially a profile of W3C standards and the AV Control plugin. We're currently looking at our changes to identify areas that can be delivered back which can provide benefit to Webkit without causing any additional maintenance overhead. 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)... As you can imagine, most application authors are web developers, and do not necessarily have experience with HbbTV, OIPF or CE-HTML, so they use the standard W3C/HTML5/XHTML constructs they are familiar with, except for the TV specific API's or plugins. More often than not, they'll write their application so that it can also run on a PC browser, because they have far better debugging facilities than TVs! However, as soon as the application is signalled correctly with an HbbTV or CE-HTML mime type, most browsers then just ask to download the page. Also, many test with a browser in 'HTML' mode, and not the stricter 'XHTML' mode. Regards, Mark. -Original Message- From: aba...@gmail.com [mailto:aba...@gmail.com] On Behalf Of Adam Barth Sent: 08 October 2012 19:36 To: Mark Toller Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] HbbTV support within Webkit >From your message, it sounds like HbbTV is still not an open standard. I'm skeptical that we should support closed standards in WebKit. Adam On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller wrote: > Hi, > > > > I'd like to ask the Webkit developers their opinion on providing some > support for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or > "HbbTV", is a major new pan-European initiative aimed at harmonising the > broadcast and broadband delivery of entertainment to the end consumer > through connected TVs and set-top boxes. The HbbTV standard is proving to > be very popular, TVs and STBs supporting HbbTV are shipping in huge numbers > throughout Europe. HbbTV is built on top of OIPF [2], which in turn is > based on portions of CE-HTML [3]. > > > > Our lab, Samsung Electronics Research Institute (SERI), has been heavily > involved in HbbTV and our current solution is based on Webkit. We would like > to provide our changes back to the community. > > > > I know that support requests for CE-HTML have been briefly touched upon in > the past. As I understand it, the main objection to providing support within > WebKit is that the CE-HTML specification is not freely available, and thus > restricts the number of developers who can fully understand it and therefore > provide fixes / support. > > > > In reality, much of the CE-HTML specification simply profiles which parts of > the W3C standard behaviour are mandatory, optional and/or recommended. OIPF > then profiles CE-HTML (dropping some requirements, extending others to match > W3C/HTML5), HbbTV profiles out even more of CE-HTML. > > > > Other parts of OIPF and CE-HTML do not need to be implemented within Webkit > itself. Some can be implemented as object plugins (e.g. AV Control and local > video), while others, such as the JavaScript classes required, can be > inserted into the JavaScriptCore at runtime. > > > > What I propose is to provide the basic support required within Webkit in > order to at least load the XHTML portions of HbbTV applications and provide > the correct key handling to drive them. In order to provide 'full' HbbTV > support, implementations would need to provide the plugins and additional > JavaScript classes to complete the picture. > > > > For instance, by simply adding support for the document mime type handling > of application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV > applications will load and display the main page, and several will also > correctly navigate around the application correctly. > > > > Regards, > > > > Mark. > > > > [1] Hybrid Broadcast Broadband TV - http://www.hbbtv.org/ > > [2] Open IPTV Forum - http://www.oipf.tv/ > > [3] CEA, CEA-2014-A, Web-based Protocol Framework for Remote User Interface > on UPnP Networks and the Internet (Web4CE) > > > > > > > ___ > 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
Re: [webkit-dev] HbbTV support within Webkit
Adding support for custom variants of HTML is not really in line with the goals of the WebKit project. It sounds like CE-HTML and OIPF are both HTML variants. I don't think these types of features are a good fit for WebKit, because: (1) Custom HTML dialects tend to create excessive maintenance burden for the contributors who are not interested in the feature. WAP is a historical example. We much prefer features that either have broad mainstream interest, or at the very least can be implemented with minimal intrusion into core code. (2) Most contributors to the WebKit project strongly believe in a "One Web" vision, where the same full core specifications are used in all the contexts where Web technology is useful - no special dialects for mobile, or tv, or whatever, it's all one web. Custom HTML dialects go against that vision, so the value of adding support would have to be very high to even consider it. I strongly recommend that the HbbTV effort should use HTML5 and other Web technologies directly, rather than profiling and extending the Web. Regards, Maciej On Oct 8, 2012, at 7:11 AM, Mark Toller wrote: > Hi, > > I'd like to ask the Webkit developers their opinion on providing some support > for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or "HbbTV", is a > major new pan-European initiative aimed at harmonising the broadcast and > broadband delivery of entertainment to the end consumer through connected TVs > and set-top boxes. The HbbTV standard is proving to be very popular, TVs and > STBs supporting HbbTV are shipping in huge numbers throughout Europe. HbbTV > is built on top of OIPF [2], which in turn is based on portions of CE-HTML > [3]. > > Our lab, Samsung Electronics Research Institute (SERI), has been heavily > involved in HbbTV and our current solution is based on Webkit. We would like > to provide our changes back to the community. > > I know that support requests for CE-HTML have been briefly touched upon in > the past. As I understand it, the main objection to providing support within > WebKit is that the CE-HTML specification is not freely available, and thus > restricts the number of developers who can fully understand it and therefore > provide fixes / support. > > In reality, much of the CE-HTML specification simply profiles which parts of > the W3C standard behaviour are mandatory, optional and/or recommended. OIPF > then profiles CE-HTML (dropping some requirements, extending others to match > W3C/HTML5), HbbTV profiles out even more of CE-HTML. > > Other parts of OIPF and CE-HTML do not need to be implemented within Webkit > itself. Some can be implemented as object plugins (e.g. AV Control and local > video), while others, such as the JavaScript classes required, can be > inserted into the JavaScriptCore at runtime. > > What I propose is to provide the basic support required within Webkit in > order to at least load the XHTML portions of HbbTV applications and provide > the correct key handling to drive them. In order to provide 'full' HbbTV > support, implementations would need to provide the plugins and additional > JavaScript classes to complete the picture. > > For instance, by simply adding support for the document mime type handling of > application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV > applications will load and display the main page, and several will also > correctly navigate around the application correctly. > > Regards, > > Mark. > > [1] Hybrid Broadcast Broadband TV - http://www.hbbtv.org/ > [2] Open IPTV Forum - http://www.oipf.tv/ > [3] CEA, CEA-2014-A, Web-based Protocol Framework for Remote User Interface > on UPnP Networks and the Internet (Web4CE) > > > ___ > 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
Re: [webkit-dev] HbbTV support within Webkit
>From your message, it sounds like HbbTV is still not an open standard. I'm skeptical that we should support closed standards in WebKit. Adam On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller wrote: > Hi, > > > > I'd like to ask the Webkit developers their opinion on providing some > support for HbbTV [1] within Webkit. Hybrid Broadcast Broadband TV or > "HbbTV", is a major new pan-European initiative aimed at harmonising the > broadcast and broadband delivery of entertainment to the end consumer > through connected TVs and set-top boxes. The HbbTV standard is proving to > be very popular, TVs and STBs supporting HbbTV are shipping in huge numbers > throughout Europe. HbbTV is built on top of OIPF [2], which in turn is > based on portions of CE-HTML [3]. > > > > Our lab, Samsung Electronics Research Institute (SERI), has been heavily > involved in HbbTV and our current solution is based on Webkit. We would like > to provide our changes back to the community. > > > > I know that support requests for CE-HTML have been briefly touched upon in > the past. As I understand it, the main objection to providing support within > WebKit is that the CE-HTML specification is not freely available, and thus > restricts the number of developers who can fully understand it and therefore > provide fixes / support. > > > > In reality, much of the CE-HTML specification simply profiles which parts of > the W3C standard behaviour are mandatory, optional and/or recommended. OIPF > then profiles CE-HTML (dropping some requirements, extending others to match > W3C/HTML5), HbbTV profiles out even more of CE-HTML. > > > > Other parts of OIPF and CE-HTML do not need to be implemented within Webkit > itself. Some can be implemented as object plugins (e.g. AV Control and local > video), while others, such as the JavaScript classes required, can be > inserted into the JavaScriptCore at runtime. > > > > What I propose is to provide the basic support required within Webkit in > order to at least load the XHTML portions of HbbTV applications and provide > the correct key handling to drive them. In order to provide 'full' HbbTV > support, implementations would need to provide the plugins and additional > JavaScript classes to complete the picture. > > > > For instance, by simply adding support for the document mime type handling > of application/vnd.hbbtv.xhtml+xml and application/ce-html+xml, many HbbTV > applications will load and display the main page, and several will also > correctly navigate around the application correctly. > > > > Regards, > > > > Mark. > > > > [1] Hybrid Broadcast Broadband TV - http://www.hbbtv.org/ > > [2] Open IPTV Forum - http://www.oipf.tv/ > > [3] CEA, CEA-2014-A, Web-based Protocol Framework for Remote User Interface > on UPnP Networks and the Internet (Web4CE) > > > > > > > ___ > 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
Re: [webkit-dev] HbbTV support within Webkit
On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller wrote: > ** > > I'd like to ask the Webkit developers their opinion on providing some > support for HbbTV [1] within Webkit. > By "some support", what exactly do you mean? Our lab, Samsung Electronics Research Institute (SERI), has been heavily > involved in HbbTV and our current solution is based on Webkit. We would > like to provide our changes back to the community. > > I know that support requests for CE-HTML have been briefly touched upon in > the past. As I understand it, the main objection to providing support > within WebKit is that the CE-HTML specification is not freely available, > and thus restricts the number of developers who can fully understand it and > therefore provide fixes / support. > > ** > It also burdens other contributors who refactor and maintain that code. WML was a mess and imposed a significant maintenance cost on everyone who worked on script and input elements. In reality, much of the CE-HTML specification simply profiles which parts > of the W3C standard behaviour are mandatory, optional and/or recommended. > OIPF then profiles CE-HTML (dropping some requirements, extending others to > match W3C/HTML5), HbbTV profiles out even more of CE-HTML. > > ** ** > > Other parts of OIPF and CE-HTML do not need to be implemented within > Webkit itself. Some can be implemented as object plugins (e.g. AV Control > and local video), while others, such as the JavaScript classes required, > can be inserted into the JavaScriptCore at runtime. > I have a hard time understanding the exact requirement for supporting CE-HTML and HbbTV. What kind of changes do you want to make to the trunk WebKit? What I propose is to provide the basic support required within Webkit in > order to at least load the XHTML portions of HbbTV applications and provide > the correct key handling to drive them. In order to provide 'full' HbbTV > support, implementations would need to provide the plugins and additional > JavaScript classes to complete the picture. > Making WebKit more pluggable to support CE-HTML and HbbTV sound good to me as long as it doesn't significantly increase the maintenance burden on contributors. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] HbbTV support within Webkit
On Mon, Oct 8, 2012 at 7:11 AM, Mark Toller wrote: > I know that support requests for CE-HTML have been briefly touched upon in > the past. As I understand it, the main objection to providing support within > WebKit is that the CE-HTML specification is not freely available, and thus > restricts the number of developers who can fully understand it and therefore > provide fixes / support. For reference, here is a link to the previous thread: https://lists.webkit.org/pipermail/webkit-dev/2011-June/017195.html --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev