What file does PG send to the Browser

General Questions
1

Well,

wrt Problems with Error Checking AND Pinegrow rendering a HUGO site, both locally and via URL - #13

I was just going to ask , how does Pinegrow render the page with its built in server.

But the topic was closed as I was typing.

As If I open the URL containing bad code in PG.. it renders it broken in PG, due to the broken code, which makes sense.

But then, if I press CMD+B in PG to open that file in the browser,
It opens in Brave browser, also with broken rendering.
So Brave Browser now renders the local host copy of that live website file, broken.

BUT.. If I open the URL directly in Brave Browser it renders correctly -with the same broken code, direct from source URL!

So what changes in the file that PG send to the Browser that causes it to be rendered badly, true to the nature of the broken code it receives and not well presented, as compared to that which the browser receives directly from the URL?

which is the same broken code.

What is the post parsing/broken sort of code that PG sends to the Browser and where does it originate/ is stored/ can be views?
Or is it a strict flag or something on the rendering end of the browser, which is sent from PG to the browser?

IF so, what is it, and where can it be viewed/set on /off etc.
SO a strict/relaxed render view in PG with alarm bells to warn you.

Would this be an interesting Feature for dev work?
Feature request?
Personally, I’m glad it rendered it true to the broken code, but if it could be toggled on and off, that would be great for a dev/debugging feature.

I’ve been looking for flags etc and I cant quite find an answer

2

The difference you’re observing comes down to how the content is processed and served.

When content is served through Pinegrow’s internal server:

  • Everything passes through Pinegrow’s parser first
  • The parser attempts to interpret the HTML
  • If there are significant structural errors, the parser can struggle and may not render the content gracefully
  • The parsed/processed version is what gets sent to the browser

image
image2150Ă—656 60.8 KB

When content is served directly by the browser:

  • Either by loading the page directly from disk (file://) or from the web
  • The content goes straight to the browser’s rendering engine without any intermediate processing
  • Modern browsers are very forgiving and have robust error recovery mechanisms
  • They can often render broken HTML in a “best effort” way that looks acceptable

So the “broken sort of code” you’re seeing when using CMD+B is actually the result of Pinegrow’s parser trying to make sense of malformed HTML and potentially failing at it, whereas the browser’s direct rendering engine is more tolerant of structural errors.

This is why external validation tools are often more reliable for heavily corrupted markup - they don’t go through this intermediate parsing layer that can be overwhelmed by significant structural issues.

The processed content isn’t stored as a separate file you can view - it’s generated on-the-fly by the internal server when serving to the browser.

This explains the technical difference between the two rendering paths and why the results differ.

1 Like
3

Ok thanks for that.

and some more characters, just so I can post the simple reply and exceed 20 characters…>
Ye Gads!

4

And then I close this topic as well :slight_smile:
Cheers.