Re: [w3ctag/design-reviews] TV-Specific Web Subsetting (#105)

> 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/105#issuecomment-379698506