[Proposal] (Another) Alternative to HTML

I’ll probably just end up sounding like a madman, but I wanted to propose an alternative to HTML. Also, I am rather queasy about posting this…

I know people have proposed things like this before and failed, I had actually forgotten about WICG until, while browsing yesterday, I found a 2015 thread that is similar to this. However, I’ve been thinking about this for a while, and I figured I would take a shot.

Also, I am proposing an alternative to HTML, NOT a replacement.

In this proposal, I do sometimes give syntax examples, but I try to avoid actually defining the syntax of the proposed language, preferring to list concepts, instead

With this, I have some goals in mind:

• Provide alternatives to the HTML+CSS+JS+WASM suite. Note that simply adding a second language will not fix much, because now you only have two options. I will discuss my solution later.
• Provide more developer expression. Enough said.
• Reduce what the browser engine is in control of. I think we should make the web slightly lower level. Firstly, this will reduce the amount of work browser vendors must do, instead delegating work to third-party API writers. Additionally, you can simply include the correct implementation as a resource/API, rather than having to target a separate implementation for each and every browser. You can also define your own implementations, or modify an existing implementation, if existing implementations do not suit your need. As an effect, implementations will also provide more scriptable behavior. We might get the concept of being able to write your own look-and-feel with one implementation, and the concept of feeding automatic styling scripts to another. Now, the main problem is see with this is users who disable scripting, or users on devices the webpage writer did not include implementations for. I discuss my solution later.
• Syntax and DOM Changes. Given the abundance of frameworks that compile to HTML, I think it’s plain that the syntax and DOM aren’t perfect. First off, I think templates could work better. Right now, templates are defined in HTML and copied to the DOM in Javascript. I think that we should be able to use templates from directly within our markup language. Templates could have some syntax that allows passing paramaters, either via attributes or child nodes. Addtionally, it would be nice to see the ability to link external templates, e.g. <link rel="template" href="..."/> Secondly, I was thinking that, even though HTML is media independent, certain things seem to imply that a certain media is used. For example, does a screen reader or Braille device actually care about the difference between a <span> and <div>? To fix this, my idea is requiring a namespace prefix for various medias. For example, <span> becomes <gui:span>. The last thing I’m thinking of is embracing custom tags. Instead of having to register a tag via JS, we should have a syntactical way to indicate that our tag is a custom tag and not an invalid tag.

Here are also some more questionable goals I’m not sure about:

• Stricten semantics. A lot of HTML’s complexity comes from it’s graceful fall when presented with errors. This also doesn’t service web developers much when their page behaves strangely. The problem with this is forwards-compatibility, so I will not be addressing this concern.

Ok, here are some more specific implementation details I have:

Implemention details:

I mentioned that simply adding a language isn’t going to fix anything. I had an interesting idea of registering custom mime types. We can then use Javascript/Ecmascript to compile any script tags with custom mime types to something similar to WASM, but without the required JS bindings that boggle down the speed. This means that we can use any scripting language, styling language, or markup language that we want, as long as we include an API to parse it, solving the “well now we only have 2 languages” problem. (There is another problem that arises, which I discuss later)

Even though the Ecma262 standard exists, not every JS implementation is equal. One idea is to technically only support our WASM-like language, and standardize a specific script that is used to run Ecmascript. Browser vendors should use this script, as it will increase platform uniformity. Browsers can use their own scripting engines, like V8, but this might increase the amount of cross-browser testing that developers must use, as well as the complexity of the browser itself. In order to ensure that all browsers can use the standardized script, it should be implemented in our WASM-like language, as browsers will already need to support this. It is still advised that users who want to use Javascript specifically include an API to run it, as this will cover the times when browsers may have differing implementations from what is standard. This solution requires the previous point about custom mime types.

