Allow original styleheet to remain in head

[robbevp]

Is your feature request related to how this polyfill works? Please describe.
Thanks for this great polyfill (and others)! This is definitely not a bug in the package, but I'm trying to figure out how to make this polyfill work with turbo. Since turbo tracks the contents of the head and adds/removes elements on changes (or does a full page reload if configured), this seems to break the polyfill.

I made a minimal reproduction with some of the options I explored: https://github.com/robbevp/anchor-polyfull-turbo

Describe the solution you'd like
Would it be an option to not remove the original link-element once it is polyfilled? I would think that as long as the link-element is above the inline styles in the head, that the polyfilled styles would be used rather. (But I might be missing something here)

If the original element was left in the head, we could just not use data-turbo-track at all and both the original and polyfilled styles would be in the head. (We'd need another way to track when the assets changed and we actually need a full page reload, but I'm sure that is solvable in some way)

I imagine that this also means that the polyfill needs to track what elements were already transformed and skip those when the function runs again

Describe alternatives you've considered
In my reproduction, I think using data-turbo-track="dynamic" and re-applying the polyfill after every navigation comes closest, but this seems like a lot of redundant work. I think we could limit the amount of work the polyfill would need to do on every navigation, by placing all styles using anchor in their own stylesheet and limiting the polyfill to those)

[jamesnw]

I'm not familiar with Turbo, so I can't speak directly to that portion. This does seem largely caused by #91, the ability to apply the polyfill dynamically.

In theory, I think it would be okay to leave the original link element in the DOM. I think we are only adding properties and transforming existing properties, but not removing properties.

If you want to test out that approach, I think it would be just commenting out https://github.com/oddbird/css-anchor-positioning/blob/main/src/transform.ts#L60 (although if we do this, we would likely want to add it as an opt-in option).

As you note, however, this only gets you part way, and wouldn't address adjusting the polyfill's output as elements and styles are added and removed.

[robbevp]

I played around with toggling that one line, but the changes will have to be a bit more involved than that. If the original link elements aren't removed, I ran into two issues:

• Every time the polyfill is applied, a new style element is added for the same stylesheet
• The polyfill was also applied to the inline styles that it generated itself

I've made some changes to remedy both of these issues, which you can see in this diff: main...robbevp:options-leave-stylesheets

The naming is still rough (and I haven't added any tests), but this did work in the project where I noticed the compatibility issue with turbo.
Doing some measurements in a project where we use this polyfill, I got a substantial performance benefit:

• Without my changes: Applying the polyfill on each navigation would take 140ms-170ms each time
• With the changes: The first apply still takes 140-170ms, subsequent applies take ±50ms.

(These are just some basic measurements with performance.now() on my M1 MBP in FF 138.0.1)

Would you be open for a PR with these changes?

[jamesnw]

Thanks so much for digging in on this!

As you pointed out, there are 2 issues here. We are on board with the idea of the leaveLinkStylesheet as an option, if that is useful for users.

The harder part is related to re-applying the polyfill. Currently, the polyfill doesn't support being run multiple times on the same styles and DOM. We haven't tested it yet, but would anticipate some issues with reparsing. This solution re-parses all styles, and while it doesn't re-insert the re-parsed styles, those styles may still impact the polyfill's output in other ways. I think this portion will require a more robust solution (or at the very least, robust exploration of the issue). This is a portion of #91.

I will note that I've seen users of other frameworks successfully run the polyfill manually multiple times when setting the elements option of the polyfill to explicitly include all stylesheet elements and DOM elements that are impacted by any changes to the page. I'd be curious if this approach could work with Turbo.