Meeting minutes
Goal of this session
[slide 3]
Martin: this session emerged from a discussion organized by the W3C China Team, with a focus on how to make the Web more performant
… this touched on enriching the ecosystem of web engines to increase efficiency and maximizing the user experience of the Web, ensuring the growth of the Web platform to create new tools & services
… while preserving accessibility, security, privacy, interoperability
… We've designated this activity under the working name of "high performance baseline" but are happy to change that name based on input
… we see needs to work with other existing efforts, miniapps, IoT/Web of Things
… We can see also use in the context of tools used for developing on the Web
… In terms of standards, we're exploring the idea of profile of standards, maybe with a new "Web core"
Adaptive Web Engines
Slideset: https://
VicYao: this started on performance considerations but has grown beyond those
… Much of this arises from changes brought by mobile internet
VicYao: the main source of Web traffic is no longer from browsers, but apps, including social media, news feeds, ecommerce platforms
… with the content embedded in fragments
… the internet is no longer a Web, but a chain of isolated islands, given the tendency of apps to keep users within their scope
Vic: despite that change, the Web has not changed a lot - it has been made compatible with mobile, rather than truly adapt to it
… the user interactions are very different on laptop vs mobile, which has lead to a terrible experience on mobile phone - noone likes to type URLs on a phone, and back/forward buttons aren't something you find in most apps
… the Web remains strong as a cross platform target, but there again there are now better alterantives
Vic: The Web exposes a complex and low performance platform
… which creates the risk of having the Web get stuck on desktop
… leading to increased fragmentation of the technology ecosystem, making "one web" meaningless
Vic: An idea that has been suggested is to subset web features, but I'm not convinced that will address the core of the issue
… My suggestion is instead to develop a completely new Web engine
… in that engine, Web applications would be distributed as packages, like apps and miniapps
… as packages, they can be embedded in apps, brought in real-time pages, and would support the mini-app ecosystem
… These packages would come with the good subset of CSS and APIs, remove the DOM
Vic: this could extend beyond phones and support the future of the Web
Modularity
Slideset: https://
Martin: an alternative approach we discussed is to develop a more modular approach to the Web, with profiles
… the platform is growing constantly, making it harder to develop new engines
… so we've been wondering if it would be possible to createa a profile with a subset of features, the same way miniapps have been doing for HTML & CSS
… there could be profile for other usages, e.g. IoT
… this could also be useful for helping with creating new engines which would target a useful profile, helping take an incremental approach
Martin: Miniapps use mostly a subset of CSS3 (+ a few additions), Ecmascript with a limited execution
Martin: in terms of markup, they're using a domain-specific language inspired by HTML (not aligned across implementations)
… and the APIs are platform specific, with functionality similar to Web APIs
Martin: Most miniapps are using APIs similar to Web APIs, with a different syntax but a similar purpose
… so existing Web standards could be used to fulfill MiniApps needs
… In terms of markup, the differences between miniapps markup languages and HTML are mostly stylistic, so this could be seen as mostly a subset of standards HTML
Martin: EPUB is another example of a successful profile
Martin: there were other attempts to profile the Web in the context of media destribution and consumer electronics
Martin: AMP is another example of a profile completed with custom components
… Baidu has a similar MIP (mobile instant pages)
Discussion
<Zakim> Mike, you wanted to comment
Mike: From a contributor of Ladybird, everything listed here is non-goal for Ladybird
… Ladybird is focused on working on everything available on the Web
… SW, media, everything should be the focus
<Mike5> https://
Mike: This was proposed 20 years ago at Compound Documents Workshop
… A new non-web browser thing (modular)
… WHATWG was created after that to protect the web platform and make the web evolve
… This won't be backward compatible. This is concerning.
Martin: It will be limited to an specific use case.
Mike: It's concerning that a web engine does not work backward compatible.
<McCool6> profiles as subsets; fallbacks e.g. server-side rendering; alternative renderings e.g. audio-only, low-frame rate (eink), etc.; WoT experience with profiles
Mike: Not imagine other vendors investing in this.
McCool: About the profiles, what is the conversion strategy.
… Regarding compatibility, new requirements based on server-side rendering...
… Use cases, there are cases for accessibility (e.g., audio only rendering).
… @@@
plh: What at a browser can do in comparison of native apps.
<Mike5> While it’s clear it’d be simpler to implement an engine that’s designed to only handle some subset of the web, the reason nobody so far is doing it is: You’d end up with an engine that only handles a subset of the web.
plh: browser give access to everything. Apps cannot. But UX may be better on native.
… Developers (us) may lazy so we use frameworks to simplify. Performance may depend on the implementation.
… Developer adoption is another point.
<Mike5> It doesn’t seem like actual end users want an engine that only handles a subset of the web. Instead they want an engine that can handle all the sites they are already normally using. And those sites aren’t using subsets of the web. Instead those sites are using the full feature set of the web.
plh: Question about packaging of the web engines?
<simon> Mike5: Isn't it an interesting proposal then to let the Browser communicate "I support this subset of technologies" so that the server can customize the - often already dynamically generated - content to the Browser making the request.
<simon> At least that's how interpret what McCool6 was saying, e.g. "If you have a browser on an eink device, maybe you need to tell the site that you cannot display colors."
plh: Security model for native and web is different. Nobody checks your web app
[it remains to be demonstrated that it is feasible to create an engine that can catch up with one of the 3 full-fledged engines]
plh: Native app store provide security checks
VicYao: I'll answer the question about packaging
… Most of the people visit the same websites.
Dom: clarification. Not the engines will be packaged, the apps will be packaged
VicYao: a website can be compiled into a package
<simon> xiaoqian: Are you suggesting that the web should have thing to behave like an appstore? What are you missing from e.g. PWAs?
VicYao: If the browser supports this package can load the package.
<Mike5> simon: Sites can already use feature detection to query a browser for “I support this subset of technologies" information. And sites already use that to customize content for the browser they’re delivering the content to.
VicYao: React Native as a framework simplifies the web standards (less HTML elements than the standards)
ydaniv: this seems to be similar to what Google did with NaCL, packaged apps, PWA
Martin: about distributing the apps in packages?
ydaniv: They have tried to distribute apps through packages.
VicYao: PWA does not change the performance of the existing web. Just add more features.
<Zakim> tidoust, you wanted to reflect on Web Media API example
tidoust: I want to reflect: I want to reflect the way the of the standards are created and implemented.
… convergence of implementation of WebMedia API and the full-fledge browsers
… In the Web devX (to be presented next session)
… You might need a subset but you need to plan the evolution to adopt the full web
… Covergence is key
Dom: What is the cost of supporting all the features, and the cost to preserve the UX?
… Breaking changes were unpopular. So support of the "legacy" content should be discussed
<tidoust> [asm.js, which led to WebAssembly, also comes to mind]
Dom: We have one Web
VicYao: React Native can be used to build any app, and easy to use.
… If Meta can do it, W3C can do it too
… Just install the WebView in the app and it works.
plh: Meta can do it but it doesn't mean that W3C should do
… JQuery features was also in a similar discussion in the past
… We don't need to standardize everything.
<plh> [imho, the success of a packaging system depends on how easy for the users to find the packages and use them]
<ydaniv> exit
<simon> So, is the main point to standardize a subset of web features?
rssagent, draft minutes
Martin: Thanks for attending we will continue the discussions in the CG: https://