Re: [w3ctag/design-reviews] Early design review: CSS Toggles (Issue #730)

We've had other discussions about application state that isn't stored in way that can be encoded in HTML (see e.g. https://github.com/w3ctag/design-principles/issues/289) and we do see a need for what we've been describing a presentational state vs document state (e.g. state encoded as elements and attributes and can be encoded in HTML).

This feature clearly falls into the presentational state category. We have two architectural concerns:
1) There needs to be a mechanism for preserving, recovering, and encoding presentational state. e.g. If I'm looking at something in an app that's only exposed three layers of state down and send the current URL to someone else, how do they recreate the state so they can see what I'm linking to? We're thinking something like having a holistic presentational state model, which CSS toggles can expose and interact with, but so can other features, such as presentational properties on DOM nodes. This feature could then be built so that the underlying state is explained by that model, which can then perhaps have it's own JS API (rather than something specific to toggles) and mechanisms for storing/loading and encoding the state in a manner suitable for URLs.
2) We're also concerned that authors will use presentational state where they really should be using document state (and vice-versa), has there been any thought on ways of nudging authors to choose the correct one? (Spec text and examples are an obvious mechanism, but we're wondering if something can be done to add or reduce friction to certain uses to help nudge authors...)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/730#issuecomment-1187690840
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/730/1187690840@github.com>