Perhaps a "modernized" small-net / small-web version of XUL —
• would focus on intent
• would be declarative
• would have a simplified syntax (relative to XUL)
• would have high-level UI primitives
• would have reactive data bindings
• would aim for portability
• would be sandboxed by default
• would be adaptive by design
https://mastodon.social/@reiver/116458395826470481
#GeminiProtocol #MercuryProtocol #SmallNet #SmallWeb #SmolNet #SmolWeb
@reiver but please leave styling, stylesheets in the client, not per document/page/site
Also: Read-only browsers killed what the web could've been. Making the web server/client while having to rent a domain name, a server, & buy a certificate, etc to run a server made the web stillborn. Per website style design was a terrible UX and accessibility mistake #Stylesheets should've been something you install in your own browser such that "the web" would have the uniform look and feel you prefer. #UnpopularOpinion
@reiver I think the challenge here will not be so much the specifics of the layout DSL, but the balance with small-net principles of eliminating tracking (since app => running unaudited logic client side), keeping clients simple (how much code required to provide those UI primitives and data binding across multiple platforms?) and of course choosing a language for the dynamic interactivity (XUL chose JS of course)...
1/2
.. I have previously thought about 'inverting' the browser from a document-centric renderer which has ingested a dynamic runtime, into a dynamic runtime (likely WASM engine), with excellent networking, a standard rendering canvas and input bindings, plus an HTML renderer if you need one. Think of a Pico8 which can do HTTPS maybe?
2/2
@reiver ⊼ (Charles) 
Dimly Lit Corners
Phil Ashby 
🍵