I always found it interesting that style tags were designed as <style type="text/css">, implying that new style standards could be introduced down the road.

(for a while I thought <script type="text/dart"> might get real… oh sweet naivety)

I have a toy which allows <script type="text/smalltalk">. The scripts get transpiled on-the-fly to Javascript.

(Although the process you have to go through to hook a new script type is painful. There are, like, four different cases you need to consider, and scripts have to be processed in the right order but handled synchronously, and...)

The script type is a possibility but you have to make it work. I've forgotten the details.

Back in the day, IE4 supported both javascript and vbscript. And from memory if you installed other eg ActivePerl (and ActivePython too I think), you could use them as well.

Since the browser will not react to these nodes, you can add some JS code that will detect them and hand off content interpretation to other mechanisms.

That's how React's JSXTransformer worked. You can also do the same for WebGL shaders:

<script type = "x-shader/x-fragment"> … </script>

When something replaces HTML holistically and isn't locked into a single vendors solution. So, probably not ever.

When we implement Display PostScript in js, so we can use it for the web?

HTML+CSS for publishing static, stand-alone documents isn't all that bad. It's terrible for making "applications", and it's terrible for composing more than one thing into a page (such as a header, footer, table of contents/menu).

I still think Adobe's idea[1] of flowing content through boxes (aka the "desktop publishing way") makes more sense than many of the other "augmentations" for CSS in terms of allowing complex layout. But it is an idea that makes sense for basically composing pages - not really for "applications".

I'm not convinced there's much of a meaningful overlap between layout for hypermedia meant to be read/watched/consumed - and "smart object graphs"/"applications" that are meant to be interacted with. Other than that the latter can be used to build the former -- but that's a terrible way to approach standardization -- just for the problems related to accessibility and machine readability alone.

If we could agree to keep the two things separate, make some real effort into making better readers for better (but probably dumber/less feature-full mark-up) -- we would probably be better off. Even such things as readability[2] shows the merit of this: it shows, by existing, the virtue of a browser that is better at being a hypertext browser is useful (and that a browser that's better at being an application run-time can be used to build and host a browser that's better at being a hypertext browser...).

But I don't think we should need for users to relate to that many layers: an OS and standard library that acts as platform for applications, an application that acts as a platform for applications and an application in the form of html+js+css+possibly some server side magic that acts as an application for browsing hypertext. I'd very much like an application (a browser) that's actually good at just browsing hypertext too.

[1] https://www.adobe.com/inspire/2014/01/complex-layouts-reflow... (Now dead AFAIK, even though there's a js polyfill)

[2] http://barisderin.com/?p=325

Hey, as long as you're implementing Display PostScript in JS, throw in light weight threads, arbitrarily shaped canvases, events, interests, air tight synchronous event distribution, monitors, object oriented programming, networking, binary data encoding, object reference tokens, and implement NeWS! [1]

[1] https://en.wikipedia.org/wiki/NeWS

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

used PostScript code instead of JavaScript for programming.

used PostScript graphics instead of DHTML and CSS for rendering.

used PostScript data instead of XML and JSON for data representation.

RinohType [1] combines a CSS-inspired style sheet system [2] with a powerful layout system based on boxes ("containers"). It currently only outputs to PDF but an SVG backend could be added without too much work...

[1] http://www.opqode.com [2] http://www.mos6581.org/rinohtype_status_update_1

(I'm RinohType's author)

It was called XHTML, but then people preferred to keep the Frankenstein alive.

XHTML was just a slightly different syntax for HTML, it did not change anything about CSS.

Alone yes, but the whole XHTML alongside all the XML modules that were being defined was a vision oriented towards to what XAML or other native layout engines offer.

Something which is not backwardly compatible with the current web? This will never happen.

Does <canvas> count? :)