css

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-08-28

Final complete day: 2026-08-28. Attention was 1.8% — this entity appeared in 46 of 2,594 analyzed posts/comments in the seven days ending that day (55 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-08-28 16:18 UTCComment

   wget/HTTrack miss the JS-rendered bits because they never actually run the page. Snapshotting API JSON into the webroot (like the top comment) is the right move if your UI is a thin client over a few endpoints. If the HTML itself is assembled in JS, I'd also prerender: crawl the sitemap in a headless browser, wait for network idle, save the fully rendered HTML, then rewrite asset URLs so CSS/fonts/images are local. Quick check: after the crawl, open a couple of pages with JS disabled and see if the content is still there. If it isn't, you saved a shell, not a snapshot. Tradeoff is maintenance vs fidelity. JSON snapshots keep the original JS app working but you also keep whatever client-side bugs you already have. Full HTML snapshots are dumber and more portable, but you lose in-page interactivity unless you carefully keep the JS. For a backend you're shutting down, I'd prerender HTML and only freeze ./api JSON for the bits that still fetch at runtime.

2. 2026-08-28 14:20 UTCComment

   Sure, probably wrap the content in a containing element (eg. a div) and style that using CSS. Then make sure the video or img element fits in that.

3. 2026-08-28 13:58 UTCComment

   This is /r/webdev. They can open up the inspector and see for themselves in 10 seconds whether it's pure CSS.

4. 2026-08-28 13:55 UTCComment

   You can hook up a script or an LLM to a browser-based tool like Chrome Devtools MCP or Playwright, render a sitemap of your entire site. Have it loop through every page and write the HTML of each page in a folder based structure with static HTML files. Then deploy that static copy to GitHub Pages, change the DNS so the URL points to the GH pages and done. How many pages is this for? Hundreds/thousands, I would invest some time in a proper pipeline that automates this. If it's more like 25 then I would just do it manually. There's options like which lets you manually download a webpage with all images, CSS, fonts, etc.. included into 1 HTML file.

5. 2026-08-28 10:59 UTCPost

   Best way to migrate a dynamic website to a static site? - I have a live website where some pages are populated dynamically through JavaScript/API calls. I’m shutting down the backend after the project ends and want to migrate the current version to a completely static site. What’s the best way to do this while preserving the currently rendered content, images, CSS, fonts, etc.? I’ve tried wget/HTTrack, but they only save the initial HTML and miss the content generated by JavaScript. Would a browser-based rendering tool be the best approach, or is there a better tool/workflow for this? update: I ended up using browser automation to render the pages, copied the dom and then manually removed all the backend js. not the cleanest approach and most defently not the most time effichent one but it worked ish