- From: Joey Arhar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Nov 2020 22:58:33 +0000
- To: public-css-archive@w3.org
After thinking some more about the element fragment case for beforematch, I think it could get complicated: - If we try to make it have async scrolling, even in the navigation case like I mentioned in my last comment, it might still break some things, I won't know until I actually change it and see what happens - If we make it have sync scrolling, which wouldn't change the existing brittle elementfragment behavior, we would be making beforematch have different semantics in the elementfragment case vs the scrolltotextfragment/find-in-page case because the scrolling would happen at a different time for each. If the timing matters to a page which uses beforematch for both of them, which seems likely, we would get cases where the page reveals content after the scroll occurs for elementfragment and the page would reveal the content before the scroll for scrolltotextfragment/find-in-page with the exact same beforematch event handler. It seems like we probably won't be able to make beforematch for elementfragments work the same as it does for scrolltotextfragment/find-in-page, which could be worse than omitting beforematch for elementfragments. In addition, are already capable of expanding content in response to changes to the elementfragment via the `hashchange` event, and you can see that mobile wikipedia already expands specific content when navigating with an elementfragment: try navigating here in mobile device emulation mode and you will see that only the target section is expanded: https://en.m.wikipedia.org/wiki/COVID-19_pandemic#Prevention -- GitHub Notification of comment by josepharhar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-725707946 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 November 2020 22:58:35 UTC