13:56:28 RRSAgent has joined #me 13:56:28 logging to https://www.w3.org/2022/11/01-me-irc 13:56:32 Zakim has joined #me 13:56:35 Meeting: MEIG monthly meeting 13:57:03 kinjim has joined #me 13:57:26 kaz has joined #me 13:58:23 Hisayuki_Ohmata has joined #me 13:58:37 present+ Kaz_Ashimura 13:58:47 agenda: https://lists.w3.org/Archives/Public/public-web-and-tv/2022Oct/0003.html 14:00:24 tidoust has joined #me 14:01:45 igarashi has joined #me 14:01:59 present+ 14:05:31 present+ Chris_Needham, Chris_Lorenzo, Ewan_Roycroft, Francois_Daoust, FW, Hiroshi_Kajihata, Hisayuki_Ohmata, Tatsuya_Igarashi, Jordan, Kinji_Matsumura, Ryo_Yasuoka 14:05:38 present+ Pat_O'Neill 14:05:44 ewanr has joined #me 14:06:18 agenda: https://lists.w3.org/Archives/Public/public-web-and-tv/2022Oct/0003.html 14:06:51 Topic: Introduction 14:06:55 ChrisLorenzo has joined #me 14:07:18 Chris: Today we'll hear about TV application development at the BBC 14:07:23 Topic: TV application development 14:07:33 i/Today/scribenick: cpn/ 14:07:49 Jordan: I work on TV iPlayer at the BBC. Firstly, will talk about how it's built 14:08:08 ... We have one codebase across all devices, with configurations to perform optimally across devices 14:08:29 ( TAL = TV Abstraction Layer ) 14:08:38 ... We had a TV abstraction layer (TAL), an opinionated approach. We've now extracted out different parts 14:09:14 ... A device specific configuration, CSS transforms, etc. For our UI we have JSX and CSS components, a mix of server side and client side rendered 14:09:18 ... Logic is vanilla JS 14:09:45 ... For playback we use our open source player. Some UI libraries, for our design system, which will be open sourced 14:10:01 ... LRUD Spatial for spatial navigation. Arnold, handles back journeys in the application 14:10:44 ... Any code targeting the TV environment is transpiled to ES5.1. We can write in TS or ES6. A linter runs on the built output to detect if any problematic or unimplemented APIs are used 14:10:57 ... The bundle uses Webpack or Rollup, for tree shaking and code splitting 14:11:15 ... We have a certification process for browsers against our own spec 14:11:51 ... We have a sandbox environment for local development. Our UI components are SASS and JSX, which allow us to common web development tools such as Storybook, to share with our UX team 14:12:15 ... In our design system, the compiled CSS adds appropriate vendor prefixes, depending on the device 14:12:34 ... The system contains a normalised stylesheets which overrides some of the agent-specific weirdness 14:12:58 ... Disparity with SVG feature support, we arrived at through trial and error 14:13:21 ... Testing, we have a specification that guarantees a minimal set of support accross devices 14:14:06 ... For newer features, we have device compatibility experiments. Run arbitrary code during aplication load, we populate an MDN style compatibility matrix for TVs, tells us which APIs or CSS features works or which devices are problematic 14:14:20 ... We can use that to hold back certain features on devices that don't support 14:14:51 ... We have a test harness for each webpage, runs in an isolated docker container, with pupeteer integration tests, take screenshots to verify 14:15:32 ... We also have manual testing. Running on 400+ devices is a huge test burden, we can't do that. Instead we have canary devices in the office, which are indicative of whether a feature will work across a wider range of devices 14:15:45 ... For example a specific historic WebKit version 14:16:18 ... Anything that we test that isn't well supported, we hold back through config. Avoids device-specific logic tests. It's capability test driven 14:16:35 ... Deployment. App may be pre-installed, or installable from a device specific store 14:17:05 ... We use a lightweight wrapper app that points to a well known URL. Points to a config that delivers a configured application. We use the user agent string to identify the device 14:17:13 ... Opportunities for standardisation 14:17:53 ... First one, already explored is spatial navigation. LRUD spatial is our library, a generic solution, to be open sourced 14:18:18 ... Our implementation is HTML attribute based, if you want specific behaviours you need to write your markup in a certain way 14:18:36 ... CSS SpatNav spec from 2017, good to revisit that 14:19:26 ... Non functional requirements, hard to define, hard to measure reliably 14:19:41 ... With CSS transitions, a device can be spec compliant even if it only runs at 1fps 14:19:55 ... Fallback, if a device doesn't support, elements will just snap to space 14:20:12 ... If a device performs poorly, better not to enable 14:20:49 ... Canvas animation, with our boot-up start application, some devices crashes when rendering. If there's a way to query maximum size, developers could use it across a wider range of devices 14:21:25 ... Currently rely on user agent to pair the app with device-specific config. Can't rely on feature detection in the app. Privacy concerns with UA string, and UA CH, but we do need a way to recognise the device 14:21:55 ... Remote debugging. Each page is isolated, test with puppeteer. Better if we can run against a set of representative engines 14:22:22 ... Running automated scripting tasks requires differnt integrations. Want a standardised approach to remote debugging 14:22:53 ... Application manifesets. There's Web App Manifest. Extending to add rich metadata to populate into app stores would help developers 14:23:40 JohnRiv has joined #me 14:23:53 ... System messaging. Allowing the host to notify of state changes. Voice events, looking at in HbbTV. Also Page Lifecycle API for more fine grained control of lifecycle events. Benefit from having a richer interface with the host, network conditions, etc 14:24:19 present+ John_Riviello, Nassar 14:24:39 cpn: you mentioned quite number of things 14:24:50 q+ 14:25:08 ... what's your thought on manifest suggestion? 14:25:42 cl: Comcast working on Comcast-specific device 14:26:12 ... how to standardize manifest files for different devices is important 14:26:19 ... for easier tests 14:26:32 cpn_ has joined #me 14:26:32 ... interested to see iPlayer app 14:26:45 ChrisL: Can you talk more about the code. Is it all HTML and CSS? 14:26:59 ... Is it open source? 14:27:01 i/you mentioned/scribenick: kaz/ 14:27:10 i/Can you talk/scribenick: cpn_/ 14:27:15 rrsagent, make log public 14:27:21 rrsagent, draft minutes 14:27:22 I have made the request to generate https://www.w3.org/2022/11/01-me-minutes.html kaz 14:27:24 Jordan: Elements are open source. Some building blocks, TAL is open source. We haven't open sourced the newer module components, but we plan to 14:27:52 ... For UI components, spatial navigation will be open sourced soon. The application self isn't open source 14:28:49 Jordan: [Demos iPlayer development] 14:29:02 ChrisL: Does it use standard ARIA tags for accessibility? 14:29:03 q? 14:29:06 ack c 14:29:12 q+ 14:29:26 Jordan: Spatial nav relies on semantic HTML. For screenreader support, we use ARIA labels 14:29:50 ... Some screen readers don't work so well, we only enable support on certain devices, but the ARIA tags are always there 14:30:14 ChrisL: You mentioned remote debugging not standardised. Which devices don't support the current standard? 14:30:54 Jordan: Chromium and Gecko, and opera devices with Presto have their own solution. So our tooling has allow for 5 different strategies for remote debugging 14:31:16 ... Sometimes the debuggers aren't available, manufacturers hesitant to open up ports on the device 14:31:31 ChrisL: Is it running in a specific browser or the pre-installed browser? 14:31:49 Jordan: Our app is just a webview that points to a URL. So using the pre-installed browser 14:32:53 ChrisL: Wondering about web performance, how many devices where you can use transitions? 14:33:36 Jordan: On performance, we do an annual assessment if we can use a library or framework. Trialed React and Preact, and others. Our UI is server-side rendered, not much dynamism when it hits the client 14:34:17 ... Exception is the playback UI, which is dynamic, so we use snap-dom (?), the underlying Vue.js DOM library. It's just the v-dom part, got decent performance from it 14:35:00 ... Problems typically are memory related, holding a large representation of the DOM in memory. Or code the libraries target don't transpile to ES5.1 so we'd need to write our own vendorised version of hte library 14:35:07 s/snap-dom (?)/Snabbdom 14:35:21 -> https://github.com/snabbdom/snabbdom#readme Snabbdom library 14:35:29 ... For device support, offloading to the GPU like ??, we're up to 60% of users on devices that support CSS transforms 14:35:52 ... Even there, hinting that older browsers like, will-change on a carousel, for example 14:36:05 ... Even within transform there are certain capabilities we turn on and off 14:36:37 ... We test manually. We haven't found an effective way to define an acceptable level of performance in our spec, and how much burden does it put on manufacturers? 14:36:59 ... We'd want to have a way of testing that isn't burdensome for manufacturers. A big area for investigation 14:37:26 ChrisL: WAVE group was looking at a test app, and to be certified you need to hit a benchmark 14:37:58 ChrisL: How do designers work with TVs? In Comcast we get designs with drop shadows, etc, things we can't do 14:38:32 Jordan: There's marketing, design, engineering. With current version of the UI there are marketing things that may not be possible. When designers look at it, they're more pragmatic 14:39:00 ... We push them to be more ambitios, not too limited. Start with high aim, then compromise down 14:39:19 ... Have you looked at Lighting framework, a canvas based renderer? 14:39:40 s/.../ChrisL:/ 14:40:27 ChrisL: Interested in your feedback. What is the development experience like building HTML and CSS? 14:40:48 Jordan: We spend a lot of time getting it performance, initial development time is quite small 14:40:48 -> https://lightningjs.io LightningJS 14:41:11 ... Figuring out the different levers to have in place, to get optimisation, then getting to a usable experience takes longer 14:41:43 ... We've had choice between rich impression stats, page heat maps, or better animation performance, you can't have both 14:41:57 ... So getting optimised on devices takes a lot longer than initial development 14:42:13 ... Is Lightning whole page or components? 14:42:29 ChrisL: It's components. Happy to talk further and give a demo and walk through 14:43:08 scribe+ 14:43:22 q? 14:43:46 cpn: You've covered quite a lot of ground. Re. Spatial Navigation, you mentioned open-sourcing your library. 14:43:55 ... Spec was pushed by LG. 14:44:14 ... If it can be done through script, to what extent would it be beneficial to standardize? 14:44:35 ... If it's because it's so common. Or does the library need to have lots of strategies to support all devices? 14:44:54 Jordan: I assume it would be more optimized if natively supported. 14:45:22 ... Our library's only dependency is on Element.getBoundingClientRect which is well-supported across browsers. 14:46:09 cpn: On remote debugging, you mentioned things being device-specific. Is there a standard that isn't widely supported. Or are there capabilities missing from the standard? 14:46:28 Jordan: Probably the de facto standard is Chrome's WebDriver implementation. 14:47:05 ... There is a Chromium spec, which moves quite rapidly, hard to tell what we can rely on. 14:47:12 q? 14:47:19 ack kaz 14:48:21 kaz: Also interested in Spatial Navigation. These days, Metaverse is getting more popular, maybe we may want to think about navigation within 3D video content, and including other types of devices such as smartphones. 14:49:03 Jordan: We don't currently run on any other devices that support more than left/right/top/down 14:49:15 ... but it definitely sounds like an opportunity to explore 14:49:57 kaz: I'm also involved in IoT standardization, interested in cross-group scenarios. 14:50:34 cpn: What could be done upstream to make sure that the standards are more interoperable before they get to you and trigger these interoperability issues. 14:50:46 s/including other types/including collaboration with other types/ 14:50:52 s/may want/might want/ 14:50:56 ... A question for everybody. 14:51:19 ... E.g. whether the set of test cases in test suites such as that developed by CTA WAVE are representative. 14:51:36 s/I'm also/Thanks! I'm involved/ 14:51:59 ... One of the things that I've heard in a previous presentation on that topic is that tests can take a long time to run. So question on how you identify relevant tests. 14:52:14 s/IoT standardization,/IoT standardization as well as Media Entertainment, so/ 14:53:11 ... The System messaging is also interesting. You talked about memory usage and I don't know whether that is covered in any W3C spec. 14:53:52 ... If in practice, constraints mean that some features cannot be used, it makes me wonder whether some kind of introspection mechanism would be useful. 14:54:06 ... Right now, you need to track user agents and configure features accordingly. 14:55:06 ... May be difficult to agree at the standards level. 14:56:02 q? 14:56:53 ChrisLorenzo: TV manufacturers try to bring performance at low cost, application developers need to struggle to get the max out of the device, etc. 14:57:10 ... It's hard to get all of the people involved going in the same direction. 14:57:20 ... Small moves will probably be needed. 14:57:57 cpn: Makes me wonder about some kind of baseline specification that could be targeted at TVs. 14:58:27 ... Clearly, content producers would benefit from having more end-to-end control over the experience. 14:59:18 ... The notion of shared runtime is an idea that we've been discussing but haven't reached a critical mass of supporters so far to push things forward. 15:00:00 JohnRiv: Confirming that there's interest is useful. That's what we're willing to do in the next couple of months. Feel free to reach out to ChrisL or myself. 15:00:40 cpn: I think that what we'd like to do is take some of the points you've raised and capture them. We're collecting good feedback here, and during our previous call from NHK. 15:00:54 ... That would allow us to look at next stages. 15:01:14 ... Two things: 1) common runtime, 2) what can we do about performance issues. 15:01:21 ... They're both worth considering at this stage. 15:01:58 ... Perhaps ChrisL and I could look at capturing this feedback in some document. 15:02:55 Jordan: Yes, there's future standards, and then there are standards already there that we should push to get supported. 15:03:28 cpn: For each of the capabilities that you've been raising, being able to say whether it's a standard problem, an adoption problem. 15:03:46 ... And documenting gaps, e.g. introspection for capabilities. 15:04:05 ... If anybody is interested in helping collect something like that, help would be welcome. 15:04:58 cpn: Thank you Jordan and everybody for joining! Look forward to seeing you all in the next meeting in December! 15:05:03 RRSAgent, draft minutes 15:05:03 I have made the request to generate https://www.w3.org/2022/11/01-me-minutes.html tidoust 15:05:13 present+ Andreas_Tai 15:05:27 rrsagent, draft minutes 15:05:27 I have made the request to generate https://www.w3.org/2022/11/01-me-minutes.html kaz