- From: Jake Archibald via GitHub <sysbot+gh@w3.org>
- Date: Tue, 04 Apr 2023 13:44:41 +0000
- To: public-css-archive@w3.org
jakearchibald has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] MPA: Reacting to the old/new page type == This covers a few use-cases: - The 'outgoing' old page wants to assign `view-transition-name` depending on its own page type and/or the 'incoming' new page type. - The 'outgoing' old page wants to opt-in and [declare a version](https://github.com/w3c/csswg-drafts/issues/8679) depending on its own page type and/or the 'incoming' new page type. - The new page wants to assign `view-transition-name` depending on its own page type and/or the old page type. - The new page wants to opt-in and [declare a version](https://github.com/w3c/csswg-drafts/issues/8679) depending on its own page type and/or the old page type. - The new page wants to assign different animations to the pseudos depending on its own page type and/or the old page type. I refer to "page type" here because if you create a custom transition I think it's more likely to be from "index" to "article", even though there may be many URLs that implement the "article" layout. Currently, with SPA transitions, we recommend using class names on the root: ```js const data = await getNextPageData(); const transition = document.startViewTransition(callback); if (currentPageType === 'index') { document.documentElement.classList.add('from-index-page'); transition.finished.finally(() => { document.documentElement.classList.remove('from-index-page'); }); } if (data.incomingPageType === 'article') { document.documentElement.classList.add('to-article-page'); transition.finished.finally(() => { document.documentElement.classList.remove('to-article-page'); }); } ``` Now those class names can be used in selectors to meet all of the use-cases above. But how should we do it with MPA? ## Option 1: Stick with class names We could add events to allow MPAs to set class names on the root element: ```js // On the outgoing page: document.addEventListener('beforecrossdocvtcapture', (event) => { sessionStorage.oldPageClass = 'from-index-page'; document.documentElement.classList.add('from-index-page'); addEventListener('pagehide', () => { document.documentElement.classList.remove('from-index-page'); }, { once: true }); if (event.incommingURL === articleURL) { document.documentElement.classList.add('to-article-page'); addEventListener('pagehide', () => { document.documentElement.classList.remove('to-article-page'); }, { once: true }); } }); ``` ```js // On the new page: document.addEventListener('crossdocviewtransition', (event) => { document.documentElement.classList.add(sessionStorage.oldPageClass); document.documentElement.classList.add('to-article-page'); event.finished.then(() => { document.documentElement.classList.remove(sessionStorage.oldPageClass); document.documentElement.classList.remove('to-article-page'); }); }); ``` But… part of the fun of MPA transitions is you don't need JavaScript. ## Option 2: Media queries based on URL ```css @media (vt-next-page: urlpattern('/articles/*')) { /* … */ } @media (vt-old-page: urlpattern('/')) and (vt-page: urlpattern('/articles/*')) { /* … */ } ``` This allows the developers to set styles depending on the next page URL (after redirects), and on the new page they can style depending on the current page and previous page URL. [URLPatterns are already defined](https://wicg.github.io/urlpattern/#urlpattern). However, URLs can be a little fragile. Often, you don't have all articles under `/articles/*` etc etc. ## Option 3: Media queries based on page type ```css @media (vt-next-page: article) { /* … */ } @media (vt-old-page: index) and (vt-page: article) { /* … */ } ``` Where pages declare their type via a meta tag: ```html <meta name="view-transition-page-type" content="article"> ``` This could be easily used by SPA transitions too. However, is it too hard to get the incoming page type from the meta tag for use in the outgoing page? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8683 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 4 April 2023 13:44:43 UTC