I mentioned about trying to be lower-level. One big problem with developing sites is cross-browser inconsistencies in UI. I believe that we push users to define their own UIs, or choose a third-party API which does it for them. For example, if I wanted to have my page work on GUI, I could load an external API that manages rendering via something like WebGL. And I can choose which API I will be using, rather than the end-user. I can support a single implementation, and know that it should work regardless of what browser the client uses. I can choose which implementation I want to use, or even craft my own, rather than relying on some browser implementation which may or may not suit my needs. Additionally, the developer can define their own tag namespaces, so that they can optimize their content for certain media. Now, there are two edge behaviors to note about this: When the user has scripting disabled, and when the developer does not expect a certain media to be used, and therefore does not account for it. In these cases, we can have the browser deploy standardized script that will do the work for the user. However, these scripts should get out of the way the moment the developer says otherwise. If both the developer and the browser have ideas on how to support a Braille device, the developer wins. Additionally, for the sake of consistency, browser vendors should not write their own implementations in these cases, but rather use a standardized one. If such a script does not exist, they should go through the work of making a standard script, rather than proprietary code.

Potential Problems:

Under implementation details, I mentioned the possibility of things like custom mime types. There is one huge hole here: if people rely on this feature being available. This feature entirely falls apart if people use this feature to implement an alternate markup language. In that case, the DOM is never configured. This means that, if the site doesn’t support a specific UI mode, or if scripting is disabled altogether, the browser attempts to use it’s default facilities to render the DOM. However, if there is nothing in the dom - because we relied on custom mime types for a secondary markup language - nothing is rendered. The best way, I think, to get around this is to force developers to use at least 1 noscript tag. Since there is the possibility of having scripting enabled, but the media device not being supported, I think there should also be a nosupport tag, too.

Encouraging usage:

There’s not much we can do here. People will be worried that their products will not work on older browsers. There are still people using IE. I do have two basic ideas, however:

My first idea is along the lines of <iframe type="not-html" src="someurl">...Transpiled version...</iframe>. Transpilation is inefficient, as there are many things we cannot easily represent in HTML, or that may be slow.

My second idea is that we force users to upgrade their browsers, which does not sound good for businesses. Users who are lucky enough to have ancient versions of browsers could potentially use NPAPI or PPAPI plugins, but this does not work for most modern users, whose browsers have removed plugins due to security concerns.

–

If I missed anything, worded anything confusingly, or if the comments have any criticism, I will edit this post to include anything new.

EDIT: Btw, if needed, I can create a mockup spec or a mockup browser or something

Hello again I was thinking, even if we didn’t create an alternative to HTML, some ideas could be integrated? I tried to make this as an edit to my post, but Discourse is no longer allowing me to edit my post.

Yesterday I had proposed an alternate language. Some of the features I suggest, would, however, be able to be squeezed into “vanilla” HTML, maybe.

Here are the pros and cons of making this a separate language, as opposed to integrating this into HTML:

Pros (of NOT sticking to HTML):

• Simplification of the parser. I imagine a “strictened” variant of HTML, with mixed-in XML features such as namespaces, as well as a custom syntax for tags outside of a namespace. Something along the lines of <namespace:tag value="attribute"/>. Parser will not handle issues such as adjusted insertion location, accepting erroneous input, and the like.
• Reset switch. A lot of Javascript APIs and quirk-mode behavior and the like can be dropped.
• Architecture redesign. This is not something in my realm. I am not very experienced in this. This would be up to the standard enthusiasts.

Cons (of NOT sticking to HTML):

• More technologies for browser vendors to maintain.
• Users who wish to use any new features must learn a new language.
• Existing frameworks, editors, and servers will not support a new language.
• Harder to polyfill

If we did use some of the concepts described in my topic post within HTML, as opposed to a new language, here is what I think it would look like:

• Assuming no script has been run, the browser renders with whatever it usually uses to render HTML. With the exception of template extensions mentioned in my topic post, it acts as though this extension failed to exist. Note that we loose the benefit of a “standardized rendering script”, which would have helped reduce cross-browser testing.
• Once scripting has started, developers register callbacks for which media they intend to support. This looks something along the lines of document.registerMediaRenderer("braile", (mediaHandle)=>{someImportedApi.begin(mediaHandle);});. mediaHandle is a library for controlling a device. For example, if we are using X11, the handle could be something like a WebGL handle, some API for setting an event listener, and some API for detecting DOM mutations. Once we call this, we check if the string passed matches the display type. If it does, we stop rendering the page and pass a handle to the callback, letting the callback handle rendering the page/
• Additionally, another API exists to register custom mime types. For example, document.registerMimeType("text/mylang", (content)=>{return someImportedApi.aotCompileToWasm(content);});. Any external resources loaded with a custom-handled mime type must follow CORS policy. The callback is called when a resource of the desired mime type is loaded. If further processing is required (in the case of a custom scripting language), the code for a web assembly script is returned by the callback. If not (in the case of a markdown or styling language), undefined is returned by the callback. Note that this would require modifying WASM to be able to make function calls without calling to JS.

