There's some policy about comments being bad / code should be self documenting.

From what I hear from my colleagues on the Chrome team, one of the first things they were delighted to do after forking Blink was to finally go around and comment the various confusing parts of the codebase. (And, no longer get requests to remove comments when trying to land a PR.)

Most WebKit developers are good at documentation, it’s just that they often work on things that their employer would not like being made obvious because it deals with SPI or unreleased products or security vulnerabilities. Commit messages are actually pretty good for the most part except in these situations where a laconic or purposefully misleading message will be used.

Documentation has been a bit of a challenge in my experience. There are some high-level docs at https://trac.webkit.org/wiki though many are 10-15 years old at this point. My approach has been to look at the commit history for the file to see if the changesets shed any light, and sometimes go to the attached bugzilla link to see if there was any discussion about the change there. Then attach a debugger and step through to try to uncover how the classes relate to one another.

You aren't opening the wrong file, there isn't much documentation in WebKit besides a few Markdown files. I'm not sure why this is the case.