Re: <model> explainer update

I accidentally hit send before finishing.

eliminating SSR for camera control, eliminating)


eliminating accessibility (any apps that read HTML without JS), eliminating
apps or sandboxes with JS disabled, etc.

The Web Components CG is working on Declarative Custom Elements, whereby
> Custom Elements (Web Components) are defined


are defined purely in HTML with JS being optional (and ideally all future
elements designed to maximize HTML usage to avoid having to add JS).

*#!*/bin/joe-pea --trusktr


On Fri, Jan 24, 2025 at 10:43 AM Joe Pea <joe@lume.io> wrote:

> X3D, Lume (my project), A-Frame, and others, are probably all too complex
> to include in a web spec all at once, at least how specs are developed
> today in small chunks. Maybe small bits at a time (f.e. a single <model>
> element) is more doable, and then rendering features can be slowly
> extracted into new elements over time (f.e. <box>, <sphere>, <camera> etc),
> once the browsers have had a chance to get on the same page (internally) in
> terms of how they render.
>
> However, x3d/lume/aframe/etc all have one thing in common that is better
> than <model>: their rendering features are purposefully planned to be fully
> controlled from HTML *without JavaScript*, making them fully compatible
> and interoperable with all web frameworks (React, Vue, Svelte, Solid,
> Angular, jQuery, etc) and other sysmtes (f.e. HTML-serving servers in a
> multitude of programming languages, accessibility readers, etc) in a
> standard *and simple* way.
>
> I wrote an issue about this in immersive web's GitHub
> <https://github.com/immersive-web/model-element/issues/73>. I'm hoping
> that this can be addressed by the immersive web community. Otherwise,
> without addressing it, people who use all those web frameworks, will have
> to escape out of their framework in order to use plain JavaScript for
> manipulation (eliminating the possibility of staying fully
> reactive-declarative, eliminating SSR for camera control, eliminating).
>
> The Web Components CG is working on Declarative Custom Elements, whereby
> Custom Elements (Web Components) are defined, and the <model> element will
> not fit in with the HTML-first way of writing custom elements, again
> forcing people to escape out of the system to use plain JavaScript.
>
> The solution is simple! Just include all features in the HTML interface as
> attributes, or as new elements. Examples:
>
> <model camerapos="1 2 3" >
>
> or
>
> <model>
>   <camera pos="1 2 3">
> </model>
>
> or similar.
>
> This will make <model> fully compatible with the current, and future,
> declarative-reactive best-practice ways of doing things.
>
> *#!*/bin/joe-pea --trusktr
>
>
> On Wed, Jan 22, 2025 at 6:50 PM Polys, Nicholas <npolys@vt.edu> wrote:
>
>> In an early draft of HTML5 there was the X3D tag...
>>
>> It is probably wise to understand the pattern and the power of the DOM
>> when it comes to scene graphs:
>>
>> X3D the HTML way | Web3D Consortium
>> <https://www.web3d.org/blog/anitahavele/x3d-html-way>
>> X3D the HTML way | Web3D Consortium
>> <https://www.web3d.org/blog/anitahavele/x3d-html-way>
>> X3D the HTML way. by Anita Havele and Nicholas Polys. What happens when
>> enterprise 3D graphics meets the World-Wide Web? When peanut butter and
>> chocolate meet? The answer, of course, is ‘Delicious Things’!. When these
>> worlds collided several years ago, interactive 3D on the Web was the domain
>> of advanced enterprises and research institutions.
>> www.web3d.org
>>
>> Perhaps this should be added to you explainer documentation !
>> ?
>>
>>
>> ------------------------------
>> *From:* holykoolala <holykoolala@gmail.com>
>> *Sent:* Wednesday, September 18, 2024 10:37 PM
>> *To:* Brandel Zachernuk <brandel@apple.com>
>> *Cc:* public-immersive-web@w3.org <public-immersive-web@w3.org>;
>> public-immersive-web-wg@w3.org <public-immersive-web-wg@w3.org>
>> *Subject:* Re: <model> explainer update
>>
>>
>> Hello,
>>
>> This part of the explanation confused me. Is this saying new Fetch and
>> CORS rules would be made so model source data becomes completely
>> inaccessible? I'm confused why Fetch / CORS are involved as a rendering
>> consideration.
>>
>> Is there any precedence for this  in the browser today?
>>
>> <Point of confusion>
>>
>> Privacy considerations:
>> Rendered <model> data is not exposed to / extractable by the page in this
>> proposal, so no tainting is required. We do expect this would require
>> extensions to Fetch (a new destination type), Content Security Policy (a
>> new policy directive), and likely a few others.
>>
>> On Wed, Sep 18, 2024, 6:43 PM Brandel Zachernuk <brandel@apple.com>
>> wrote:
>>
>> Hi everyone,
>>
>> I have an update to the model explainer as initially posted by us back in
>> 2022! I would love for folks to read it ahead of TPAC so we have a chance
>> to reacquaint everyone with what <model> is, what kind of challenges it
>> faces, and some potential ways of addressing those problems.
>>
>> It’s *not* my intention to set anything in the explainer in stone, but
>> to get enough detail in one place for people to agree / disagree with. If
>> you get the chance between now and TPAC, please take a look through the
>> document (and the demo!) to see the refinements to the proposal. There’s a
>> PR out for both to land in main, but you can read from the branch here:
>>
>> https://github.com/immersive-web/model-element/blob/explainer_demo/explainer.md
>> Additionally, there is an interactive explainer demo that covers the
>> broad context that <model> is attempting to cover- it’s also in the PR to
>> get “officially” hosted, but I have a copy of it up here:
>> https://zachernuk.neocities.org/2024/model_explainer/
>> It’s intended to be viewed by scrolling on a computer, but should work on
>> a phone as well.
>>
>> I look forward to further discussion on all of this next week!
>> Many thanks,
>> Brandel
>>
>> *What’s new:* *Tighter limitations on v1 functionality* As an initial
>> candidate, I feel like <model> shouldn’t encode interactive state beyond
>> that presented via an animation timeline or camera controls.
>> *Update to camera / view controls* The first proposal’s use of “camera”
>> feels like it was too limited. entityTransform supports a DOM-native API
>> for constructing a more sophisticated view without adding too much extra
>> complexity. The API is also synchronous (even if the view updates are
>> managed out-of-process) - more about that below.
>> *Bounding box information* Used in service of understanding how to set
>> up a view of a model, in the event that the contents aren’t known by the
>> author already. *environmentmap attribute and events* Important for an
>> adequate level of visualization control, I feel like applying one IBL is a
>> “good-enough” start to allow authors to present model media in different
>> contexts - and means model *files* are not impairing their ability to
>> display correctly in a mixed-reality view.
>> *Reducing the use of Promises* While many APIs like HTMLMediaElement and
>> webGL/webGPU offload activity to other processes, that’s not always a good
>> reason to use a Promise-based API. Particularly with attributes like view
>> pose and animation time, a reasonable answer *now* is likely better than
>> a perfect answer at some unknown time in the future.
>> *Manipulation terminology change* The discussed automatic controls were
>> previously known as “interactive’ mode, which was noted to be an ambiguous
>> term. Clarifying that it’s related less to a stateful interactivity and
>> more to a mode of interaction on a “stage” in an “orbit” mod is intended to
>> differentiate this.
>> *Removal of audio* While audio is part of some 3D model asset types,
>> it’s a capability that is already available through existing APIs, so it’s
>> not a critical part of an initial implementation to provide that
>> functionality.
>>
>>