Update <html> element attributes when navigating #553
Conversation
|
Bunch of failures. But seem unlikely that they're directly related to this. |
…ument, which has a different id
|
👋 @dhh this should be ready now! Mind approving the workflow? |
|
There's just one failure now, but that's definitely not related to this change, so good to go:
(But would be great to have a look at this too, so we can have a clean build!) |
|
I'd argue that not changing the document element during navigation is a feature. At Basecamp we use It's useful for state that can't be obtained on the server and that won't change during a session. For example, data about the current theme, client capabilities, client permissions, or other client preferences that only need to be obtained once. @manuelpuyol, was this motivated by a particular use case? |
|
Yeah, looking at how we use HTML in Basecamp, this is going to be a regression. Can't ship this as is. Best we can do if we actually want to change this is to put it behind a configuration option. |
Sorry for the delay! We also set some state data in the |
I see, thanks for the explanation @manuelpuyol! It's intentional that we're only replacing the
If we did decide to change the behavior I think it would need to be more nuanced, such that changes to the document element are merged, as is done for In any case, I think we should revert on the grounds that this is a breaking API change. |
|
Concur. I missed that originally. @manuelpuyol can you do a revert PR? Then we can give it another try behind a configuration option or something. But we can't break the API as-is. |
|
Working on a revert here #596 |
Turbo only replaces the
<body>and updates the<head>when navigating, ignoring possible changes to the<html>element, like classes ordata-*attributes.With this change, Turbo will update the
<html>when navigating through pages.