No Stupid Questions

HTML is, as the expanded name implies, a markup language.

It's just a text document that, based on the markup around the sections of text, gets rendered according to the rules assigned to the markup tags. It's quite similar to a Word doc.

Javascript is interpreted and JIT-compiled by the Javascript engine. Works similarly to other interpreted languages (Python, BASIC, VBScript, etc)

CSS...I'm less clear on but am guessing it's somewhere between markup and interpreted.

Pipeline is HTML -> CSS -> Javascript. JS can then go back and alter the previous two.

You are conflating a bunch of different things here and it's hard to tell exactly what you're even asking. HTML is completely separate from Javascript and CSS. Together, they are web technologies and typically all three are used to display a webpage, but only HTML is actually required. The others provide additional functions, each in their own way.

More to your point. HTML is not a programming language. It is not turing-complete. It is a markup language. It does not get "compiled", it gets "rendered". This may seem like a semantic difference, but these are actually different things and they are handled differently by code and in fact by completely different engines within the code. HTML rendering engines are still very complex beasts, and while you can draw some similarities with a compiler, they are not the same thing.

Most web standards are defined by the W3C, that includes HTML and CSS. But there are many different standards, even ones defined by the W3C, and many versions of those standards as well. All of these are handled by the browser's rendering engine. However, there's also a lot of bad code in the world that still needs to be rendered correctly, and you might be surprised how recently some of these standards actually developed. The browser wars have flared up many times and each time "standards" were usually the casualty. Mozilla has this brief explainer of the three different "quirks" modes currently used for compatibility on the modern web.

Javascript engines are their own whole different ballgame, as Javascript/ECMAscript is indeed a turing complete programming lanaguage, and all the big players (V8, Spidermonkey/Warpmonkey) are highly sophisticated JIT compilers with multiple layers of on-the-fly optimization. The deeper technical details are frankly beyond me.

Modern web browsers are as complex, feature-rich environments as any traditional operating system, and they have as many different aspects to them as any complete operating system does. They are not "one engine" or "one compiler" or "one standard" as much as they are an ecosystem of engines, compilers, standards, protocols and libraries all working together while remaining compatible with each other and all the other software that is out there, to ultimately present the user with a coherent, consistent and accessible representation that hides most of the immense complexity of what is going on behind the scenes.

HTML doesn't "run". It's not a scripting language, it's a markup language. All it does is mark sections of the document for the browser to display.

but isn’t that inefficient given that most of what people do on computers is browsing the web?

Why, yes, yes it is!

And now you understand why these days we use multi-core, multi-gigahertz processors to do a lot of fundamentally the same things we used to accomplish with single-core processors with speeds on the order of megahertz.

(Just wait 'til you find out about WebAssembly, LOL.)

Yes html is all parsed and rendered by the web browser. What the elements do and how they interact and are displayed is defined by a standards body like the w3 consortium https://www.w3.org/TR/2014/REC-html5-20141028/

There's traditionally been differences in the implementations of those standards between browser companies, thus causing browser compatibility issues where a site may say it doesn't work in Firefox, or requires chrome or whatever. Though most major browsers use Chrome's rendering engine now except for Firefox and its derivatives.

Yes I suppose it is less efficient than precompiling a webpage and serving it as a package that gets downloaded and "executed" though that then opens you up to cross operating system compatibility issues such as Linux and windows not being able to run binaries compiled for the other os. Html was conceived at least in part to be agnostic in that way I believe. As a "hypertext mark up language" it was a way of formatting text for easier reading

Seems like your really pondering “HTML should be conspicuously slow for such a widely-used standard,” right?

The answer is that modern browsers are complex and highly optimized rendering engines.

Read back through this blog: https://mozillagfx.wordpress.com/

But in a nutshell, there’s a lot of talk about how modern browser are analogous to tuned game engines, heavily relying on the GPU and all sorts of hacks to render HTML efficiently. “Compiler” doesn’t even begin to do them justice, and modern GPUs are a core part of getting a good browsing experience.

V8 is another good example, taking what was a notoriously slow language (JavaScript) and hacking out a fast JIT engine for it.

The “standard” is ostensibly the HTML spec and such, but in reality whatever Chrome (and Firefox/Safari) renders is the standard. Devs build around their strengths and quirks, basically, instead of the other way around.

HTML is the content and CSS is how to display it, or the formatting and styling required to display it.