This does not fulfill all of my goals. Syntactic and DOM goals are not achieved, nor is simplification of the browser. However, it does fulfill many of the other goals I mentioned.

This approach is also successful in reducing cross-browser testing, IF scripting is enabled and the newly proposed APIs are used.

Why not just use XML (or microxml) in tht case? XML is already in the browser.

You even get templating support with XSLT, although check out XSLT 3 to see how it evolved into a much more comfortable language over the past 20 or so years since XSLT 1 was adopted by browsers.

One of the drawbacks of XML in the browser was that search engines didn’t know what to do with it; you get the same problem with any form of custom elements.

The other was that we didn’t have a good data binding story, but JSON has made that a non-problem.

I think XML does a really good job at separating data from styling. HTML tends to have a lot of pre-styled elements.

XSLT then converts the XML data to an HTML page (I know the browser can render XML with styling, but HTML has additional features such as scripting, and even XHTML lacks some things like noscript). To be honest, I think the complexity of HTML5 is much higher than that of XML. If you compare https://ygg01.github.io/xml5_draft/#parsing to https://html.spec.whatwg.org/multipage/parsing.html#parsing, you can see how much simpler XML is, but we kind of need some HTML features.

We’ve now converted raw data to a usable HTML page. Now we have 2 more things to worry about: styling and scripting.

CSS is great, as long as you remember that the @media query exists. However, CSS is also where a lot of frustration in cross-browser testing and styling takes place. This is where the ability to script rendering comes into play. By using a <script href="url"></script>, you know that (unless it is updated) it will consistently produce the same result. You can also copy and fine-tune the script if needed. This is opposed to, I dunno, Chrome uses one rendering engine, Firefox another, so you gotta try to design for both of them. The browser can use it’s own rendering engine if you don’t specifically specify a script to render your page for a certain media. This also presents the ability to use alternate layout engines, and variety is usually good. The only problem I see with this is clipboard, since doing the rendering from JS means you will have to ask for the clipboard permission when the user presses CTRL+C. Probably just have a copy event, though.

The other thing that I would still like to see is custom mime types. People constantly complain about JS, but compiling scripts to WASM ahead of time is a bit overkill. The ability to use JS to AOT compile script tags with other mime types to WASM at run time would, despite slightly increasing load-time, make things much easier. All you would need to do to run, say, typescript is <script type="text/ecmascript" src="https://typescriptlang.org/tsaot.js"><script type="text/typescript">...your script...</script>. Plenty of programming languages are available for native architectures, we could add some variety to the web.

This is a big topic but I only wanted to ask if you’d seen CSS Houdini.

I had not been aware of Houdini. It looks amazing, my only concerns are that it uses Canvas2D instead of the much faster WebGL, and also it doesn’t seem to solve any problems on devices that do not support X11 or Desktop capabilities.

Houdini uses the 2D canvas API, but it is not a canvas2d instance. It is rendered on the GPU as you would expect.

Regarding the idea of compiling things to WASM via mimetypes, this would actually be possible today using a Service Worker. More directly though, the nascent Loader API was supposed to provide exactly this functionality - though not compiling to WASM, since there is limited provisions for interface specifications in WASM, instead compiling to JS. JS can contain (inlined/externalized) WASM though, which makes it a relatively good slip layer for an abstraction like this.

This is an old thread.

But I am going to do this. This will be an alternative to HTML and LATEX and offer active document, with various embedded formats.

This will separate safety requirements from the document markup and document interaction.

I will write the interpreter/parser in NIM and the rendering engine in SFML. So it will be a document focused system.

If you want you can build a web focused system around it, and add web/socket/network stacks around it as you define it and as you see fit.