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.
I do buy 3d model data occasionally (hobby, not for professional uses). I think most stores obfustcate the data somehow although I never took a look at it in detail. If you wanted, you probably could easily extract the model from the preview.
I still think this is a very bad proposal. Why compare something with an image and then disallow it to be treated like other ressources? This is typically bad corporate influence on the web.
I think we should go the other way. Remove DRM components from browsers again. Netflix not available anymore? They will either adapt or not be available. Their loss would probably be more significant.
>I still think this is a very bad proposal. Why compare something with an image and then disallow it to be treated like other ressources? This is typically bad corporate influence on the web.
Because webgl fingerprinting. Also, I'm not sure why you think not being able to extract the data using javascript is "bad corporate influence on the web" or" DRM". you can still do whatever you want. The models are freely available for you just not the page.
People also consume refined sugar, alcohol, saturated fat and cigarettes regularly.
Just because something is common doesn't mean it's good for you.
I'm not against closed software mind you, I'm using some myself, but the web as a platform has reached this amazing stage because it's been built on openness. And now the very same companies that became rich thanks to this openness want to close it to get all the benefits for themself.
As per the parent comment, it's not exposed to the javascript running on the page, which is arguably the "dev" in this case.
>Not you the client, hence the user.
I fail to see how it being exposed to the javascript running on the page or not makes a meaningful difference to the user. Are we expecting the average user to interact with the page via the developer console or something?
>and we all have seen where it leads to.
The proposal doesn't have any DRM element at all. At worse you can just inspect network traffic to download the model file to disk and open it in whatever app you want.
> I fail to see how it being exposed to the javascript running on the page or not makes a meaningful difference to the user. Are we expecting the average user to interact with the page via the developer console or something?
No, but I'm expecting the average user to be able to enjoy an open ecosystem. Such as bookmarklet, addons, client side widgets, electron apps, WASM plugins, and all the wonderful things we can't yet think of now.
Instead, we will have one more walled garden.
And just like that, piece by piece, the next step in the IT revolution will be more and more close. Because that's the plan, that's what they want. Something the computer runs, but has no control over.
>No, but I'm expecting the average user to be able to enjoy an open ecosystem. Such as bookmarklet, addons, client side widgets, electron apps, WASM plugins, and all the wonderful things we can't yet think of now.
But there's still webgl and <canvas>. I'm failing to see what type of use cases we're missing out on here, because javascript access is missing.
My understanding is basically that DRM is the technology that permits the existence of Netflix and similar. Perhaps I just lack a strength of principle, but I don't see why you'd remove one of the most-enjoyed aspects of the internet for the sake of uh... some kind of privacy-adjacent something?
We got to an ok compromise of video tags and native browser support, with DRM extension for corporate needs/reqs... Is it the best? No. Could it worse, definitely.
But without it youd need a Netflix app on your PC... And what safeguards does that have from hoovering my pc usage up for sale or marketing? Atleast Netflix only gets MY Netflix consumption for their metrics and ML, and isn't cross referencing the games I play or other things I'm doing at the same time.
In addition to the privacy concerns with native applications, they're almost always insecure. One thing that is nice about modern browsers is that (despite Safari's leisurely update cycle) they are actually relatively secure, as far as software goes. Threats to the average user of Chrome are things like phishing, rather than RCE, and tab isolation keeps things from escalating out of control.
Contrast that to the now ubiquitous conferencing software solutions, and it seems like every day there's some zero-day RCE vulnerability or other spooky exploit.
If we needed to install and run a dozen different closed-source executables from BigCorp et al., I predict that we'd very soon go back to security dark-ages.
Netflix make money from their subscription service not DRM. I can easily torrent anything I watch on netflix but I watch it on netflix because its easier. Thats why I pay for netflix its not because their DRM prevents me from pirating anything.
As I understand it, this is not so much about DRM as it is about privacy. The new model tag allows the browser to sandbox the display of a 3d object without reporting information back to the web page/server. This way, the browser can use camera data to track the user eye position relative to the device for parallax or to show what is behind the device to accomplish the effect known as "augmented reality."
In other words, Apple wants developers to be able to deploy augmented reality experiences on the web without giving them access to the user's camera, which is a privacy issue.
Assuming I'm reading your snark correctly, is this really such a bad thing? People here seem to have a rose-tinted view of the internet's past, before Google, Apple et al. "abused" their browsers' position to push changes into the spec.
I can certainly see that apparently there are a lot of HN commenters who would like to go back to the days of IE and no real web technologies or much progress, but I think practically everyone outside this bubble prefers their browser experience to be at least somewhat feature-rich, and while the proposal under question may be strictly unnecessary, it should be weighed against alternatives: bundling a model viewer with every page view.
Maybe this proposal is bad and a waste of resources, but I don't like the knee-jerk response of digging one's heels in and decrying any and all browser APIs as bloat.
Not entirely directed at you, but your response just seems to echo something I see very often.
Agreed. There is another poster in this thread commenting about "privacy". There is a certain class of perfect privacy fetishist that is completely blind to the fact that that particular horse has long, long bolted out the stable.
All these arguments serve, when they are successful in hobbling the browser as an app platform, is too push developers into native apps in the app store. And then the developer doesn't need to fingerprint you, they get your identity just for asking.
Meanwhile, browsing habits (sites visited + time of day of visit) is enough to fingerprint the vast majority of people. And sites do collude on the backend to share this data with advertisers, long before the user ever gets a chance to block it in the client app.
If privacy fetishists see the browser as a sinking ship, they don't seem to realize they are trying to bail out the Titanic with a teaspoon, or that there is no such thing as dry land. The only way to stay private is too stay off the network entirely.
Okay, if I misread that I apologise. I'm not following the rumors, so it seemed like "oh looks like Apple's coming out with another something something and needs to update the spec to handle it". I think my point remains, though.
I don't mind new capabilities, but I hate how many new browser features are "standards" invented by Google for their own products which everyone else have to implement to remain a competitive browser.
Not fan of the prospect of Apple doing the same. If I wanted to make what Apple is making, I would have to rely on webgl. Them inventing something for their own use case when other stuff exists feels just unnecessary. Their proposal also includes a 3d format no one uses (except them I guess), as an attempt to shoehorn it in or something.
While I do accept the point, I think part of this is just that Google and Apple are the companies doing a large amount of work in the browser space. Because of this, they are likely to be the companies who see the hole that should be filled, or the opportunity to improve something.
Who are the people that should be making browser spec proposals, if not the people building browsers?
Yes, it sucks if you want to write your own browser, and now have to play catch up with the big boys throwing their weight around. But I don't think this is points against Google or Apple. Our browser technology shouldn't be held back by some romantic dream of individuals being able to build one from scratch, despite what many HNers seem to think. Even the best mechanics and engineers will struggle to build a car comparable to whatever rolls off of the large production lines. (I understand maybe that's a poor analogy, since you don't need all the bells and whistles of a new Toyota to be road-legal, while you do kind of need to keep up with the spec in order to be internet-usable (although there still are some IE11 holdouts..)).
My point isn't from a "a single person should be able to build this" perspective. But from a "big players misuse this to grab market share" perspective. Like how youtube was slow in Firefox for years, since they used APIs only existing in Chrome. Others follow suit, and thus other browsers are forced to either implement the same thing (thus making it a "standard") or lose market share since stuff works better in other browsers.
Sure, this sucks. I guess the counterargument is that then, given that the new API in Chrome is an improvement over the standard, waiting for this API to be actually accepted and written into the spec is a long, arduous process during which Chrome is unable to implement an objective improvement to their user experience.
My concern is basically that if we force browsers to be spec-compliant and wait for the due process concerning new features, we pump the brakes on everything, and we risk stalling genuinely beneficial updates.
Interesting they show support for USD(Z) in the example. USD will be the standard for most VFX houses and make tooling for various web based systems so much easier.
We have a 3D model format for the web in glTF. This is Apple having Not Invented Here Syndrome again. USD was developed at Pixar, of which Steve Jobs was the founding investor. Apple is the only one who wants USDZ on the Web. Everyone else is already using glTF.
GLTF, especially the binary format, is specifically design for transmission over the web. Wavefront is uncompressed text, Collada is even worse because it's extremely verbose XML. I don't know a lot about USDZ, but what I do know is that it's overkill for the web (graphics features that are mostly too costly to do in WebGL, additional scene description data like audio tracks, etc), while also lacking specific features that GLTF has that are aimed at the web, like streaming, progressive download of texture data.
Nvidia are also leaning very hard into USD with their meta- verse project. In that case USD matches requirements perfectly.
glTF 2.0 is widely supported although the quality of that support is variable. The spec is fairly large and every tool that exports glTF does so in a subtly different way.
For instance Blender adds a rotation transform node before every mesh to convert from Y-up (Blender) to Z-up (glTF). Animations run in Y-up space and target the node before that final rotation node. The BabylonJs exporter for 3dsMax converts its meshes and animations to z-up as part of the export process.
Many glTF loader implementations get tripped up on this (failing to support more than one model mesh or failing to respect the full transform hierarchy or failing to support animations). There are similar complexities and support issues around vertex data formats, buffer layouts, punctual lights etc
My limited reading of the USD format is that it has an even wider specification. My concern is that browser support will splinter even worse than it would with glTF. The' model' proposal doesn't dig into what USD nodes will and won't be supported and exactly how the data is expected to be rendered.
Blender is Z-up and glTF is Y-up, but regardless, this is a long standing issue of Blender. These problems exist for all of the model export formats coming out of Blender. How is that glTF's fault?
It's a schema specification with various plugins. I guess it will mainly be about the geo specification for models (and perhaps ignore the shaders etc). Documentation is hard to come by, you basically have to look at the source / examples.
Are you the one who posts this link on anything 3D-in-the-browser posted here? If you knew anything about either, you'd know they are completely different things.
VRML was more like 3D, inline SVG, before SVG in the browser was a thing. It was markup in the page. And it was meant to be scriptable and interactive. This is none of those things.
WebGL exists, why do we need a budget restricted version of a model viewer in the browser? None of the motivations are at all convincing. Should browsers now be obliged to integrate with VR headsets?
My comment is general enough to be easily interpreted as a question. If you have an as to how this proposal is a necessary addition to WebGPU and WebGL, why not go with that, instead of snarky condescension?
Not used Web3D but VRML is a dead language. Which is a pity because VRML was extremely fun to code in. Sadly it was a victim of being release too early (even VRML2 was out before most people 3D accelerators).
> WebGL exists, why do we need a budget restricted version of a model viewer in the browser?
WebGL support on safari is ropey at best why would apple implement a standard written by some one else when they can create a new standard no one asked for?
Holding a knife and moving your hand back and forth is not killing someone, either, but my omission of a few important details is the deception. In this case, the something being added to the HTML spec is a new standard that they are creating. I'm not going to argue whether anyone asked for it, but "nobody" is obviously hyperbole; Apple is asking for it.
Well there ya go, I called you on trite generalizations and hyperbole. Adding no truth or insight to the discussion.
I for one think this is a future proofing move with little current utility. However I’m not one who thinks the AR/VR/ 3D Models in browser bandwagon is going anywhere within the next 5 years.
Can you explain the steps necessary to display a 3D model using WebGL? (without using any 3rd party libraries). Could it possibly be easier than just pointing `src` to the URL of a model file?
Not sure where you got the idea of yet another format, no one seems to be mentioning that here or in the proposal.
Presumably browsers would support the most popular formats, just as they do with images and video. And just as with images and video, we'll likely end up in a situation where m most formats are supported by most browsers, with a couple odd formats that are only supported by some. Doesn't seem like a huge deal.
I'm only a casual at 3D, but my experience has always been that no two format implementations ever quite work the same way.
Unless apple is proposing to elevate some existing implementation, that already has interop across various platforms, then I think anything they do would necessarily be Yet Another Format.
Wouldn't an equivalent experience be <canvas> with no webgl used at all?
Get to see a nice blank screen for both. Once you fiddle with all the settings so you aren't looking out from the inside of a monochrome polygon, you're going to approach the same complexity as the webgl version
There are many developers, especially those just getting into the field, that don’t understand how to work with WebGL. WebGL is a great fallback if you need/want more control, but having basic support for 3D elements is a great idea for someone that just wants to show it off.
> It would be possible to reuse one of the generic embedding elements, such as <embed> or <object>, for this purpose. However, we think that 3D content should behave like other media types.
I think their argument is that although it is semantically possible to use object, they think this would be clearer for the future.
If this gets accepted into webkit, which is now nearly synonymous with "HTML", would it be a huge porting effort to get this working with Firefox, the only other HTML implementation I can think of?
(I understand that other webkit forks could have this code easily applied.)
> If this gets accepted into webkit, which is now nearly synonymous with "HTML"
It's not synonymous with HTML. Chrome's browser engine is now unfortunately synonymous with "the web" in general. And, while it's derived from WebKit, it's diverged from it too far, and bears a different name, https://en.wikipedia.org/wiki/Blink_(browser_engine)
No need for such an element. It's such a private use case to display 3D models that it's better suited as a web component than an element in the standard. See for example <model-viewer> https://modelviewer.dev/
As others have mentioned, the privacy implications are much more important. That is, the site owner will not have to have access to eg. the camera stream, but still use AR with this method.
So in a way, the value in this proposal is that it is less capable than the from scratch approach, and can be implemented safely just in the browser.
I would love to see that apple negotiates their wishes but have in turn to implement web APIs they currently keep back by choice.
And let users use a real different browser on their device.
Google: "Hey Apple, here is your pet <model> tag for your next AR/VR secret project. Now, here there are all the PWA APIs that are still missing in Safari. Thank you."
Based on the comments so far, I think I'm in the minority who think this would be a good feature for the web. This proposal might not be perfect, but I think the idea is great.
There's lots of good reasons to semantically want to embed a 3d model in a page, like any other type of media. Say you're writing a course explaining how differential gears work - a 3d model of that could be really handy to look at to learn. A shoe company wanting to have a model of their sneakers in their shop.
Sure we've got canvas, and WebGL, and WebGPU, and libraries like three.js, which work. But wow you gotta get a lot of JS slapped together to just get something rendering. E.g. I wonder how long transit spent getting a truck rendering on this page. https://panic.com/transmit/
The other challenge of doing everything yourself is that code is stuck in time. It's going to get very minimal benefits from browsers and devices getting better over time, it won't get native UI changes - in 5 years it'll look very dated, if it's still accessible.
3D models are very variable: some are defined with just triangles, some include quads, some are NURBS or subdivision surfaces. Sometimes two sides per polygon are considered, sometimes just one.
Ways of navigating a 3D model also vary wildly. Sometimes you just want to pivot/rotate them around a little, but sometimes "walking" inside them makes more sense.
Then there are materials and lights, and here people go wild with ideas.
In our "current world", if you want a 3D viewer, you use WebGL and Javascript, and voila, what you get is what you see in all browsers that support WebGL.
> But wow you gotta get a lot of JS slapped together to just get something rendering
Indeed. But there are some quite nice 3D model viewers out there ready to roll, easy to embed, and full of features.
I always though the way Windows' Geometry3D[0] element worked was really nice. You define a list of points in a particular order. Whether a face is on the "inside" or "outside" depends on the direction you "wind" a metaphorical string around those points. After defining some primitives you can start to compose them into a single model.
Seems like there's a reasonable parallel here with video content. Before native video, video was always in a flash player, and that was good enough for a lot of people— it was proprietary of course, and it it required a plugin. But it worked.
Now with native video, there are still precious few instances where it's just the browser's native video widget. In basically all serious commercial scenarios, there's at least custom player chrome, navigation buttons, overlays, JavaScript to pause the video and play an unskippable interstitial, etc etc.
I would argue that the current state of affairs for 3D viewers is closer to the current state of affairs for video than it is to the Flash player story of 15 years ago. No, there is no explicit "model viewer" widget, but you could just as easily argue that WebGL canvas is to 3D content what <video> is to h264 and webm content.
As long as they still use a <video> tag does the chrome or JS implementation matter? The tag captures the semantics that Google can now use to show the video in their search results! etc. Using custom plugins like Flash made this much harder.
My understanding is that a lot of the "custom" players out there today are lightly-skinned <video> tags. Custom controls are a very small part of what it means to make a video player
> In our "current world", if you want a 3D viewer, you use WebGL and Javascript, and voila, what you get is what you see in all browsers that support WebGL.
Under "Considered Alternatives" [0]
> 4. Do not add a new element. Pass enough data to WebGL to render accurately
> As noted above, this would require any site that wants to use an AR experience to request and have the user trust that site enough to allow them access to the camera stream as well as other information. A new element allows this use case without requiring the user to make that decision.
I’m not convinced a script-less element protects privacy: recall that subtle differences in how different machines (running the same browser) render certain <canvas> operations, it’s a given that the same underlying hardware differences will lead to subtle 3D model rendering differences (e.g. subpixel antialiasing, measuring shader render time, etc) and thus add another way for unscrupulous websites to fingerprint users.
Another issue is that it’s inevitable that support for fragment and vertex shaders will be added, which is another huge issue (MS put-off supporting WebGL for years out of plausibly legitimate concerns about possible vulnerabilities in WebGL shaders).
…of course that’s all fine on Apple’s uniform hardware: fingerprinting MacBook users with their identical GPUs will be harder compared to PC users with their huge matrix of possible GPU chipsets, GPU drivers, and GPU performance/quality settings - which all affect how simple 3D models are rendered.
It seems history teaches us the exact opposite. Nobody uses the native input elements because they can't be sufficiently styled and customized but simultaneously have significant behavior differences between browsers. They also of course languished for the longest time, at points looking out of place with the browser chrome itself.
As a user, I curse every time a website decides that my theme is incompatible with my computer's theme and that my scroll bar should in fact be bright red and 1 pixel wide just like on the designer's Macbook, and that buttons should look exactly like tabs, links, checkboxes and radio boxes because that's what the brand designer wanted. Native component's can't be styled because of very good reasons and unless you're developing a game they probably shouldn't be.
HN uses purely native components and it's one of the best websites I regularly visit. Fast, responsive, works on every device. I can't help but feel like web developers recreating native components are doing so out of incompetence or complete disregard of usability.
What you're describing is a failure of particular designers and developers to build an acceptable user experience. But that doesn't mean that good front-end designers and developers don't exist, or that good UI/UX doesn't exist outside of native browser controls.
I'm a front-end developer, and I currently work with one of the best UI designers in the industry (she's really, incredibly good). We consistently get very positive feedback on our work - currently rebuilding the front-end UI for a unicorn SaaS startup.
Good UI controls take a lot of work on small details even beyond the design mocks - event handling, styling, keyboard navigability, layout behavior, configurable options... but when it all comes together it feels great to use.
What are you talking about? The vast majority of sites use native input elements.
The percentages are going to be different, though, depending on whether you're talking about text boxes, dropdowns, or date pickers. (After all, Safari only introduced native support for date pickers this past April, according to MDN's compatibility table [1].)
Couldn’t you host a model custom element implementation on a cdn and get almost all those same benefits? I would rather see a turn to custom elements over extending the browser’s native set of tags further.
FYI, browsers have been separating out the cache for each website for a long time, so you will have to re-download that implementation from the CDN for each website that uses it.
Years of trying to treat models like images shows us it's a poor idea. Maybe now with Disney/Epic PBR being the standard material model it's closer but, that Panic truck? Good luck defining the exact lighting for that so it renders correctly and consistently.
The spec text even says that the lighting environment will come at a later date. So, no, you don't seemingly have any control over one of the most important parts that makes the visuals of your scene. Even VRML could do that.
Also seemingly no word on the camera position, or FOV, or anything else.
So it doesn't seem feasible to get even remotely matching renders, at which point, why bother?
>This proposal does not aim to define a mechanism that allows the creation of a 3D scene within a browser using declarative primitives or a programmatic API.
the goal isn't to fully render scenes, it's simply to gain the ability to include a 3d resource in the page semantically. heavier solutions to render scenes already exist.
So true. I'd be curious about developing modern web standards without JavaScript. I'm aware of gopher/gemini but somehow i like the semantic aspects of the web.
It makes no difference that you now call some boxes with some new names as those boxes get custom styling and behavior anyway. There is no semantics (no meaning) behind the names.
Even there are proposals how to use elements "semantically correct" nothing enforces it. So it's useless in the big picture. You can't rely on any semantic meaning. As a trivial example, everybody is free to put a h1 below a h6. It will "work"… Because there is just no semantic meaning to those names!
Things like Gemini are interesting as they show a route to tech that separates again documents and applications working with documents. Gemini tries to get the document part right I think.
Only in a model where you don't strive for pixel perfection and customizable behaviors for every piece of rendered content something like semantic meaning of those peaces could arise: There would need to be some agreed meaning because the client would be in charge of rendering and bringing everything to live. But this model is not the web. Not any more…
> As a trivial example, everybody is free to put a h1 below a h6. It will "work"… Because there is just no semantic meaning to those names!
Well you took the most obvious counter-example, but there's plenty of semantics in HTML. See for example picture/source element, or audio/video. Both as a user and website operator who deals with people in several languages, i cannot have strong enough words for my appreciation of adding subtitles to a video using just `<track kind="subtitles" srclang="en" label="English" src="foobar.vtt">` without having to modify the media container server-side as previously.
Little features like this may sound insignificant to you if you only use the web for forums and blogposts, but they're in my view a great accessibility/internationalization win. h1-h6, unless used in a serious publication, has indeed no semantic meaning other than "make that one bigger than this one". But for deeper semantics, there's schema.org microdata and indieweb.org microformats, which enable deep interoperability/federation between websites with entirely different tech stacks. I would personally appreciate if either/both were standardized as part of the Web instead of the entire JavaScript craze, but saying the web has no semantics is ignoring decades of innovation in this field with very practical applications and i don't think that's very fair.
> separates again documents and applications(...). Gemini tries to get the document part right I think.
I strongly appreciate this separation, as i'm personally interested in document browsers, not applications platforms (i've already got an OS and desktop environment for that). However, i'm not sure gemini gets it "right" (very subjective). I like that there is a document format focused on plaintext UX, and i very much intend to support it on my websites sooner or later. I'm part of the tildeverse where gemini grew and is nowadays thriving. However, in order to reduce bloat, gemini has pretty much given up on every useful semantic aspect of the web. What's left in gemtext is: one-level lists, three-level headings, and preformatted text (code/quotes).
No more alternative text for linked images (unless you want it displayed for everyone including clients like lagrange which support inline images), no more federated mentions/replies like indieweb.org, no more scraping...
> Only in a model where you don't strive for pixel perfection and customizable behaviors for every piece of rendered content something like semantic meaning of those peaces could arise (...) this model is not the web. Not any more…
I'm not sure that's entirely true. Some part of me agrees with the argument, but on the other hand i don't see a reason why a proper semantic markup couldn't provide a suggested pixel-perfect layout which the browser could freely ignore to make its own. Also, when you disable JavaScript entirely, the web is a very capable semantic document platform.
All in all, i don't have a clear opinion on the topic. But i'm sure it's worth investigating. I'm all ears for resources and projects in such directions (either more semantics in gemini, or less interactive stuff in the web). Thanks for taking the time to come up with a thoughtful answer!
Mistake was killing flash instead of boiling it down to a more minimal API and just using that, instead of spending the last 10 years poorly reinventing flash.
Sorry "basic needs" refered to "basic needs" in terms of 3D rendering. It was an answer to people elsewhere in the thread complaining that this new element would not support lighting and other sophisticated 3D rendering features.
I agree that 3D/VR is definitely not a basic need for the web and i personally don't want/intend to use it. That being said, if there is an established 3D model standard, i think it's better overall if the browser implements it properly, rather than having two dozen half-baked JS implementations eating all your CPU/RAM just to display a tiny square.
Just like technically you can parse an MP4 video frame by frame using JS to display each frame in a canvas, doesn't mean you should. <video> element is much better suited to that, and if that element had not been standardized, we would arguably have to choose between "Youtube browser" and Flash player fallback, which is arguably worse for everyone involved.
PS: Also as other have pointed out in the thread 3D on the web is over two decades old yet has never been standardized. See also https://en.wikipedia.org/wiki/VRML
Isn't that to say it adds a model that you can't see? It's just an invisible element on the page? If it's not being rendered, what are you seeing? If it is being rendered, what are the shaders? Camera? Etc that webgl solve? Or are these not essential complexity?
The problem is no feature set will meet even 5% of the needs of most devs.
Maybe you'd like to display a "model" of a city. Oh, too big, needs to be streamed, LODed, etc. Maybe you'd like to display a "model" of a forest. Oh, well, you need a terrain renderer that dynamically generates geometry from height data plus you need a specialized renderer to render the grass and bushes else the frame rate will be 1fps. You'd like to display a "model" of Waikiki Beach at sunset and you'd like to use a water shader with a sunset and reflections. You'd like to display a "model" of the Los Angeles mountains as viewed from downtown Los Angeles, complete with atmospheric ray scattering to convey the air quality. You'd like to render a fur covered animal and render fur, not just a texture. You'd like to render a "model" of a person with realistic hair. You'd like to render a "model" of wax candle with subsurface scattering so it actually looks like a candle. You'd like to render a "model" of camera lenses to explain refraction so you'd actually like them to refract.
Engines like Unreal and Unity let you change the way they render because every situation requires different solutions. No generic "render a model" covers rendering all models. An API like WebGPU/WebGL lets devs add what they need.
Oh, you say, we'll just add features to cover those use cases. Now Chrome will have features A,B,C, Firefox, A,B,D, Safari B,E. That will be hell for devs. An API lets people write libraries with features they need that work in all browsers. They don't have to wait for the magic day N years from now that all browsers finally add the feature they want.
Further, people will keep requesting non-3D features "I want to have an <input type="text"> in my scene". "I want to have a <canvas> in my scene" that I can draw on in realtime. "I want to have a model that displays a <canvas> in my model so people can draw logos on their avatar's t-shirts". I want to play sounds in 3D from specific points in my model, etc. until this "model tag" has all of HTML and all of JavaScript inside
Again, this is all better solved with APIs instead of trying to cram more and more and more features into a single tag.
> The other challenge of doing everything yourself is that code is stuck in time. It's going to get very minimal benefits from browsers and devices getting better over time, it won't get native UI changes - in 5 years it'll look very dated, if it's still accessible.
And neither will a model tag. In fact it will be worse. First off, when I put a model on my page, I want it to look they way I or my artist created it. I don't want it to change over time based on someone else's idea of how it should look.
Yeah I actually agree -- this is very in line with the semantic web and is in many ways is a much more elegant proposal than Canvas (though I love canvas). This will make it much easier for devs to embed a 3D model in a page without sideloading all of three.js or similar monstrosities. It will also enable 3D model search engines to more easily find models on the web because of the semantic <model> tag.
3D is a poor choice for many visualizations because when it is rendered in 2D, information is hidden behind the model being transformed over time (either manually by the user or via automatic rotation, etc).
IMO it should only be considered if there are challenges with flattening the data in question. For example, if the data represents an actual scanned 3D object.
On the other hand, rendering arbitrary data as "3D" models is usually a cute waste of time. There are much more effective ways to explore and analyze it.
Instead of spending time on the new vague proposal, maybe Apple should spend time supporting existing web standards like WebGL 2.0 by default (instead of hidden flags).
It makes a lot of sense to me as well having seen code for model viewers using WebGL. Before gltf, (relatively) standardized PBR materials, etc. it kind of made sense to just give people WebGL and tell them to figure it out. Also WebGL clearly was designed for browser games and game engine ports where it makes sense. As 3D models become more common, having robust fast implementations, standard controls, etc makes sense. As long as WebGL/WebGPU interop is good so it's possible to customize materials or still use model loading (if you want) but do your own draw calls I think it's fine
But also, it'd be pretty cool if this was implemented as a browser extension, that way it could be much faster to iterate over.
I wonder why this is not common practice? Modifying browser internals is such a pain that it strikes me as odd that it is the 1 established way of going about this proposals.
If I am not wrong, a functional version can be written in plain JS (+ WASM?) using Custom Elements (tho tag names must contain a hyphen). Except I don't know why all the non-Google stakeholders are hell bent on sabotaging Custom Elements. While Google is doing so much innovation in that space. Strange.
Came here to say that. They could do a custom element implementation, perhaps ship that (in their own namespace), offer polyfills for other browsers and go on from there.
I think such an element would be welcome, and make it easier to add 3D elements to websites. A while ago I wanted to share some 3D models with people, but there weren't any good options. I found a couple sites that lets you upload .obj files, but you need an account and they worked by embedding renderers in iframes. If 3D models had better browser support I hope there would emerge some sites that would let you upload and share them as easy as regular images now.
I don't think it's stranger than having a video tag even though we could embed video without it previously. Having a dedicated 3D tag would make websites more semantic. Hiding stuff in canvas tags like Googles Flutter is the wrong way to go, so bringing stuff out of canvas tags when possible should be encouraged.
Edit: I also think this can be compared to the svg tag. Sure, you could use canvas and webgl and render a 2D vector image using some javascript library. But with svg, you don't have to, and you can style it with css etc.
I don't agree with the tag name though. IMO, "model" is a singular 3D object. Such a tag should support scenes with multiple objects in them.
> I don't think it's stranger than having a video tag even though we could embed video without it previously. Having a dedicated 3D tag would make websites more semantic.
Video had literally thousands of commonly used sites embed third party players before we got a standard.
> A while ago I wanted to share some 3D models with people, but there weren't any good options.
So in contrast to video no one gives a shit?
> If 3D models had better browser support I hope there would emerge some sites that would let you upload and share them as easy as regular images now.
We have APIs to render 3D content (WebGL) have APIs to load random files from a site what more do you need for obj files?
> I don't agree with the tag name though. IMO, "model" is a singular 3D object. Such a tag should support scenes with multiple objects in them.
And what format will you use to describe these Scenes? obj doesn't handle animations or complex structures. What you want isn't a browser but a complete game engine.
> Video had literally thousands of commonly used sites embed third party players before we got a standard.
Yes, and now I can right click a video and open it in it's own tab, pop it open in an overlay, or download it easily.
> So in contrast to video no one gives a shit?
It's historically been more difficult to create 3D models than images or video. Now phones have lidar, photogrammetry is becoming more accessible, there are ML models that create 3D from 2D, 3D printers have been around for a while, etc. 3D could be more popular if it was easier to share and display.
> We have APIs to render 3D content (WebGL)
That gives you a GL context, then you need javascript to render the scene and add interactivity from mouse events etc.
> have APIs to load random files from a site what more do you need for obj files?
Something like imgur where I can upload a file and send the link to people, and have it work in their chat client and browsers. Something that makes it easy to add a 3D visualization to articles.
> And what format will you use to describe these Scenes? obj doesn't handle animations or complex structures.
Apple uses the USDZ format in their examples, and there's also the glTF format. But obj and stl files should be supported as well.
> What you want isn't a browser but a complete game engine.
Game engines does much more than render 3D scenes. They also handle image loading, audio, video, network connections, user input... You're right, browsers does have a lot in common with game engines.
> 3D could be more popular if it was easier to share and display.
Could be more popular? The APIs are already there, literally nothing stops you from writing a pure js lib that supports 3d models in a way that you want and can be reused on any site that needs it.
Video didn't have that, video needed 3rd party plugins to even run. Video still managed to attract a sizeable user based before that.
> You're right, browsers does have a lot in common with game engines.
The same way a toaster and a fridge both handle food. Of course I am all in favor of dropping Chrome for Unreal I think the later doesn't call home half as much.
> Could be more popular? The APIs are already there, literally nothing stops you from writing a pure js lib that supports 3d models in a way that you want and can be reused on any site that needs it.
The APIs are there, but not the renderer or a way to interact with it. I'm looking at it as a consumer, not a web developer. I don't want to have to write a library or use someones else's, that's the point. Browsers have native video controls when embedding mp4 files with the video tag, you could argue that could be done just fine with html and javascript instead.
> video needed 3rd party plugins to even run. Video still managed to attract a sizeable user based before that.
Of course video attracts lots of users, that one of the main use of internet for many. Besides Netflix and similar streaming, looking at short clips on Facebook and Reddit is why a lot of users open their browser in the first place. Should everything that's not as popular then be dismissed? Should we not have svg support in browsers? Should video decoders be shipped as webassembly blobs? Should we do like Google docs and render the whole page in a canvas tag?
> Of course I am all in favor of dropping Chrome for Unreal I think the later doesn't call home half as much.
Unreal uses Chromium Embedded Framework, so all you need to browse the web is the Unreal Engine and a build environment, and you can make your own web client. No need for extra browsers.
> I'm looking at it as a consumer, not a web developer
Then why do you care if it is part of the browser or just a library? A consumer doesn't need to know that, certainly wont interact with a model element directly.
> you could argue that could be done just fine with html and javascript instead.
Not at the time the video controls where introduced and now many sites use DRM which would prohibit a pure js implementation unless you want to piss of Netflix, Amazon, etc. .
> Should everything that's not as popular then be dismissed?
There are finite browser developers working with finite time and finite resources. Why spend any of that on something a random web dev. can easily implement as a JS library?
Please explain to me how Ogg Vorbis and Ogg Opus are still not supported, then. Please tell me why Apple has no answer for a patent-unencumbered format that replaces it. Better yet, please explain why Google’s “pet formats” are evil, bad, or even just not good. I’m tired of hearing this argument. So basically Google made WebM, so we can never have open formats in browsers? How is this really the answer that’s better for the web ecosystem?
Not supporting WebP had some merit, considering there were other answers, but WebM basically doesn’t have any better alternatives. Even iPhones have the necessary hardware to decode VP8 and VP9. Why does Firefox support WebM if it’s so bad for the web? Why is Apple even part of the AV1 alliance without releasing software that supports it?
I don’t like Apple getting a free pass on positive intent because it’s not Google. Whether its codecs (which Apple holds both MPEG-4 and HEVC patents,) or WebGPU shaders (nobody else wanted WSL, but Apple forced it on us, apparently because of SPIR-V IP conflicts,) people seemingly make up excuses for why it’s OK that they lag on standards that nobody else seems to have an issue with. It’s beyond frustrating. It’s infuriating. As a web developer, it’s a bigger problem to me than anything Google Chrome does, and trust me, that’s saying a lot.
I think apple should just fix their webgl implementation.
They seem to be missing a fundamental feature of the web it's interactive. They have an interactive attribute for the tag but no description of what this means? What does it mean to interact with a 3d model? Can 3d model interaction be accurately defined in a single attribute? Why not just use javascript for that logic?
The whole point of having multi media like a 3d model on a website is so people can interact with it. If the interaction is as simple as spin the model there are three.js and a million other javascript libraries that can do that in a few lines of code.
Another fundamental the proposal doesn't address is the model format? As far as I know all model file formats are proprietary OBJ is probably the closest to an open standard and its anything but standard. Another issue that javascript easily solves.
A fake problem their solution found is DRM, obviously the DRM could be removed as easy as HLS encryption (Super easy, did it yesterday). The main problem here is again the file format, no one would share their 3dmax file because its fucking huge they would export a low poly model for web that would be useless to anyone wanting to steal your model.
3D models are complicated. If the <model> element is complex enough to support anything the user decides to embed then it'll put a huge burden on browser developers. That's fine for Apple and Google, but it'd be another nail in Firefox's coffin. On the other hand, if the element only supports (say) the gltf spec then it won't be a simple case of adding a model for a non-technical user. They'd need to export or convert their model, textures, shaders, animations, etc.
3D support is probably an order of magnitude harder than video. And video is hard enough.
> You dont have to know how to encode/decode videos to add video to a page
Sure a non-coder could put an avi file in an html5 video tag but it won't work.
They will need to hire a coder to write code for their site that encodes the video to x264 hosts it on a CDN and then embed that in the site with the video tag.
My initial reaction to this was "just use WebGL", but they've made a pretty compelling case as to why that's not ideal:
> Consider a browser or web-view being displayed in Augmented Reality. The developer wants to show a 3D model in the page. In order for the model to look accurate, it must be rendered from the viewpoint of the user - otherwise it is a flat rendering of a three-dimensional image with incorrect perspective.
> A solution to this would be to allow the Web page, in particular the WebGL showing the 3D model, to render from the perspective of the user. This would involve granting too much private information to the page, possibly including the camera feed, some scene understanding, and very accurate position data on the user. It should not be a requirement that every Web page has to request permission to show a 3D model in this manner. The user should not have to provide access to this sensitive information to have the experience.
> Furthermore, there is more information needed to produce a realistic rendering, such as the ability to cast and receive shadows and reflections from other content in the scene, that might not be on the same Web page.
From that perspective, having the rendering handled by the browser seems like a smart idea.
I don't understand why passing a new view matrix to webGL is such a security risk or why that needs to be shared with he site owner.
I also think a window with a dynamic view matrix would make more sense in certain cases. Some techniques work when rendered to a surface that would not work in VR, ie screen space effects.
It’s not exactly eye tracking, but you know some advertisers are going to use it to make ads that turn to point directly at you.
But I’m not sure the proposed tag is a good idea either. I have not used VR but I think it might be a good thing if web browsers in VR stay flat and can’t take over the space in front or behind them?
> it might be a good thing if web browsers in VR stay flat and can’t take over the space in front or behind them
IMO the preferred implementation would be for the <model> tag to be a window into a 3d space "behind" the browser that's only visible if you look through that window. Maybe a small area in front of the window would also be acceptable. You wouldn't want it taking over space outside its designated area though without either going "fullscreen" or getting some other form of permission.
Presumably if Apple is proposing it, then they are already implementing it in Safari and will eventually enable it, and either it will be terrible and nobody will use it, or it will be great, and the rest of the browser vendors will need to catch up.
A model is no better than a image without animation. So at the minimum it needs to support animation. But of course an animation with no interactivity is no better than a video. So it needs to support interactivity. Now you're talking about a bunch of scripting, to which (as they point out) Babylon and Three.js are well suited. I don't see the point of adding this to the browser when canvas exists, unless the point is to take components out of Babylon/Three and put them into fast browser code.
241 comments
[ 3.2 ms ] story [ 367 ms ] threadRendered <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.
I do buy 3d model data occasionally (hobby, not for professional uses). I think most stores obfustcate the data somehow although I never took a look at it in detail. If you wanted, you probably could easily extract the model from the preview.
I still think this is a very bad proposal. Why compare something with an image and then disallow it to be treated like other ressources? This is typically bad corporate influence on the web.
I think we should go the other way. Remove DRM components from browsers again. Netflix not available anymore? They will either adapt or not be available. Their loss would probably be more significant.
Because webgl fingerprinting. Also, I'm not sure why you think not being able to extract the data using javascript is "bad corporate influence on the web" or" DRM". you can still do whatever you want. The models are freely available for you just not the page.
Just because something is common doesn't mean it's good for you.
I'm not against closed software mind you, I'm using some myself, but the web as a platform has reached this amazing stage because it's been built on openness. And now the very same companies that became rich thanks to this openness want to close it to get all the benefits for themself.
As per the parent comment, it's not exposed to the javascript running on the page, which is arguably the "dev" in this case.
>Not you the client, hence the user.
I fail to see how it being exposed to the javascript running on the page or not makes a meaningful difference to the user. Are we expecting the average user to interact with the page via the developer console or something?
>and we all have seen where it leads to.
The proposal doesn't have any DRM element at all. At worse you can just inspect network traffic to download the model file to disk and open it in whatever app you want.
No, but I'm expecting the average user to be able to enjoy an open ecosystem. Such as bookmarklet, addons, client side widgets, electron apps, WASM plugins, and all the wonderful things we can't yet think of now.
Instead, we will have one more walled garden.
And just like that, piece by piece, the next step in the IT revolution will be more and more close. Because that's the plan, that's what they want. Something the computer runs, but has no control over.
But there's still webgl and <canvas>. I'm failing to see what type of use cases we're missing out on here, because javascript access is missing.
But without it youd need a Netflix app on your PC... And what safeguards does that have from hoovering my pc usage up for sale or marketing? Atleast Netflix only gets MY Netflix consumption for their metrics and ML, and isn't cross referencing the games I play or other things I'm doing at the same time.
Contrast that to the now ubiquitous conferencing software solutions, and it seems like every day there's some zero-day RCE vulnerability or other spooky exploit.
If we needed to install and run a dozen different closed-source executables from BigCorp et al., I predict that we'd very soon go back to security dark-ages.
I can certainly see that apparently there are a lot of HN commenters who would like to go back to the days of IE and no real web technologies or much progress, but I think practically everyone outside this bubble prefers their browser experience to be at least somewhat feature-rich, and while the proposal under question may be strictly unnecessary, it should be weighed against alternatives: bundling a model viewer with every page view.
Maybe this proposal is bad and a waste of resources, but I don't like the knee-jerk response of digging one's heels in and decrying any and all browser APIs as bloat.
Not entirely directed at you, but your response just seems to echo something I see very often.
All these arguments serve, when they are successful in hobbling the browser as an app platform, is too push developers into native apps in the app store. And then the developer doesn't need to fingerprint you, they get your identity just for asking.
Meanwhile, browsing habits (sites visited + time of day of visit) is enough to fingerprint the vast majority of people. And sites do collude on the backend to share this data with advertisers, long before the user ever gets a chance to block it in the client app.
If privacy fetishists see the browser as a sinking ship, they don't seem to realize they are trying to bail out the Titanic with a teaspoon, or that there is no such thing as dry land. The only way to stay private is too stay off the network entirely.
Not fan of the prospect of Apple doing the same. If I wanted to make what Apple is making, I would have to rely on webgl. Them inventing something for their own use case when other stuff exists feels just unnecessary. Their proposal also includes a 3d format no one uses (except them I guess), as an attempt to shoehorn it in or something.
Who are the people that should be making browser spec proposals, if not the people building browsers?
Yes, it sucks if you want to write your own browser, and now have to play catch up with the big boys throwing their weight around. But I don't think this is points against Google or Apple. Our browser technology shouldn't be held back by some romantic dream of individuals being able to build one from scratch, despite what many HNers seem to think. Even the best mechanics and engineers will struggle to build a car comparable to whatever rolls off of the large production lines. (I understand maybe that's a poor analogy, since you don't need all the bells and whistles of a new Toyota to be road-legal, while you do kind of need to keep up with the spec in order to be internet-usable (although there still are some IE11 holdouts..)).
My concern is basically that if we force browsers to be spec-compliant and wait for the due process concerning new features, we pump the brakes on everything, and we risk stalling genuinely beneficial updates.
glTF 2.0 is widely supported although the quality of that support is variable. The spec is fairly large and every tool that exports glTF does so in a subtly different way.
For instance Blender adds a rotation transform node before every mesh to convert from Y-up (Blender) to Z-up (glTF). Animations run in Y-up space and target the node before that final rotation node. The BabylonJs exporter for 3dsMax converts its meshes and animations to z-up as part of the export process. Many glTF loader implementations get tripped up on this (failing to support more than one model mesh or failing to respect the full transform hierarchy or failing to support animations). There are similar complexities and support issues around vertex data formats, buffer layouts, punctual lights etc
My limited reading of the USD format is that it has an even wider specification. My concern is that browser support will splinter even worse than it would with glTF. The' model' proposal doesn't dig into what USD nodes will and won't be supported and exactly how the data is expected to be rendered.
https://graphics.pixar.com/usd/docs/
The closest thing I can find there is the glossary and the C++ doxygen api docs.
VRML was more like 3D, inline SVG, before SVG in the browser was a thing. It was markup in the page. And it was meant to be scriptable and interactive. This is none of those things.
And it is awesome.
WebGL support on safari is ropey at best why would apple implement a standard written by some one else when they can create a new standard no one asked for?
Don’t be deceptive. Inaccurate generalizations and hyperbole add nothing to the discussion.
I for one think this is a future proofing move with little current utility. However I’m not one who thinks the AR/VR/ 3D Models in browser bandwagon is going anywhere within the next 5 years.
Are you going to specify yet another new 3D model format as a standard target for browser to support?
Presumably browsers would support the most popular formats, just as they do with images and video. And just as with images and video, we'll likely end up in a situation where m most formats are supported by most browsers, with a couple odd formats that are only supported by some. Doesn't seem like a huge deal.
Unless apple is proposing to elevate some existing implementation, that already has interop across various platforms, then I think anything they do would necessarily be Yet Another Format.
Get to see a nice blank screen for both. Once you fiddle with all the settings so you aren't looking out from the inside of a monochrome polygon, you're going to approach the same complexity as the webgl version
The term "model" is a pretty generic term that's very relevant to HTML, already used heavily in Web frameworks, etc.
> It would be possible to reuse one of the generic embedding elements, such as <embed> or <object>, for this purpose. However, we think that 3D content should behave like other media types.
I think their argument is that although it is semantically possible to use object, they think this would be clearer for the future.
Seems a bit pointless really.
(I understand that other webkit forks could have this code easily applied.)
It's not synonymous with HTML. Chrome's browser engine is now unfortunately synonymous with "the web" in general. And, while it's derived from WebKit, it's diverged from it too far, and bears a different name, https://en.wikipedia.org/wiki/Blink_(browser_engine)
So in a way, the value in this proposal is that it is less capable than the from scratch approach, and can be implemented safely just in the browser.
There's lots of good reasons to semantically want to embed a 3d model in a page, like any other type of media. Say you're writing a course explaining how differential gears work - a 3d model of that could be really handy to look at to learn. A shoe company wanting to have a model of their sneakers in their shop.
Sure we've got canvas, and WebGL, and WebGPU, and libraries like three.js, which work. But wow you gotta get a lot of JS slapped together to just get something rendering. E.g. I wonder how long transit spent getting a truck rendering on this page. https://panic.com/transmit/
The other challenge of doing everything yourself is that code is stuck in time. It's going to get very minimal benefits from browsers and devices getting better over time, it won't get native UI changes - in 5 years it'll look very dated, if it's still accessible.
A model element makes a lot of sense to me.
Ways of navigating a 3D model also vary wildly. Sometimes you just want to pivot/rotate them around a little, but sometimes "walking" inside them makes more sense.
Then there are materials and lights, and here people go wild with ideas.
In our "current world", if you want a 3D viewer, you use WebGL and Javascript, and voila, what you get is what you see in all browsers that support WebGL.
> But wow you gotta get a lot of JS slapped together to just get something rendering
Indeed. But there are some quite nice 3D model viewers out there ready to roll, easy to embed, and full of features.
[0]https://docs.microsoft.com/en-us/dotnet/api/system.windows.m...
Now with native video, there are still precious few instances where it's just the browser's native video widget. In basically all serious commercial scenarios, there's at least custom player chrome, navigation buttons, overlays, JavaScript to pause the video and play an unskippable interstitial, etc etc.
I would argue that the current state of affairs for 3D viewers is closer to the current state of affairs for video than it is to the Flash player story of 15 years ago. No, there is no explicit "model viewer" widget, but you could just as easily argue that WebGL canvas is to 3D content what <video> is to h264 and webm content.
Under "Considered Alternatives" [0]
> 4. Do not add a new element. Pass enough data to WebGL to render accurately
> As noted above, this would require any site that wants to use an AR experience to request and have the user trust that site enough to allow them access to the camera stream as well as other information. A new element allows this use case without requiring the user to make that decision.
[0] https://github.com/WebKit/explainers/tree/main/model#conside...
Another issue is that it’s inevitable that support for fragment and vertex shaders will be added, which is another huge issue (MS put-off supporting WebGL for years out of plausibly legitimate concerns about possible vulnerabilities in WebGL shaders).
…of course that’s all fine on Apple’s uniform hardware: fingerprinting MacBook users with their identical GPUs will be harder compared to PC users with their huge matrix of possible GPU chipsets, GPU drivers, and GPU performance/quality settings - which all affect how simple 3D models are rendered.
HN uses purely native components and it's one of the best websites I regularly visit. Fast, responsive, works on every device. I can't help but feel like web developers recreating native components are doing so out of incompetence or complete disregard of usability.
I'm a front-end developer, and I currently work with one of the best UI designers in the industry (she's really, incredibly good). We consistently get very positive feedback on our work - currently rebuilding the front-end UI for a unicorn SaaS startup.
Good UI controls take a lot of work on small details even beyond the design mocks - event handling, styling, keyboard navigability, layout behavior, configurable options... but when it all comes together it feels great to use.
This is definitely not true. Not even close.
What are you talking about? The vast majority of sites use native input elements.
The percentages are going to be different, though, depending on whether you're talking about text boxes, dropdowns, or date pickers. (After all, Safari only introduced native support for date pickers this past April, according to MDN's compatibility table [1].)
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
https://modelviewer.dev/
https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...
The spec text even says that the lighting environment will come at a later date. So, no, you don't seemingly have any control over one of the most important parts that makes the visuals of your scene. Even VRML could do that.
Also seemingly no word on the camera position, or FOV, or anything else.
So it doesn't seem feasible to get even remotely matching renders, at which point, why bother?
the goal isn't to fully render scenes, it's simply to gain the ability to include a 3d resource in the page semantically. heavier solutions to render scenes already exist.
You see where this is going right?
The semantic web is dead since invention.
It makes no difference that you now call some boxes with some new names as those boxes get custom styling and behavior anyway. There is no semantics (no meaning) behind the names.
Even there are proposals how to use elements "semantically correct" nothing enforces it. So it's useless in the big picture. You can't rely on any semantic meaning. As a trivial example, everybody is free to put a h1 below a h6. It will "work"… Because there is just no semantic meaning to those names!
Things like Gemini are interesting as they show a route to tech that separates again documents and applications working with documents. Gemini tries to get the document part right I think.
Only in a model where you don't strive for pixel perfection and customizable behaviors for every piece of rendered content something like semantic meaning of those peaces could arise: There would need to be some agreed meaning because the client would be in charge of rendering and bringing everything to live. But this model is not the web. Not any more…
Well you took the most obvious counter-example, but there's plenty of semantics in HTML. See for example picture/source element, or audio/video. Both as a user and website operator who deals with people in several languages, i cannot have strong enough words for my appreciation of adding subtitles to a video using just `<track kind="subtitles" srclang="en" label="English" src="foobar.vtt">` without having to modify the media container server-side as previously.
Little features like this may sound insignificant to you if you only use the web for forums and blogposts, but they're in my view a great accessibility/internationalization win. h1-h6, unless used in a serious publication, has indeed no semantic meaning other than "make that one bigger than this one". But for deeper semantics, there's schema.org microdata and indieweb.org microformats, which enable deep interoperability/federation between websites with entirely different tech stacks. I would personally appreciate if either/both were standardized as part of the Web instead of the entire JavaScript craze, but saying the web has no semantics is ignoring decades of innovation in this field with very practical applications and i don't think that's very fair.
> separates again documents and applications(...). Gemini tries to get the document part right I think.
I strongly appreciate this separation, as i'm personally interested in document browsers, not applications platforms (i've already got an OS and desktop environment for that). However, i'm not sure gemini gets it "right" (very subjective). I like that there is a document format focused on plaintext UX, and i very much intend to support it on my websites sooner or later. I'm part of the tildeverse where gemini grew and is nowadays thriving. However, in order to reduce bloat, gemini has pretty much given up on every useful semantic aspect of the web. What's left in gemtext is: one-level lists, three-level headings, and preformatted text (code/quotes).
No more alternative text for linked images (unless you want it displayed for everyone including clients like lagrange which support inline images), no more federated mentions/replies like indieweb.org, no more scraping...
> Only in a model where you don't strive for pixel perfection and customizable behaviors for every piece of rendered content something like semantic meaning of those peaces could arise (...) this model is not the web. Not any more…
I'm not sure that's entirely true. Some part of me agrees with the argument, but on the other hand i don't see a reason why a proper semantic markup couldn't provide a suggested pixel-perfect layout which the browser could freely ignore to make its own. Also, when you disable JavaScript entirely, the web is a very capable semantic document platform.
All in all, i don't have a clear opinion on the topic. But i'm sure it's worth investigating. I'm all ears for resources and projects in such directions (either more semantics in gemini, or less interactive stuff in the web). Thanks for taking the time to come up with a thoughtful answer!
This seems like a very specific use case, which I think is best left to custom code.
I agree that 3D/VR is definitely not a basic need for the web and i personally don't want/intend to use it. That being said, if there is an established 3D model standard, i think it's better overall if the browser implements it properly, rather than having two dozen half-baked JS implementations eating all your CPU/RAM just to display a tiny square.
Just like technically you can parse an MP4 video frame by frame using JS to display each frame in a canvas, doesn't mean you should. <video> element is much better suited to that, and if that element had not been standardized, we would arguably have to choose between "Youtube browser" and Flash player fallback, which is arguably worse for everyone involved.
PS: Also as other have pointed out in the thread 3D on the web is over two decades old yet has never been standardized. See also https://en.wikipedia.org/wiki/VRML
Maybe you'd like to display a "model" of a city. Oh, too big, needs to be streamed, LODed, etc. Maybe you'd like to display a "model" of a forest. Oh, well, you need a terrain renderer that dynamically generates geometry from height data plus you need a specialized renderer to render the grass and bushes else the frame rate will be 1fps. You'd like to display a "model" of Waikiki Beach at sunset and you'd like to use a water shader with a sunset and reflections. You'd like to display a "model" of the Los Angeles mountains as viewed from downtown Los Angeles, complete with atmospheric ray scattering to convey the air quality. You'd like to render a fur covered animal and render fur, not just a texture. You'd like to render a "model" of a person with realistic hair. You'd like to render a "model" of wax candle with subsurface scattering so it actually looks like a candle. You'd like to render a "model" of camera lenses to explain refraction so you'd actually like them to refract.
Engines like Unreal and Unity let you change the way they render because every situation requires different solutions. No generic "render a model" covers rendering all models. An API like WebGPU/WebGL lets devs add what they need.
Oh, you say, we'll just add features to cover those use cases. Now Chrome will have features A,B,C, Firefox, A,B,D, Safari B,E. That will be hell for devs. An API lets people write libraries with features they need that work in all browsers. They don't have to wait for the magic day N years from now that all browsers finally add the feature they want.
Further, people will keep requesting non-3D features "I want to have an <input type="text"> in my scene". "I want to have a <canvas> in my scene" that I can draw on in realtime. "I want to have a model that displays a <canvas> in my model so people can draw logos on their avatar's t-shirts". I want to play sounds in 3D from specific points in my model, etc. until this "model tag" has all of HTML and all of JavaScript inside
Again, this is all better solved with APIs instead of trying to cram more and more and more features into a single tag.
> The other challenge of doing everything yourself is that code is stuck in time. It's going to get very minimal benefits from browsers and devices getting better over time, it won't get native UI changes - in 5 years it'll look very dated, if it's still accessible.
And neither will a model tag. In fact it will be worse. First off, when I put a model on my page, I want it to look they way I or my artist created it. I don't want it to change over time based on someone else's idea of how it should look.
Yay! OpenGL with extensions all over again
https://webglreport.com/?v=2 reports 10 extensions.
And you can get the full spectrum over GL, GL ES and Vulkan, here https://gpuinfo.org.
But then I thought, maybe they're niche because something like this doesn't already exist
IMO it should only be considered if there are challenges with flattening the data in question. For example, if the data represents an actual scanned 3D object.
On the other hand, rendering arbitrary data as "3D" models is usually a cute waste of time. There are much more effective ways to explore and analyze it.
Or you can just model your item in solvespace (or link an STL file) and export it as HTML. Done.
https://solvespace.com/index.pl
Examples: http://m-labs.hk/software/solvespace/
But also, it'd be pretty cool if this was implemented as a browser extension, that way it could be much faster to iterate over.
I wonder why this is not common practice? Modifying browser internals is such a pain that it strikes me as odd that it is the 1 established way of going about this proposals.
https://modelviewer.dev/
I don't think it's stranger than having a video tag even though we could embed video without it previously. Having a dedicated 3D tag would make websites more semantic. Hiding stuff in canvas tags like Googles Flutter is the wrong way to go, so bringing stuff out of canvas tags when possible should be encouraged.
Edit: I also think this can be compared to the svg tag. Sure, you could use canvas and webgl and render a 2D vector image using some javascript library. But with svg, you don't have to, and you can style it with css etc.
I don't agree with the tag name though. IMO, "model" is a singular 3D object. Such a tag should support scenes with multiple objects in them.
Video had literally thousands of commonly used sites embed third party players before we got a standard.
> A while ago I wanted to share some 3D models with people, but there weren't any good options.
So in contrast to video no one gives a shit?
> If 3D models had better browser support I hope there would emerge some sites that would let you upload and share them as easy as regular images now.
We have APIs to render 3D content (WebGL) have APIs to load random files from a site what more do you need for obj files?
> I don't agree with the tag name though. IMO, "model" is a singular 3D object. Such a tag should support scenes with multiple objects in them.
And what format will you use to describe these Scenes? obj doesn't handle animations or complex structures. What you want isn't a browser but a complete game engine.
Yes, and now I can right click a video and open it in it's own tab, pop it open in an overlay, or download it easily.
> So in contrast to video no one gives a shit?
It's historically been more difficult to create 3D models than images or video. Now phones have lidar, photogrammetry is becoming more accessible, there are ML models that create 3D from 2D, 3D printers have been around for a while, etc. 3D could be more popular if it was easier to share and display.
> We have APIs to render 3D content (WebGL)
That gives you a GL context, then you need javascript to render the scene and add interactivity from mouse events etc.
> have APIs to load random files from a site what more do you need for obj files?
Something like imgur where I can upload a file and send the link to people, and have it work in their chat client and browsers. Something that makes it easy to add a 3D visualization to articles.
> And what format will you use to describe these Scenes? obj doesn't handle animations or complex structures.
Apple uses the USDZ format in their examples, and there's also the glTF format. But obj and stl files should be supported as well.
> What you want isn't a browser but a complete game engine.
Game engines does much more than render 3D scenes. They also handle image loading, audio, video, network connections, user input... You're right, browsers does have a lot in common with game engines.
Could be more popular? The APIs are already there, literally nothing stops you from writing a pure js lib that supports 3d models in a way that you want and can be reused on any site that needs it.
Video didn't have that, video needed 3rd party plugins to even run. Video still managed to attract a sizeable user based before that.
> You're right, browsers does have a lot in common with game engines.
The same way a toaster and a fridge both handle food. Of course I am all in favor of dropping Chrome for Unreal I think the later doesn't call home half as much.
The APIs are there, but not the renderer or a way to interact with it. I'm looking at it as a consumer, not a web developer. I don't want to have to write a library or use someones else's, that's the point. Browsers have native video controls when embedding mp4 files with the video tag, you could argue that could be done just fine with html and javascript instead.
> video needed 3rd party plugins to even run. Video still managed to attract a sizeable user based before that.
Of course video attracts lots of users, that one of the main use of internet for many. Besides Netflix and similar streaming, looking at short clips on Facebook and Reddit is why a lot of users open their browser in the first place. Should everything that's not as popular then be dismissed? Should we not have svg support in browsers? Should video decoders be shipped as webassembly blobs? Should we do like Google docs and render the whole page in a canvas tag?
> Of course I am all in favor of dropping Chrome for Unreal I think the later doesn't call home half as much.
Unreal uses Chromium Embedded Framework, so all you need to browse the web is the Unreal Engine and a build environment, and you can make your own web client. No need for extra browsers.
Then why do you care if it is part of the browser or just a library? A consumer doesn't need to know that, certainly wont interact with a model element directly.
> you could argue that could be done just fine with html and javascript instead.
Not at the time the video controls where introduced and now many sites use DRM which would prohibit a pure js implementation unless you want to piss of Netflix, Amazon, etc. .
> Should everything that's not as popular then be dismissed?
There are finite browser developers working with finite time and finite resources. Why spend any of that on something a random web dev. can easily implement as a JS library?
Not supporting WebP had some merit, considering there were other answers, but WebM basically doesn’t have any better alternatives. Even iPhones have the necessary hardware to decode VP8 and VP9. Why does Firefox support WebM if it’s so bad for the web? Why is Apple even part of the AV1 alliance without releasing software that supports it?
I don’t like Apple getting a free pass on positive intent because it’s not Google. Whether its codecs (which Apple holds both MPEG-4 and HEVC patents,) or WebGPU shaders (nobody else wanted WSL, but Apple forced it on us, apparently because of SPIR-V IP conflicts,) people seemingly make up excuses for why it’s OK that they lag on standards that nobody else seems to have an issue with. It’s beyond frustrating. It’s infuriating. As a web developer, it’s a bigger problem to me than anything Google Chrome does, and trust me, that’s saying a lot.
They seem to be missing a fundamental feature of the web it's interactive. They have an interactive attribute for the tag but no description of what this means? What does it mean to interact with a 3d model? Can 3d model interaction be accurately defined in a single attribute? Why not just use javascript for that logic?
The whole point of having multi media like a 3d model on a website is so people can interact with it. If the interaction is as simple as spin the model there are three.js and a million other javascript libraries that can do that in a few lines of code.
Another fundamental the proposal doesn't address is the model format? As far as I know all model file formats are proprietary OBJ is probably the closest to an open standard and its anything but standard. Another issue that javascript easily solves.
A fake problem their solution found is DRM, obviously the DRM could be removed as easy as HLS encryption (Super easy, did it yesterday). The main problem here is again the file format, no one would share their 3dmax file because its fucking huge they would export a low poly model for web that would be useless to anyone wanting to steal your model.
They can't even make a key-value storage that doesn't break every other release, you expect them to get something involving complex math to work?
Vs a single tag to embed a model. For a non-coder. You dont have to know how to encode/decode videos to add video to a page.
Im surprised it's taken this long. (Whether it'll turn out good, not sure, but it will definitely be adopted, and fast)
3D models are complicated. If the <model> element is complex enough to support anything the user decides to embed then it'll put a huge burden on browser developers. That's fine for Apple and Google, but it'd be another nail in Firefox's coffin. On the other hand, if the element only supports (say) the gltf spec then it won't be a simple case of adding a model for a non-technical user. They'd need to export or convert their model, textures, shaders, animations, etc.
3D support is probably an order of magnitude harder than video. And video is hard enough.
If it's not needed, why do the setup in the webGL API?
Sure a non-coder could put an avi file in an html5 video tag but it won't work.
They will need to hire a coder to write code for their site that encodes the video to x264 hosts it on a CDN and then embed that in the site with the video tag.
Safari is supporting WebGL 2 soon; it's already in preview.
> Another fundamental the proposal doesn't address is the model format?
It would probably be glTF.
> Consider a browser or web-view being displayed in Augmented Reality. The developer wants to show a 3D model in the page. In order for the model to look accurate, it must be rendered from the viewpoint of the user - otherwise it is a flat rendering of a three-dimensional image with incorrect perspective.
> A solution to this would be to allow the Web page, in particular the WebGL showing the 3D model, to render from the perspective of the user. This would involve granting too much private information to the page, possibly including the camera feed, some scene understanding, and very accurate position data on the user. It should not be a requirement that every Web page has to request permission to show a 3D model in this manner. The user should not have to provide access to this sensitive information to have the experience.
> Furthermore, there is more information needed to produce a realistic rendering, such as the ability to cast and receive shadows and reflections from other content in the scene, that might not be on the same Web page.
From that perspective, having the rendering handled by the browser seems like a smart idea.
Feels like Apple is working on something that needs this.
Edit: it's on the first paragraphs of the MDN page about <canvas> [1]:
> First introduced in WebKit by Apple for the OS X Dashboard, <canvas> has since been implemented in browsers. Today, all major browsers support it.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/...
I also think a window with a dynamic view matrix would make more sense in certain cases. Some techniques work when rendered to a surface that would not work in VR, ie screen space effects.
But I’m not sure the proposed tag is a good idea either. I have not used VR but I think it might be a good thing if web browsers in VR stay flat and can’t take over the space in front or behind them?
IMO the preferred implementation would be for the <model> tag to be a window into a 3d space "behind" the browser that's only visible if you look through that window. Maybe a small area in front of the window would also be acceptable. You wouldn't want it taking over space outside its designated area though without either going "fullscreen" or getting some other form of permission.