- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Nov 2023 20:55:40 +0000
- To: public-css-archive@w3.org
> FWIW, I'm in favor of this. If UA controls when -ua-old and -ua-new are added, then the complexity of whether it's added at the right spot is an implementation detail. That's actually what I proposed initially and https://github.com/w3c/csswg-drafts/issues/9595 changed my mind. There are 3 use-cases we're trying to tackle: 1. #9424 2. #9595 3. Letting authors configure types as described in options 2-5 on this issue. Assuming 1 is the default : "apply only types specified in the new document (override)". Cases 2 and 3 above require making types mutable at least within the reveal event. We can solve case 1 with UA supplied types but conceptually it seems like case 1 is SPA equivalent of case 3 (?) : let authors configure types in the old vs new DOM different than the browser's default. The choices I see so far are: 1. Make types mutable within the `reveal` event + UA supplied types. 2. Make types mutable within the `reveal` event and in the update callback? Since reveal is the MPA equivalent of the end of the update callback in SPA. 3. Make types mutable all the time. Between these choices I lean towards the last one. The only reason I see for 1 or 2 is that the timing is subtle so authors will get it wrong. Let's hide the timing complexity in the implementation and explicitly let them mutate the types only at the "right" spot (a.k.a reveal event). -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9526#issuecomment-1813248970 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 November 2023 20:55:42 UTC