Hacker News Reader

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.

Seems already possible using a custom web component.

You can also just render a complete OS in a canvas using wasm. Heck, why use the browser at all, just let them download a custom binary...

You see where this is going right?

Mistake was made when adding Javascript.

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.

There is no "semantic aspect" of the web.

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…

> 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.

Sure, but that doesn't make standardization useless so people stop reinventing this same wheel over and over again for very basic needs.

I wouldn't call "display a chair in a web page in an inexact and implementation-defined manner, with air quotes 'interactivity'" a "very basic need".

This seems like a very specific use case, which I think is best left to custom code.

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?

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.

[0]https://docs.microsoft.com/en-us/dotnet/api/system.windows.m...

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.

[0] https://github.com/WebKit/explainers/tree/main/model#conside...

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.

My first thought was "this probably wouldn't work for games, and other uses of embedded 3D content are pretty niche"

But then I thought, maybe they're niche because something like this doesn't already exist

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).

Agreed. This proposal makes the Safari sandbagging even more apparent.

This ^^ I’d be surprised if Apple has any new learning to offer or if they have surveyed the landscape and decided this is the way to go.

WebGL 2 will be enabled by default in Safari 15.

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.

yes and an example already exists here

https://modelviewer.dev/

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.

There's a medicine against the CDN craze.

https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...

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.

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

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.

> 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.

Yay! OpenGL with extensions all over again

It never stopped being an extension spaghetti, Khronos loves extensions.

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 wow you gotta get a lot of JS slapped together to just get something rendering.

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/

> WebGL export using Three.js, which is how the interactive models on this page work

Yes, it does the slapping together for you.

You can already embed VRML

I was just coming here to say this, but as a joke. :)

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's the tag for the native button that shows the up votes and downvotes on HN? Is it like <up-button/> or something?

> Nobody uses the native input elements

This is definitely not true. Not even close.

> Nobody uses the native input elements

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...

Safari supports date pickers now?! Wonders will never cease.