black box browsers/shrouded in mystery
It's strange ... no matter what topic I write about, no matter from what point of view I try to approach our profession, the bottom line is pretty much always the same: we still have a long, long way to go before we'll reach an acceptable level of professionalism. That's not necessarily a bad thing, there's plenty of adventure to be found in our work, but sometimes you'd wish some issues just didn't exist. Why the mini-rant? Well, let's talk browsers.
the inner workings of a browser
Usually you hear people talking about browsers when there are rendering inconsistencies, javascript incompatibilities or features lacking. We love to complain about the tools that output our work, but we do so on a very basic level. We throw input at our browsers, we look at the output and start to grumble when something is not coming out well. That's alright I guess, but if we just keep it at that we'll never really learn to use the browser to our advantage.
In most other professions people are taught about the tools they work with. You can't fly a plane unless you know a couple of things about physics, math and electronics. The more complex the tool, the more important it is to understand it at a core level. That's not to say a front-end developer should understand the finer delicacies of rendering an entire page in every single browser out there, but some general knowledge will definitely come in handy. This broader understanding would form a perfect base for tackling problems, making connections and becoming generally better at what it is we do.
Currently most people know bits and pieces, based on information they just happened to encounter when they felt adventurous enough to actually sit down and read up. Or when they met a particular problem that needed fixing, forcing them to dig deeper into the inner workings of the browser. This is all fine of course, but hardly conform with the future-proof spirit I like to apply in my work. I prefer to prepare for problems when they arise, or try anticipating them so they won't even occur in the first place.
knocking on some doors
If you start looking around for information on browser activities when rendering/redrawing/leaving a page you'll come up with very little. Most of the information is related to specific problems, more often than not we get little more than tepid conclusions based on black box tests. So I took the time to do some extra research on how a browser performs his primary job, starting at the source. I opened up my IRC client and entered the Opera, FF and webkit chats for a little talk with the people who actually work on these browsers. The results were pretty interesting.
The bottom line though is pretty simple: the documentation I was after simply doesn't exist, at least not in any structured form. I asked for books, schemes, online or offline documents, but got nothing substantial from any of the channels. The webkit guys remained awfully quiet (though they seemed pretty busy discussing some bugs), the Opera guys told me they'd rather not reveal too much about their engine, the FF crew informed me that the browser core changes too much to maintain any kind of up to date document. They did say they were available for more direct and concrete questions, which was rather nice of them.
So even if you go through all the trouble to get some idea of how the browser handles our web pages, there isn't much info out there that will help you. Either browser developers don't like to share the exact details, or they simply don't have the resources to keep updated information. That in itself is an interesting find, one which is once again telling for the state of our profession.
meager findings
Along the way I did find an odd resource here and there, so I'm just going to share what I've got so far. It's pretty random and not very focused, but at least it's something:
conclusion
Knowing what exactly happens when you leave or enter a page is crucial if you want to spent time on optimizing web pages or when you happen to encounter timing issues. Sadly this information is not readily available today, nor did I find a source that gathers all the bits and pieces and puts it in one single location.
Finally I'd like to thank the people I bothered with my annoying questions for their time and help, they must've picked up my disbelieve/surprise but they were still nice enough to explain their situation. If I missed some vital resources or you guys have any more links to share, please do so in the comments. The more information I can get my hands on, the better.

Comments
Tom Wijsman
This conclusion is false!
A layout engine transforms HTML and CSS into a DOM (Document Object Model) which can be manipulated by ECMAScript, either by initial execution or later events. This DOM tree (or a separate Parse tree) allows a rendering engine to easily (re)draw those objects to the screen; it's comparable to a game engine loading all kinds of data and then rendering it with OpenGL or DirectX.
Previous paragraph is simply what happens when you enter a page, deconstruction of the DOM happens when you leave a page. I don't see why you call this information not readily available, because any of the before mentioned names have quite some documentation. Of course they apply some things which makes things better for us, but again, there is information out there for hardware virtualization, V8, caching, protected mode by using low integrity, plugins and so on...
It's too complex to make a complete compendium of all information, but that doesn't mean it's not available to us. Suppose I were to write a web browser: Learning the HTML, CSS, DOM, ECMAScript and related standards will reasonable allow me to produce something that renders a page to your screen, perhaps go to a second page and so on.
Now there are two problems that kick in: First, my engine would be very slow, so I have to do all these low-level improvements to get my engine optimized (these improvements are specific, as implementations can differ so there is no documentation for this). Second, I need my browser to support all types of features: Some of these require documentation, some of them don't. For example, if we look at something as simple as a Tab, it's actually defined as an UI pattern out there. For example, we can speed up the process of loading images through caching, for which a RFC document exists. And so on...
I think that if I were to write a browser or understand how parts of it work,
I'm pretty sure that I'm not left behind without information at all. Because of W3C, RFCs and more...
kangax
This information is actually available; it might not be as comprehensive as you want it to be but check out stoyan's series on reflows and repaint (which should have more links to other resources) — http://calendar.perfplanet.com/2009/rendering-repaint-reflow-relayout-restyle/