4 ms·

Apple isn't doing anything that's incompatible with X3D. In fact, they didn't even specify which kinds of models they would accept (there's a `type` on the <sou

Apple isn't doing anything that's incompatible with X3D. In fact, they didn't even specify which kinds of models they would accept (there's a `type` on the <source> elements). You could easily point one of those at an X3D file. Sure, you could put an <X3D> tag into a HTML document, but there's no `<img>` equivalent (like you can use with SVG) to load that content from another URI. When dealing with extremely large (byte-wise) or complex shapes, having the option to load that data separately (or in a more efficient binary format) is obviously desirable.

zamalek 5y ago
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[...]
- bastawhiz 5y ago
  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.
  - zamalek 5y ago
    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 https://doc.x3dom.org/tutorials/basics/hello/index.html
dragonwriter 5y ago
> Sure, you could put an <X3D> tag into a HTML document, but there's no `<img>` equivalent (like you can use with SVG) to load that content from another URI. Yes, there is, the HTML <object> tag. https://www.web3d.org/x3d/content/HtmlObjectTagForX3d.html https://www.web3d.org/x3d/content/HtmlObjectTagForX3d.html
- bastawhiz 5y ago
  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 the same spec. We've done this numerous times in the last decade. The object tag isn't an X3D concept.
  - dragonwriter 5y ago
    > 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 <object>, 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.
    - true_religion 5y ago
      Yeah, if we all used object instead of image tags then you could just download an extension that filled in avif or webp and we could move forwards.
- shawnz 5y ago
  <object> is not a satisfactory equivalent for this <model> tag any more than it's a satisfactory equivalent for the <img> tag itself. <object> is semantically a superset of both.
  - dragonwriter 5y ago
    > <object> is not a satisfactory equivalent for this <model> tag any more than it's a satisfactory equivalent for the <img> tag itself. The main reason for having both <img> and <object> is that <img> existed first, and removing tags is almost always a bad idea because it brraks existing sites. > <object> 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.

zamalek 5y ago

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

bastawhiz 5y ago
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.
- zamalek 5y ago
  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 https://doc.x3dom.org/tutorials/basics/hello/index.html

dragonwriter 5y ago

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

bastawhiz 5y ago
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 the same spec. We've done this numerous times in the last decade. The object tag isn't an X3D concept.
- dragonwriter 5y ago
  > 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 <object>, 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.
  - true_religion 5y ago
    Yeah, if we all used object instead of image tags then you could just download an extension that filled in avif or webp and we could move forwards.
shawnz 5y ago
<object> is not a satisfactory equivalent for this <model> tag any more than it's a satisfactory equivalent for the <img> tag itself. <object> is semantically a superset of both.
- dragonwriter 5y ago
  > <object> is not a satisfactory equivalent for this <model> tag any more than it's a satisfactory equivalent for the <img> tag itself. The main reason for having both <img> and <object> is that <img> existed first, and removing tags is almost always a bad idea because it brraks existing sites. > <object> 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.