Live data from Hacker News

Apple proposes adding "model" element to HTML that displays 3D content

github.com

191–200 of 241 posts

Re: Apple proposes adding "model" element to HTML that displays 3D content

#191

The naming is unfortunate. 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.

Not only it can, it already exists.

https://modelviewer.dev/

Re: Apple proposes adding "model" element to HTML that displays 3D content

#192
We will need a full 3d rendering space for future applications anyway. It will require, that 2D content can be embedded in a 3D space and vice versa. Also a standardized 3D dom (with whatever usefully condensation of properties) will be required sooner or later, unless we want only some very big players to provide proprietary 3D environments.

I think, a "model" tag is a good and forward compatible path

Re: Apple proposes adding "model" element to HTML that displays 3D content

#193
post #128

It would be a great idea if WebGPU wasn't a thing. Imo Apple and big corp should double down on their WebGPU support instead of pitching their own ideas. And if they want to support something that is production ready, WebGL2 has been out there for a while.

Exactly, https://modelviewer.dev/

Re: Apple proposes adding "model" element to HTML that displays 3D content

#196

Earlier quoted context omitted.

Re-iterating the quote from my comment: > X3D is designed to be as integrated into HTML5 pages as other XML standards such as MathML and SVG. X3DOM[...]

And as I said, there's exactly nothing that makes the proposed tag incompatible with that idea. It's just another way of linking to that file. Inlining content is not universally desirable.

Yes, there is. X3D can be embedded into HTML exactly like SVG, per the quoted text and this example: https://doc.x3dom.org/tutorials/basics/hello/index.html

Re: Apple proposes adding "model" element to HTML that displays 3D content

#197
post #183

Earlier quoted context omitted.

> Sure, you could put an tag into a HTML document, but there's no ` ` equivalent (like you can use with SVG) to load that content from another URI. Yes, there is, the HTML tag. https://www.web3d.org/x3d/content/HtmlObjectTagForX3d.html

is not a satisfactory equivalent for this tag any more than it's a satisfactory equivalent for the tag itself. is semantically a superset of both.

> is not a satisfactory equivalent for this tag any more than it's a satisfactory equivalent for the tag itself.

The main reason for having both and is that existed first, and removing tags is almost always a bad idea because it brraks existing sites.

> is semantically a superset of both.

Yes, that's why given its existence, introducing new tags that offer a strict subset of its utility is unnecessary.

Re: Apple proposes adding "model" element to HTML that displays 3D content

#198
post #71

Earlier quoted context omitted.

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.

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

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

Re: Apple proposes adding "model" element to HTML that displays 3D content

#199
post #183

Earlier quoted context omitted.

is not a satisfactory equivalent for this tag any more than it's a satisfactory equivalent for the tag itself. is semantically a superset of both.

> is not a satisfactory equivalent for this tag any more than it's a satisfactory equivalent for the tag itself. The main reason for having both and is that existed first, and removing tags is almost always a bad idea because it brraks existing sites. > is semantically a superset of both. Yes, that's why given its existence, introducing new tags that offer a strict subset of its utility is unnecessary.

I think it's pretty clear that that is NOT the reason why still exists. Otherwise, why not just discourage its use in favour of while still retaining it for compatibility? But actually the opposite is true, is encouraged because it is more semantically descriptive and provides image-specific features that couldn't reasonably be added to .

If this line of thinking actually matched what the W3C believed, then how can you explain the addition of ANY of the new tags, for example, in the HTML 5 specification, since we already have the most general cases covered with things like and ? Following this to its logical conclusion, why not deprecate EVERY tag except those? Why have tags at all?

Re: Apple proposes adding "model" element to HTML that displays 3D content

#200

Earlier quoted context omitted.

> Sure, you could put an tag into a HTML document, but there's no ` ` equivalent (like you can use with SVG) to load that content from another URI. Yes, there is, the HTML tag. https://www.web3d.org/x3d/content/HtmlObjectTagForX3d.html

The object tag is problematic because it has a single interface for every supported content type . Want to expose functionality? Can't, unless it's a param that is passed as a string. Having a dedicated element type enables it to be used in many ways (like drawing images to a canvas) that an object tag does not support. It's also hardly a case of NIH to update a spec with a more specific element than another one in t…

> The object tag is problematic because it has a single interface for every supported content type. Want to expose functionality? Can't, unless it's a param that is passed as a string.

On a markup level, that's true of any tag.

On a functional level, it’s not true of , as the tag expects supported functionality to be defined separately for every type.

> Having a dedicated element type enables it to be used in many ways (like drawing images to a canvas) that an object tag does not support.

There’d nothing preventing the handler for a media type from doing that.

Post reply on HN