I would tend to agree.
However, you may be interested to know that CSS is complex enough now that you can build very complex selectors to create UI actions. I now consider some of my CSS as "firmware" which has a set of actions the display can perform. Then HTML becomes the program which selects CSS opcodes to run by invoking the firmware functions.
Currently I use such a model in a sort of MVC. Where, even without JS, the View (HTML) is often a short compiled program / set of visual actions, which run on the site-wide display's firmware (CSS). The controller updates the model and then compiles a new program to run in the view.
In a similar way that punched cards were a program fed to looms to weave a pattern, HTML can be instructions that determine the order of operations executed by a virtual machine (browser) loaded with firmware (CSS). One might say that when writing such HTML/CSS you know what the output will be, it's just a marked up display. I would say this is no different than the loom's program of punched cards which the programmer knew would produce a certain pattern, but had to be executed on the loom (or browser) before said output could be viewed. CSS+browser machine accepts limited input during the running of the program, reacting to :hover and :active events, this is actually more complex than the loom which does not accept input while running its program. Today's clients' displays are extremely thick, and thus you can actually program them (even without using JS to a certain extent). This makes the controller a program that writes programs that will run in the display.
That said, most people don't use HTML or CSS in such a way. Most treat them as static output from a user or server side program.
TL;DR: HTML can be used as programming opcodes that run on a CSS virtual display device. Markup is actually opcode for programming the rendering machine.
I would tend to agree.
However, you may be interested to know that CSS is complex enough now that you can build very complex selectors to create UI actions. I now consider some of my CSS as "firmware" which has a set of actions the display can perform. Then HTML becomes the program which selects CSS opcodes to run by invoking the firmware functions.
Currently I use such a model in a sort of MVC. Where, even without JS, the View (HTML) is often a short compiled program / set of visual actions, which run on the site-wide display's firmware (CSS). The controller updates the model and then compiles a new program to run in the view.
In a similar way that punched cards were a program fed to looms to weave a pattern, HTML can be instructions that determine the order of operations executed by a virtual machine (browser) loaded with firmware (CSS). One might say that when writing such HTML/CSS you know what the output will be, it's just a marked up display. I would say this is no different than the loom's program of punched cards which the programmer knew would produce a certain pattern, but had to be executed on the loom (or browser) before said output could be viewed. CSS+browser machine accepts limited input during the running of the program, reacting to :hover and :active events, this is actually more complex than the loom which does not accept input while running its program. Today's clients' displays are extremely thick, and thus you can actually program them (even without using JS to a certain extent). This makes the controller a program that writes programs that will run in the display.
That said, most people don't use HTML or CSS in such a way. Most treat them as static output from a user or server side program.
TL;DR: HTML can be used as programming opcodes that run on a CSS virtual display device. Markup is actually opcode for programming the rendering machine.