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.
<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
<div>? To fix this, my idea is requiring a namespace prefix for various medias. For example,
<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:
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.
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.
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