6 ms·

Has there been a serious attempt to define an html/css subset that achieves these kinds of goals? Something that a mere mortal could implement and would cover

Has there been a serious attempt to define an html/css subset that achieves these kinds of goals? Something that a mere mortal could implement and would cover the vast majority of web designs? I understand the urge to throw out the old and replace it with a new system, but that would be a huge blow to accessiblilty and adoption.

eitland 3y ago
I have been asking for a while if it could be a good idea to make something like asm.js but for webpages: Something to put in a meta tag or something early in the page that lets the browser know this webpage will only use a known-to-be-fast-and-predictable subset of html and css and only use js from a standardized library that provides things like autocomplete and other actually high value interactions.
- WorldMaker 3y ago
  You don't need JS for basic autocomplete in 2023, you can use "datalist" in HTML: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... A lot of basic high value interactions are more directly encoded in HTML today than a lot of developers expect to need JS for. Some other tags to pay attention to: summary/details, progress, meter, input type="color|date|time|datetime|range". It's an interesting relearning project, sometimes, how much the high level interactivity bits of HTML have changed since, for instance, the jQuery era.
  - eitland 3y ago
    > You don't need JS for basic autocomplete in 2023, you can use "datalist" in HTML: This does not seem to load data dynamically, it seems to be a way to show data from a predefined list?
    - WorldMaker 3y ago
      Most "basic" autocomplete isn't all that dynamic and you can prepopulate on the server side reasonably well. Sure, you still need JS to fetch a dynamic changing list, but you can also just update datalist options elements with JS rather than implement a full separate UX for autocomplete today. You are limited in the ability to CSS style datalist options so a lot of developers are still going to feel pressure in 2023 from "pixel perfect" UX designers to continue to reimplement that wheel, but the version of the JS that just updates a datalist after a fetch is likely much simpler than building a full "autocomplete control".
- khimaros 3y ago
  i'm interested in the answer to this question as well and did a bunch of searching a while back to no avail. maybe the world is waiting for us to start?
  - YoshiRulz 3y ago
    The tag is `<!DOCTYPE html>` and it should be the first line in the file/stream. Doing anything else will enable "quirks mode"[1]. Beyond that, the best thing you can do is avoid features that haven't been standardised yet or that were only standardised recently. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mode_and_Standards_Mode#how_do_browsers_determine_which_mode_to_use https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...
  - eitland 3y ago
    I have absolutely no idea about html rendering so my only contributions so far has been to ask/suggest to people who could know. But it is an idea that I keep getting reminded about. It could work adoption wise, since if it can be done technically it can be adapted independently of everyone else on backend and frontend: - backwards compatible, if a browser doesn't take advantage of it it renders completely ordinary and in supporting browsers if a website doesn't use this trick it just renders as any other website - If just one browser and one website does implement this then there will be a full setup. If the idea worked and for example Firefox supported this and Wikipedia or someone else took advantage of it suddenly everyone who used Wikipedia would se faster load and less battery usage.
    - khimaros 3y ago
      my assumption is that this would be a strict subset of existing HTML/CSS/JS so that existing browsers would work without modification. but a small enough subset that hobbyist browsers could realistically implement the entire standard. it may make sense to look at browsers such as elinks and dillo for defining that subset.
- its-summertime 3y ago
  https://amp.dev/ https://amp.dev/ is that. No one wants to use it because the very first line of the mandatory js file is about advertising metrics.
  - eitland 3y ago
    There are reasons why I didn't mention amp :-) amp isn't meant to solve our problem but Googles problems.
khimaros 3y ago
maybe a good starting point would be the subset which is supported by dillo or elinks today?

eitland 3y ago

I have been asking for a while if it could be a good idea to make something like asm.js but for webpages: Something to put in a meta tag or something early in the page that lets the browser know this webpage will only use a known-to-be-fast-and-predictable subset of html and css and only use js from a standardized library that provides things like autocomplete and other actually high value interactions.

WorldMaker 3y ago
You don't need JS for basic autocomplete in 2023, you can use "datalist" in HTML: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... A lot of basic high value interactions are more directly encoded in HTML today than a lot of developers expect to need JS for. Some other tags to pay attention to: summary/details, progress, meter, input type="color|date|time|datetime|range". It's an interesting relearning project, sometimes, how much the high level interactivity bits of HTML have changed since, for instance, the jQuery era.
- eitland 3y ago
  > You don't need JS for basic autocomplete in 2023, you can use "datalist" in HTML: This does not seem to load data dynamically, it seems to be a way to show data from a predefined list?
  - WorldMaker 3y ago
    Most "basic" autocomplete isn't all that dynamic and you can prepopulate on the server side reasonably well. Sure, you still need JS to fetch a dynamic changing list, but you can also just update datalist options elements with JS rather than implement a full separate UX for autocomplete today. You are limited in the ability to CSS style datalist options so a lot of developers are still going to feel pressure in 2023 from "pixel perfect" UX designers to continue to reimplement that wheel, but the version of the JS that just updates a datalist after a fetch is likely much simpler than building a full "autocomplete control".
khimaros 3y ago
i'm interested in the answer to this question as well and did a bunch of searching a while back to no avail. maybe the world is waiting for us to start?
- YoshiRulz 3y ago
  The tag is `<!DOCTYPE html>` and it should be the first line in the file/stream. Doing anything else will enable "quirks mode"[1]. Beyond that, the best thing you can do is avoid features that haven't been standardised yet or that were only standardised recently. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mode_and_Standards_Mode#how_do_browsers_determine_which_mode_to_use https://developer.mozilla.org/en-US/docs/Web/HTML/Quirks_Mod...
- eitland 3y ago
  I have absolutely no idea about html rendering so my only contributions so far has been to ask/suggest to people who could know. But it is an idea that I keep getting reminded about. It could work adoption wise, since if it can be done technically it can be adapted independently of everyone else on backend and frontend: - backwards compatible, if a browser doesn't take advantage of it it renders completely ordinary and in supporting browsers if a website doesn't use this trick it just renders as any other website - If just one browser and one website does implement this then there will be a full setup. If the idea worked and for example Firefox supported this and Wikipedia or someone else took advantage of it suddenly everyone who used Wikipedia would se faster load and less battery usage.
  - khimaros 3y ago
    my assumption is that this would be a strict subset of existing HTML/CSS/JS so that existing browsers would work without modification. but a small enough subset that hobbyist browsers could realistically implement the entire standard. it may make sense to look at browsers such as elinks and dillo for defining that subset.
its-summertime 3y ago
https://amp.dev/ https://amp.dev/ is that. No one wants to use it because the very first line of the mandatory js file is about advertising metrics.
- eitland 3y ago
  There are reasons why I didn't mention amp :-) amp isn't meant to solve our problem but Googles problems.

khimaros 3y ago

maybe a good starting point would be the subset which is supported by dillo or elinks today?