Re: Suggestions

>  > 1.
>  >
>  > remove <image>
>
> I'm not sure if there are (m)any reasons to make SVG 1.0
> forwards-incompatible.
>
>  > and have a xlink:href on <foreignObject> that links to
>  > an external resource, or
>  >
>  > have <externalObject> in place of <image> and have <inlineObject>
>  > instead of <foreignObject>
>  >
>  > This way, you first of all get closer to XHTML
>
> *Why* would this be a good thing in this case?

Well, not for the sake of getting closer to XHTML, but for the same reasons
that the XHTML group removed the <img> tag.

>  > with the removal of
>  > <img> and that <object> is always used instead, and you get a much
>  > clearer link between embedded/non-embedded objects, which should
>  > render the same way.
>
> I don't understand this.

Consider an authoring tool. You import some data, say an XHTML file, this
will typically be put in a <foreignObject> element, let's say the user wants
to link to the file instead of embedding it, will the authoring tool replace
the <foreignObject> with an <image> element? (And the other way around)..
see, it's just not logic.. also, it can't currently be done, since the
<image> element currently has a definition of

---------
The 'image' element indicates that the contents of a complete file are to be
rendered into a given rectangle within the current user coordinate system.
The 'image' element can refer to raster image files such as PNG or JPEG or
to files with MIME type of "image/svg+xml
---------

and it also has a preserveAspectRatio which <foreignObject> doesn't have.

I suggest, making <image> and <foreignObject> exactly the same, except one
links to an external resource, and the other is embeded inline. And also
make the naming of those elements more logic.

> [I commenting only on this one suggestion, which doesn't mean I agree
> with all the others.]

Since you say that, I must assume you disagree :)

> Tobi
>
> --
> http://www.pinkjuice.com/
>

Received on Saturday, 25 January 2003 06:03:24 UTC