- From: Christopher Joel <notifications@github.com>
- Date: Tue, 07 Jan 2020 08:58:20 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/856/571675909@github.com>
I would like to offer another use case for `observedStyles`. In the [`<model-viewer>`](https://modelviewer.dev) project, we offer a high-level, declarative API for embedding a 3D model as though it were a rich media type like `<img>` or `<video>`. Today, we primarily use attributes for configuration because they are the most practical thing to use, but not all of our attributes "make sense" as attributes. Consider this basic example of the markup an author may write today is: ```html <model-viewer src="astronaut.gltf" alt="An astronaut" field-of-view="60deg"></model-viewer> </model-viewer> ``` Here the author has configured the `src`, `alt` and `field-of-view` attributes. `field-of-view` controls the field of view of the virtual camera that is pointed at the model, and amounts to a style in our domain. We would prefer to use a custom property (`--field-of-view`) to express it, but there is no way for us to efficiently observe changes to such a style so that we can reflect the new value in the 3D scene (internally rendered with `<canvas>`/WebGL). This is one example, but we have probably a dozen or so attributes (e.g., `camera-orbit`, `skybox-image`, `exposure`) that make a lot more sense conceptually as styles. The thing we lack is an efficient mechanism to observe changes to a known set of custom properties. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/856#issuecomment-571675909
Received on Tuesday, 7 January 2020 16:58:22 UTC