Notes caveats that make :target difficult to use with dynamic content #11928
Conversation
…namic content These caveats are not well documented anywhere else on the web, and only become evident reading the spec – or in my case, after hours of head scratching, testing and refactoring. I would like to allow others to avoid a similar pain.
Preview URLsFlawsNone! 🎉 External URLsURL: No new external URLs (this comment was updated 2022-01-11 18:58:32.208351) |
|
I am not seeing this caveat. The example, when I click on the history.pushState(#one) doesn't give focus to #one, the target element, either. If I put https://stephen.band/target/#four in the browser, sometimes it works for both (goes to and hilites four) and sometimes it doesn't (neither scrolls to four nor matches the selector). I am thinking the caveat should be in the pushState API rather than the selector, with a caveat linking to pushState, but need to do a bit more research. |
|
Hi Estelle.
You are not testing the right things. Here's a test with steps to reproduce:
https://stephen.band/target/
Cheers,
Stephen
…On Thu, 13 Jan 2022 at 19:58, Estelle Weyl ***@***.***> wrote:
I am not seeing this caveat.
Example: https://codepen.io/estelle/pen/LYzMjRK
—
Reply to this email directly, view it on GitHub
<#11928 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAQ3HQDKAC6B6DK2NPKHDDUV4OEVANCNFSM5LXBN4HA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Cheers,
Stephen
<http://cruncher.ch>
*web*: cruncher.ch
*twitter*: @cruncher <http://twitter.com/cruncher>
*email*: ***@***.***
|
|
Hi again. The problem is more thouroughly explained in this github issue:
w3c/csswg-drafts#6942
This was the result of a discussion (here
WICG/navigation-api#162 and here
https://twitter.com/domenic/status/1480634085357854729) where I tried to
get the App History API people interested in making :target update on
navigation changes. They didn't go for it, instead they propose a new
pseudo selector that does actually respond to navigation changes (*sigh*)
so I really want to make it clear in MDN that :target has problems for
dynamically updated content. Reading this page in MDN is what made me
believe that I could design some complex interaction around :target, and in
the end it turns out you can't.
Cheers,
Stephen
…On Thu, 13 Jan 2022 at 20:39, Stephen Band ***@***.***> wrote:
Hi Estelle.
You are not testing the right things. Here's a test with steps to
reproduce:
https://stephen.band/target/
Cheers,
Stephen
On Thu, 13 Jan 2022 at 19:58, Estelle Weyl ***@***.***>
wrote:
> I am not seeing this caveat.
> Example: https://codepen.io/estelle/pen/LYzMjRK
>
> —
> Reply to this email directly, view it on GitHub
> <#11928 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAQ3HQDKAC6B6DK2NPKHDDUV4OEVANCNFSM5LXBN4HA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
|
Thanks. Digging deeper. |
| @@ -12,7 +12,7 @@ browser-compat: css.selectors.target | |||
| --- | |||
| {{CSSRef}} | |||
|
|
|||
| The **`:target`** [CSS](/en-US/docs/Web/CSS) [pseudo-class](/en-US/docs/Web/CSS/Pseudo-classes) represents a unique element (the _target element_) with an {{htmlattrxref("id")}} matching the URL's fragment. | |||
| The **`:target`** [CSS](/en-US/docs/Web/CSS) [pseudo-class](/en-US/docs/Web/CSS/Pseudo-classes) represents a unique element (the _target element_) with an {{htmlattrxref("id")}} matching the URL's fragment at the time the page loaded. | |||
There was a problem hiding this comment.
not just at page load. when the page scrolls AND the fragment is changed, the selector matches, even if the id was added well after page load (my test was 10s) ... the URL fragment wasn't there at page load.
|
|
||
| There are two caveats that make the `:target` selector unsuitable for use with dynamic content. | ||
|
|
||
| 1. The target element is determined at the time of `DOMContentLoad`, upon navigations triggered by clicking on links, and when setting `window.location` or `window.location.hash`. It does NOT update when changing the location hash via `window.history.pushState()` or `window.history.replaceState()`. Pages relying on `history` to navigate cannot rely on `:target` to highlight content. |
There was a problem hiding this comment.
is this accurate, or is it only when history.pushState() doesn't trigger a scroll to the fragment?
|
I know I have been lax in replying here, but is there a good reason for closing this? The description of "The :target pseudo-class represents a unique element (the target element) with an id matching the URL's fragment." just isn't true. It's only true under certain circumstances. |
Summary
These caveats are not well documented anywhere else on the web, and only become evident reading the spec – or in my case, after hours of head scratching, testing and refactoring.
Motivation
I would like to allow others to avoid the head scratching, testing and refactoring.
Supporting details
Test case for dynamic :target styles and explanation of the problem is here: https://stephen.band/target/
Related issues
Changes to :targets behaviour are being discussed in the App History API (WICG/navigation-api#162) but the consensus is it can't be changed.
Metadata