I’m not too studied-up on CORS, but I know what it’s there for. Currently there’s a number of things that are not possible to do because our generator is on a different subdomain than other generators or iframes, etc. etc. and even the top-level page we’re actually on.
With that allowed (I think CORS can allow this), there’s a lot more customisation we can do of things like t2i image iframes and gallery iframes, reading/changing the top-level url, etc. Maybe that’s something you don’t want to allow, but I for one have wanted to do these things for completely benign legit reasons multiple times.
Thanks!
I’ve hackily fixed
<a href="#foo">foo</a>
clicks so they work properly now.I’ve also added a fix so if you visit perchance.org/whatever#foo it’ll correctly try to scroll to the
id="foo"
element if it exists: https://perchance.org/dkp9npcidc#foo - pinging @[email protected]You can also type a hash into the address bar of an already loaded page and press enter, and it’ll scroll to the element, like a normal top-level page does.
I’ve also fixed
history.replaceState
so you can now change the query string of the top-level frame as shown below. It’ll throw an error if you try to change the pathname, since that could allow for malicious ‘spoofing’ of other generators as mentioned above.history.replaceState({}, "", `/${generatorName}?foo=1`)
window.location.hash = "#foo"
(you can also do this withreplaceState
IIUC).document.title = "foo";
and it’ll propagate to the top-level frame.<link rel="icon" href="https://exampe.com/image.png">
to<head>
) and it’ll propagate to the top-level frame.Let me know if you find any bugs 👍
And I’ve added a
hideGalleryButtons
to the text to image plugin.I’ve now updated my hash-links-plugin to not do anything ;p
https://perchance.org/hash-links-plugin
Great stuff–I’ll check those all out tomorrow and come back with an update 👍
New bug: the code expects there to be a href attribute on every
<a>
tag. There may not be, at which point it breaks.generatorName
is a thing?! I’ll make use of that for one of my private plugins 👍 Should I scour the windows object for such hidden gems??):target
doesn’t change though, when it does for the normal method.Test page I used for trying all these out: https://perchance.org/testing-features-19-aug-24-498573958#edit
What’s this?
Fixed, thanks!
Nope, just https://perchance.org/advanced-tutorial - and if you find something that you want to use, but isn’t documented there, please let me know
:target
is a css pseudo-selector. So you could puta:target { color:red; }
, and then links will be red if they have the id of the #hash. Lets you visually change elements when they’re the one being linked to.Ah, admittedly I did sorta skim that doc; I’d read so much stuff that day from everywhere else 😅
Bug: if it’s just in a code block and immediately happens, setting
document.title
is later overridden by$meta.title
. Ideally$meta.title
would happen first, and then anydocument.title
stuff elsewhere–so that it takes precedence.Hmm. If it’s during page load, then I think I should encourage people to use
$meta.title
for that, since that’s what search engines will see. I.e. it might be misleading if, during page load,document.title
takes precedence, but then later they see that search engine’s aren’t using that. (Note that some search engines will run the full JS/iframe for certain popular pages, so they would seedocument.title
, but it’s not guaranteed)It’s just a temp thing for me; I add “DEV” at the front so I can see at a glance which copy I’m working on. And I still manage it, but I have to use a setTimeout, so… it’s not like it really prevents it anyhow. And a regular web page would accept this just fine without such a workaround.
I would think the only time people ever use
document.title
in or out of perchance is to have a dynamic title based on stuff happening on the page–otherwise why script it at all? So it’s always done when the coder wants it to be different to the normal title, when they want to override it, ignoring anything else.So… dunno, my take is, it should just work the same as it does anywhere else. It’s cool that $meta.title does what it does, but it should be easily overridable I reckon. If nothing else, to keep parity with expectations for web pages in general.
I guess that’s kind of my angle on a lot of this stuff, maybe you noticed… coming from a web-dev background and working just in raw html/css/js files for a while, I’m all about keeping it working as close to that as possible and avoid unexpected side-effects or differences. Doesn’t mean you have to take that stance, but that’s mine anyhow 😁
That’s a goat fix. Great job! 🫂
Bug: if a #hash is set in the address, Auto will scroll to that instead of leaving the scroll where it is. Perhaps you’re re-handling the hash after auto-partial-load, but I think could be skipped. I think refreshing on a regular web page won’t re-scroll to the hash target.
Thanks! Fixed.
👍