Please forgive me if commenting is not appropriate as I'm not a TAG member but ...

• HbbTV is based on the intersection of Opera Presto and webkit from a couple of years ago with selected additions. Is this a subset? Depends on your definition of subset really.
• I very much doubt anyone removes anything from a browser as part of their HbbTV implementation. Does that make HbbTV browsers "full browsers"?

Here is the latest draft I can find of the HBBTV profile: http://www.oipf.tv/web-spec/volume5a.html

To directly address @jpiesing's questions:

• This is very much subsetting from the perspective of developers and browser vendors. An "environmental" issue here is the rate at which these devices update their software and/or keep pace with the overall web ecosystem. The web has suffered many bouts of runtimes falling off the pace. These situations have created pain for developers and users. The best-case scenario is one in which implementations continue to evolve with the "head" of standards.
• The concern here is that some features may be deprecated by still supported by HbbTV profiles. At a minimum, it's a concern that this is a separate, out-of-sync document.

Regards

I think this (second) sentence from the introduction:

Its goal is to describe a common profile that can be relied on by content and service providers and implemented by manufacturers.

makes it very clear that this is a subset, given that it says "implemented by manufacturers". I'd be substantially less concerned about a document that is more like Can I use... that is targeted at a specific market.

(There's still a separate issue about what makes that market different from the general Web, and whether that is its own problem.)

Discussed at the Boston f2f.

Resolved: @hadleybeeman will incorporate these thoughts into the evergreen web finding draft Resolved: @swickr will find W3C liaison with HbbTV, and ask them how to have a conversation with them.

We need to ping HBBTV (& ATSC?) about our evergreen web finding and start a discussion with them about it. We also need to see if we can push moving these architectures to a model that is more based on the progressive webapp model as opposed to an embedded web runtime (subset) model. We would invite them to work with us on designing APIs for device access.

Hi @swickr! We're reviewing things at our face-to-face. Any progress on this? Can we do anything to help?

(And for the record, here's the link to the Evergreen Web finding: http://www.w3.org/2001/tag/doc/evergreen-web/)

Let's try to drive some action out of this. Will revisit on 15 Aug.

Agreed to re-engage with @jpiesing.

Discussed at London f2f.

@jpiesing, we'd love to have a discussion with you or your colleagues from the HBBTV steering group about your vision for the future of HBBTV and how you envision it using/working with web technologies.

Can you join us on one of our weekly calls (we meet on Tuesdays at 15:00 UTC)? Let me know if one in the next few weeks would work.

@hadleybeeman I'd be glad to join one of your weekly calls. In principle I can do alternate Tuesdays starting on August 1st however August 15th is a public holiday for me in Belgium.

@jpiesing Apologies for the delay! We are still looking forward to talking with you and hearing your views on HBBTV.

We are currently meeting face-to-face for the next three days (Tues, Weds and Thursday) in Nice France. Would you be able to dial in at some point? Let us know if there is any time that works for you.

@hadleybeeman I'm in Belgium so in the same timezone as you. Any of the following could work;

• Before 1000 CEST on Wed 27th
• Between 1400 and 1600 CEST on Wed 27th
• Before 1100 CEST on Thu 28th
• 1300-1400 CEST on Thu 28th

I'm sorry, @jpiesing. We're nearing the end of our time and haven't been able to make this work on our end! Let's try again for a call soon... @torgo or @plinss will check the agendas and get back to us all soon.

I will take the action to try to ask hbb people to request a review from us of their new version which is not yet public.

@torgo Can I suggest also bringing this topic to the Media & Entertainment IG? cc @mavgit @tidoust

I will take the action to try to ask hbb people to request a review from us of their new version which is not yet public.

There is no new HbbTV spec version which is not yet public & there is no updated version of the underlying "Web Standards TV profile". There is a new version of the main HbbTV spec which references some additional web APIs but that's way too big for TAG to review and packed full of stuff that is specific to TV.

Personally I've not been pushing for a systematic update to the underlying list of web standards used in HbbTV as I was hoping that the CTA WAVE "Web Media API Snapshot" ( https://w3c.github.io/webmediaapi/ ) could be used instead. It remains to be seen whether that will be the case.

The browser(s) in a TV/media device are based on a fork of one of the web code-bases. I don't believe anyone removes features from the code to cut it down to match the "Web Standards TV profile". The most you might see is that web APIs which have an underlying OS dependency might not be usable and/or tested on a TV or other media device. APIs relating to desktop integration could be an example of this.

The main reason for making a list of APIs is to define a minimum baseline to discourage new devices from using really old versions of a browser just because it's what the manufacturer / integrator already has running. This is known to be a significant problem. New devices that use really old versions of browsers add cost for app developers as they force feature detection for features that have been standard in the web for ages and prevent re-use of code and libraries from the web.

A second reason for making a list of list of APIs is to enable scalable device testing/certification. Some content providers insist on testing web media devices before allowing their content to reach that device. Because of the previously mentioned problem with very old versions of a browser, this testing may include verifying that the baseline web APIs used by that content provider are supported. A common minimum baseline set of APIs could reduce the combinatorial explosion of testing web media devices and web media apps.

I know that in an ideal world, web media devices would just include the most recent version of their selected codebase and regularly update. Similarly in an ideal world, web media app developers & content providers would not feel the need to test their app/product on individual devices. Wishing for an ideal world doesn't get products in the market that run the key services which consumers want to use.

The Media & Entertainment Interest Group has its next conference call on May 1 at 14:00 UTC. It would be great to discuss this topic there. Would you both be available, @torgo, @jpiesing?

The Media & Entertainment Interest Group has its next conference call on May 1 at 14:00 UTC. It would be great to discuss this topic there. Would you both be available, @torgo, @jpiesing?

May 1st is a public holiday in many countries in mainland Europe.

Our calls are on the first Tuesday of each month, so we could possibly schedule this for the following one on June 5.

Our calls are on the first Tuesday of each month, so we could possibly schedule this for the following one on June 5.

@chrisn Very unfortunately I'm chairing an all day f2f meeting that day. July 3rd is no better.

Apologies that this took a whole 2.5 years for us to sort out.

Assuming that there is no new specification produced by HbbTV surrounding specifically the markup subsetting and there are quite a few devices shipping, I believe it does limit the surface of what we can review. It is exciting for us see web technology being used on a variety of devices, but as we have noted in our evergreen web finding, in the future we would like to see a future technology at some point that would have this built into the fundamental architecture.

Additionally, we were mildly disappointed to see a feature subset of web platform features - it would be great to prevent this from happening in the future. It is understandable that at the time of development there were hardware performance, memory and bandwidth constraints - but we have accomplished significant hardware and network infrastructure advancements in the past to a point that our next generation may not need to be as limited.

If you do have a newly minted specification at some point we would definitely be interested in providing you with a review, regardless of it being standardized through W3C or not.

Also, it is worth noting that there is a lot of new exciting technology on the platform that would be worth looking into.

The CTA WAVE project is publishing a periodic Web Media API Snapshot to provide a spec and associated test suite to help consumer electronics manufacturers keep their smart TVs and other consumer products in synch with the web platform. WAVE membership includes browser vendors, device manufacturers and media distributors.

The spec includes web APIs "that are supported across all four of the most widely used user agent code bases at the time of publication" which "will then be used to generate a test suite."

This spec is being developed in the Web Media API Community Group. The spec is being published under a W3C-CTA co-publishing agreement.

• Web Media API Snapshot 2017 was published last December on the CG site and by the CTA. The Web Media API Snapshot 2017 Test Suite is also available.

• Web Media API Snapshot 2018 is targeting a final review draft this Friday November 2, 2018.

Web Media API Snapshot 2018 includes a recommendation that manufacturers follow the TAG Evergreen Web finding:

Devices SHOULD regularly update their browsers, preferably automatically.

CTA WAVE has liaisons with television specification groups already referencing HTML5 or planning to reference it, including:

• Advanced Television Systems Committee (ATSC)...
• Hybrid Broadcast Broadband TV (HbbTV)
• IPTV Forum Japan
• Korean Ministry of Science, ICT and Future Planning (MSIP)

Notes:

1. The "specification is not defining a subset or profile to be used in place of the full Web platform. There are additional specifications that are included in all code bases that are not included in this specification... There is no suggestion that APIs not included in this specification should be removed from implementations."

2. I gave a lightning talk on the WAVE test suite at the recent TPAC 2018 AC meeting.