WHATWG on 2023-07-19

01:20	<Domenic>	There has been a lot of development happening with HTML after "version 5". See https://github.com/whatwg/html/commits/main
04:51	<Antony Britto>	There has been a lot of development happening with HTML after "version 5". See https://github.com/whatwg/html/commits/main HTML 5 version released in 2014, past 9 years I did not heard about any new version? Why cant we add few features to handle backend API for web applications in HTML? That will make a lot more things more secure and address the data privacy concerns of users. At the time of HTML 3 in 1997 there was technology limitations to handle new features. As of 2023 we have powerful processors and large size storage and memory with pretty good internet connections with good bandwidth. Any thoughts guys?
04:52	<Antony Britto>	* Hi Everyone, I'm an enthusiast Django/React/Anguar developer with 25 years of experience in IT, mainly handling DevOps jobs and architect infrastructure solutions for deployment on cloud. I was thinking about whether we could add some functionalities to HTML to make it handle communication with backend APIs instead of using JavaScript to do the job. Would this make the frontend more secure for web applications and improve data privacy concerns of users? I've also been wondering why there hasn't been much development happening with HTML after version 5.
05:55	<Andreu Botella>	There has been constant changes to the HTML specification since then, which browsers have been regularly shipping, it just hasn't been released as major versions
05:56	<Andreu Botella>	the HTML standard is now a living standard, that gets regularly updated at https://html.spec.whatwg.org/multipage
05:57	<Andreu Botella>	https://whatwg.org/faq#living-standard
06:01	<Antony Britto>	There has been constant changes to the HTML specification since then, which browsers have been regularly shipping, it just hasn't been released as major versions May I know why cant we add few features to handle backend API for web applications in HTML? That will make a lot more things more secure and address the data privacy concerns of users. Is there any technological bottle neck?
06:03	<Andreu Botella>	if there is a way to make such a thing more secure and address privacy concerns, it might make sense to implement it, but I don't see how it would
06:03	<Andreu Botella>	could you expand some more?
06:06	<Antony Britto>	if there is a way to make such a thing more secure and address privacy concerns, it might make sense to implement it, but I don't see how it would Is it possible to communicate with backend API from HTML without the help of scripting languages?
06:06	<Andreu Botella>	I doubt so, since backend APIs are used for a lot of things, and I'm not sure how you'd cover most use cases for them without making the features that handle them a programming language unto itself
06:09	<Antony Britto>	I doubt so, since backend APIs are used for a lot of things, and I'm not sure how you'd cover most use cases for them without making the features that handle them a programming language unto itself As simple as get the data from the backend API and display it on the web page (this is what we do with web applications in simple terms.) with HTML without any scripting languages. Hope this is clear?
06:10	<Andreu Botella>	with no processing?
06:11	<Antony Britto>	with no processing? Server side processing? only validations happens at frontend right, no business logic in frontend
06:14	<Andreu Botella>	in my experience, there's a ton of business logic on the frontend
06:15	<Antony Britto>	in my experience, there's a ton of business logic on the frontend Those are the data privacy concerns.
06:17	<Andreu Botella>	also useful business logic
06:17	<Andreu Botella>	the thing is, this new API would have to be attractive enough to existing users so they want to move away from their current solution
06:17	<Andreu Botella>	and what you're describing would just remove functionality that those existing users would be using
06:18	<Andreu Botella>	script would still be a thing, so there wouldn't be any actual security or privacy benefits if no one is using this new API
06:19	<Antony Britto>	the thing is, this new API would have to be attractive enough to existing users so they want to move away from their current solution Why should we make them move, it is a personal choice and based on other requirements of the business.
06:20	<Antony Britto>	May I know why cant we add few features to handle backend API for web applications in HTML? Is there any technological bottle neck?
07:08	<Antony Britto>	Would it be possible to develop features for HTML to add interactivity to web pages, such as responding to user input, making changes to the content of the page, and loading new content from the server in a minimalist way? Most of these are possible with HTML except loading new content from the server. An example is a calculator made with HTML and CSS without any scripting. https://codepen.io/Lovkiy/pen/KxxmNj Would it be possible to make a feature in HTML to loading new content from the server?
07:20	<Andreu Botella>	that calculator does use javascript, it's in the `onclick` attributes
07:22	<Antony Britto>	Could you please elaborate on it? I could not see any JS in the codepen JS box. Anyway just curious. My real query is Would it be possible to make a feature in HTML to loading new content from the server?
07:27	<Andreu Botella>	the contents of the `onclick` attribute of `<input>` is evaluated as JS when you click on it
07:28	<Antony Britto>	the contents of the `onclick` attribute of `<input>` is evaluated as JS when you click on it Thanks I have no idea. :-)
07:29	<Antony Britto>	Would it be possible to make a feature in HTML to loading new content from the server?
07:30	<nicolo-ribaudo>	Yes it would be technically possible. The main blocker is that you have to convince browsers and the various other html stakeholders that it's a good idea, and explain in detail how it would work.
07:31	<Andreu Botella>	Technical feasibility isn't the end-all-be-all. And I'm not convinced of the security and privacy advantages you claim it would have
07:31	<Andreu Botella>	but yeah, feel free to file an issue at https://github.com/whatwg/html
11:04	<nicolo-ribaudo>	Domenic I'm not sure anymore that https://github.com/whatwg/html/pull/9520 is correct. Before that PR, the top-level worker module script was fetched with outside settings and its settings object was set to inside settings. Then, all its dependencies where fetched with inside settings and their settings object was inside settings. After that PR, all its dependencies are fetched with outide settings and their settings object is outside settings. where outside settings and inside settings are defined in https://html.spec.whatwg.org/#worker-processing-model Should the settings object of all the dependencies be inside settings instead, while keeping the fetch client as outside settings? Is it observable in any way?
11:05	<nicolo-ribaudo>	The behaviour after that PR matches the old behaviour before the modules loading refactor, but the fact that only the top-level module script has inside settings as its settings object seems weird to me
12:35	<Domenic>	Domenic I'm not sure anymore that https://github.com/whatwg/html/pull/9520 is correct. Before that PR, the top-level worker module script was fetched with outside settings and its settings object was set to inside settings. Then, all its dependencies where fetched with inside settings and their settings object was inside settings. After that PR, all its dependencies are fetched with outide settings and their settings object is outside settings. where outside settings and inside settings are defined in https://html.spec.whatwg.org/#worker-processing-model Should the settings object of all the dependencies be inside settings instead, while keeping the fetch client as outside settings? Is it observable in any way? Oh dang, oops. Yes, the fetch client should be outside settings, with the settings object being inside settings. That is pretty important. The observability is in the various callers of https://html.spec.whatwg.org/#classic-script . Sigh, sorry I missed that in review.
13:49	<nicolo-ribaudo>	Oh dang, oops. Yes, the fetch client should be outside settings, with the settings object being inside settings. That is pretty important. The observability is in the various callers of https://html.spec.whatwg.org/#classic-script . Sigh, sorry I missed that in review. I'll open an issue about it, but I will not work on a fix until after the params renaming PR is merged (given that every single line would conflict)
17:29	<Antony Britto>	Is it a good idea to think about making the existing form submission method in HTML can be like AJAX requests?