I'm actively exploring/implementing this, which has shaped my thoughts on the topic.
1. I'd have the browser recommend apps to install to open otherwise unsupported MIMEtypes & URI schemes. I think most desktops support this now (certainly FreeDesktop.Org-compatible Linux & BSD ones do via "AppStream"), it'll free webdevs from compatibility worries, & allow low-cohesian features like videoconferencing & (like brimstedt & osrec discussed) apps to be entirely independant codepaths.
2. For the sake of markettability & accessability (unlikely bedfellows) I like to target unusual human interface devices, e.g. voice, "smart" TVs. It should be a goal to work well absolutely anywhere!
3. I was kind of surprised to find that the next biggest simplification after dropping JavaScript is to move forms out-of-line from the webpage into their own codepaths. This allows me to better reuse OS code whilst simplifying hypertext event handling, avoid webdevs complaining that native widgets clash with their designs, & design a better UX for more devices.
4. There seems to be plenty of precedence suggesting it'd be a good idea to allow links to partially update a webpage, or open modal dialogs/popovers. hey.com is a prominant example.
5. The DOM needs to be replaced, it's an overengineered OO monster straight out of the 90's that can be largely replaced with about 10 lines of code in any language. It's expensive for the browser to construct, for JavaScript to optimize away, and for webdevs to deal with directly.
6. I've got almost no complaint against CSS (I found it easy enough to implement), but sometimes author styles actively make websites worse. So support for user & alternate styles should be emphasized to the user, and websites should still look good if they don't provide CSS.
7. Drop support for CSS `position:`, there's better alternatives now & it does more visual harm than good.
8. I prefer XHTML over HTML as it's easier to parse, but there's a better compromise to be reached between the two camps than the one WHATWG prescribes: handle self-closing tags and close any intermediate tags between the current one & the explicitly closed ones. This routine seems to work well enough on the modern Web, even if it'd break some CSS selectors.
That covers the main points, I'm curious to hear other thoughts?
I'm not clear what you're describing with "flexbox scrolling"?
My reasoning is that I want to prevent elements from overlapping and obscuring important information. CSS is generally designed to avoid that, which is what the "CSS is awesome" memes like to illustrate.
>I'm not clear what you're describing with "flexbox scrolling"?
"position: absolute" can be used to disrupt the two-way size propogation. Without it you either get shrinked content on y, flexbox wrapping problem on x, scroll appearing on a wrong element in some cases (or cropping for "overflow: hidden"), or you have to set width and height of the block with scroll using css "calc()" — all these solutions are ugly.
>My reasoning is that I want to prevent elements from overlapping and obscuring important information
The most simple example of overlapping elements is a background/border. You can look around this page and find a lot of overlapping graphical elements — it's not the problem, but overlapping text (and other content) is.
"CSS is awesome" example formally has no overlapping DOM elements, no "position" attributes. It's just a block with "border" style and "width" set to some fixed amount. Often this problem happens without border on the block and remains invisible, unless two such blocks are really close together and the text begins to overlap. Still no "position" involved though.
1. I'd have the browser recommend apps to install to open otherwise unsupported MIMEtypes & URI schemes. I think most desktops support this now (certainly FreeDesktop.Org-compatible Linux & BSD ones do via "AppStream"), it'll free webdevs from compatibility worries, & allow low-cohesian features like videoconferencing & (like brimstedt & osrec discussed) apps to be entirely independant codepaths.
2. For the sake of markettability & accessability (unlikely bedfellows) I like to target unusual human interface devices, e.g. voice, "smart" TVs. It should be a goal to work well absolutely anywhere!
3. I was kind of surprised to find that the next biggest simplification after dropping JavaScript is to move forms out-of-line from the webpage into their own codepaths. This allows me to better reuse OS code whilst simplifying hypertext event handling, avoid webdevs complaining that native widgets clash with their designs, & design a better UX for more devices.
4. There seems to be plenty of precedence suggesting it'd be a good idea to allow links to partially update a webpage, or open modal dialogs/popovers. hey.com is a prominant example.
5. The DOM needs to be replaced, it's an overengineered OO monster straight out of the 90's that can be largely replaced with about 10 lines of code in any language. It's expensive for the browser to construct, for JavaScript to optimize away, and for webdevs to deal with directly.
6. I've got almost no complaint against CSS (I found it easy enough to implement), but sometimes author styles actively make websites worse. So support for user & alternate styles should be emphasized to the user, and websites should still look good if they don't provide CSS.
7. Drop support for CSS `position:`, there's better alternatives now & it does more visual harm than good.
8. I prefer XHTML over HTML as it's easier to parse, but there's a better compromise to be reached between the two camps than the one WHATWG prescribes: handle self-closing tags and close any intermediate tags between the current one & the explicitly closed ones. This routine seems to work well enough on the modern Web, even if it'd break some CSS selectors.
That covers the main points, I'm curious to hear other thoughts?