There’s some very strange behaviour that happens when you use CTRL+F to search for text on a page.

For example:

The first “image” text on the page is in the “images & sprites” heading. But before that, it finds 4 instances of “image” which… seemingly don’t exist? Are hidden or something? Looking at the code of that generator I have no idea. Only then does it find any of the real instances of “image” that are on the page–three of them.

This problem happens all over the site on all sorts of generators by the way, it’s not unique to that one. It’s just an easy example.

For me personally this has been troublesome when trying to search on a documentation page for some particular function name–things like that. Or when there’s a very complex generator with a ton of buttons I want to find one that does the thing I want to do–but instead I have to read through every one of them, because the page search doesn’t work correctly.

By the way I’m using Chrome 126.0.6478.132 (Official Build) (64-bit). I haven’t tested on other browsers, but as a lot of the big browsers are Chromium-based I’m guess at least those will have the issue.

  • @perchanceMEnglish
    1•3 months ago

    Yeah there’s some code that basically pulls the “rendered” HTML out of the iframe and sanitizes it, and adds it as offscreen text so crawlers can index it as if it weren’t embedded in an iframe. It’s not really necessary if a generator has good $meta.description, but it probably helps a bit anyway. That text should have had display:none (which should still be indexed, since crawlers need to allow for the possibility of it being interactively shown some time after page load). Ideally crawlers would just notice that the iframe takes up the whole page, and “look into” it for content to index, but at least with Google’s it either doesn’t do that, or only sometimes does that (i.e. for popular pages where it can spend more resources) - at least, last time I checked

    • @wthit56OPEnglish
      1•3 months ago

      Ah I see–thanks for explaining 👍