6 ms·

Quick note: when trying to do full page screenshots, Chrome does a screenshot of the current view, then scrolls and does another screenshot. This can cause some

Quick note: when trying to do full page screenshots, Chrome does a screenshot of the current view, then scrolls and does another screenshot. This can cause some interesting artifacts when rendering pages with scroll behaviors. Firefox does a proper full page screenshot and even allows you to set a higher DPS value. I use this a lot when making video content. Check out some of the args in FF using: `:screenshot --help`

wereHamster 2y ago
That's not the behavior I'm seeing (with Puppeteer). Any elements positioned relative to the viewport stay within the area specified by screen size (eg. 1200x800) which is usually the top of the page. If the browser would scroll down these would also move down (and potentially appear multiple times in the image). Also intersection observers which are further down on the page do not trigger when I do a full-page screenshot (eg. an element which starts animation when it enters into the viewport).
- deleted 2y ago
  [deleted]
- genewitch 2y ago
  bravo for puppeteer, i guess? "singlefile" is the only thing i've ever seen not do weird artifacts in the middle of some site renders, or, like on reddit, just give up rendering comments and render blank space instead until the footer. anyhow i've been doing this exact thing for a real long time, e.g. https://raw.githubusercontent.com/genewitch/opensource/refs/heads/master/screenshot.cgi https://raw.githubusercontent.com/genewitch/opensource/refs/... using bash to return json to some stupid chat service we were running
xg15 2y ago
I mean, if you have some of those annoying "hijack scrolling and turn the page into some sort of interactive animation experience" sites, I don't think "full page" would even be well-defined.
- sixothree 2y ago
  Pretty sure this refers to sticky headers. They have caused me many headaches when trying to get a decent screenshot.
ranger_danger 2y ago
Where would you type that command in?
- pavel_lishin 2y ago
  Firefox developer console.
deleted 2y ago
[deleted]

wereHamster 2y ago

That's not the behavior I'm seeing (with Puppeteer). Any elements positioned relative to the viewport stay within the area specified by screen size (eg. 1200x800) which is usually the top of the page. If the browser would scroll down these would also move down (and potentially appear multiple times in the image). Also intersection observers which are further down on the page do not trigger when I do a full-page screenshot (eg. an element which starts animation when it enters into the viewport).

deleted 2y ago
[deleted]
genewitch 2y ago
bravo for puppeteer, i guess? "singlefile" is the only thing i've ever seen not do weird artifacts in the middle of some site renders, or, like on reddit, just give up rendering comments and render blank space instead until the footer. anyhow i've been doing this exact thing for a real long time, e.g. https://raw.githubusercontent.com/genewitch/opensource/refs/heads/master/screenshot.cgi https://raw.githubusercontent.com/genewitch/opensource/refs/... using bash to return json to some stupid chat service we were running

xg15 2y ago

I mean, if you have some of those annoying "hijack scrolling and turn the page into some sort of interactive animation experience" sites, I don't think "full page" would even be well-defined.

sixothree 2y ago
Pretty sure this refers to sticky headers. They have caused me many headaches when trying to get a decent screenshot.

ranger_danger 2y ago

Where would you type that command in?

pavel_lishin 2y ago
Firefox developer console.

deleted 2y ago

[deleted]