Q:

When is html officially in "run-time"

I just had a discussion about meta tags in html and when they are interpreted by the web browser. My colleague was adament that this is done pre-run-time (html parse time) as run-time officially starts when body.onload is triggered.
When does run-time officially start in html? 
I know this seems trivial, but googling "html run-time" yields naught.

A:

As noted by nevatype, "run-time" doesn't exactly make sense for declarative languages like HTML. That's why you aren't getting any Google results.

What you're asking about sounds sort of like the rendering pipeline:

Parsing, which turns a chunk of HTML into DOM nodes
Style, which resolves CSS onto the DOM
Layout, which figures out where DOM elements end up relative to one another
Paint setup, sometimes referred to as recording, which converts styled DOM elements into a display list (SkPicture) of drawing commands to paint later, on a per-layer basis
Painting, which converts the SkPicture of drawing commands into pixels in a bitmap somewhere (either in system memory or on the GPU if using Ganesh)
Compositing, which assembles all layers into a final screen image

Source: https://www.chromium.org/developers/the-rendering-critical-path

However, as noted on that same page, this is not how browsers do the initial page load.

HTML is a funny language. Browsers will basically let you do almost anything.
Imagine writing sloppy C code and the compiler goes, "You know, George, you have totally no idea what a pointer is. But I like you, George. Here's what you probably meant."[1]
That's almost how HTML gets handled. When a browser interprets HTML, it is extremely kind. No closing tags? No credit? No problem!
Basically, the browser starts progressively rendering the page while it is still loading.
This is the reason the XHTML craze a few years back was so weird. XHTML is not forgiving. You had to get the entire document and parse it before the browser started showing anything. Yuck.
1: Just so nobody gets the wrong idea, if C did do that it would not be a good thing.

This and this describe the initial page load in an understandable way.

Here's a rough idea:

Make a request
Receive responses with the HTML
Parse the HTML into a DOM tree (happens while the page is still loading)
Style the DOM nodes (using the browser's user agent stylesheet)
Layout (figuring out where DOM elements are)
Paint the layers
Composite the layers onto the screen

This is fairly similar to the pipeline before, but the parsing is happening aggressively, and I haven't gotten to the external resources yet.
So your page has external resources. That's expected. The browser expects it. The browser will use a preloader in the background to scan ahead of the parser and start loading those external links. So step 3 part A is preloading resources.
Except that you have blocking CSS in your HTML. That's okay. Everybody does it. (Except the magic unicorns at Google who telepathically transmit actually include the important parts of the CSS in the HTML, thus eliminating a resource request.)
CSS links are blocking by default. The browser cannot render until the CSS has been loaded, parsed into CSSOM, and then used to style nodes.
I'm not very clear on whether the CSS also blocks the HTML parsing or whether it happens concurrently (maybe a second thread?).
So here's where I see:

Make a request
Receive responses with the HTML
Parse the HTML into a DOM tree (happens while the page is still loading)

Meet a CSS <link> and load that (and while we're waiting, the preloader starts looking for other resources to load)
Parse CSS into a CSSOM tree

Style the DOM nodes using the CSSOM
Layout (figuring out where DOM elements are)
Paint the layers
Composite the layers onto the screen

Now, you tell me you have render blocking JavaScript. That's really, really bad.
When the parser meets a <script> tag that is not async or defer, it has to get that JavaScript run, because that JavaScript could be making changes to the DOM (but nobody in their right mind does this anymore).
So now we have to stop parsing the DOM, wait for the JS to download, parse it, then execute it.

Make a request
Receive responses with the HTML
Parse the HTML into a DOM tree (happens while the page is still loading)

Meet a CSS <link> and load that (and while we're waiting, the preloader starts looking for other resources to load)
Parse CSS into a CSSOM tree
JavaScript! Abort! Shut everything down!

Wait for the JavaScript to arrive (the preloader is the only guy still doing anything)
Receive all the JavaScript (JavaScript is not as kind as HTML)
Parse the JavaScript
Run the JavaScript (may or may not change the DOM)

Parse the rest of the HTML into the DOM
Style the DOM nodes using the CSSOM
Layout (figuring out where DOM elements are)
Paint the layers
Composite the layers onto the screen

To answer your question about when run-time is: I have parsing at step 3, but the DOM gets used through step 8 (and keeps getting used when users initiate changes).
The load event happens when the document and all the dependent resources have been loaded. Since this includes things such as images, you could stick the load event around step 10.

