Re: Text Selection

At 06:53 PM 11/3/2004, Denis Bohm wrote:

> > For example, there is nothing ambiguous about this:
> >
> >    <test xmlns:html="http://www.w3.org/1999/xhtml"
> >          xmlns:svg="http://www.w3.org/2000/svg">
> >     <html:form>
> >      <svg:svg height="100" width="300">
> >       <svg:foreignObject height="100" width="300">
> >        <html:input name="q" type="text"/> <!-- this is rendered and gets
>submitted -->
> >       </svg:foreignObject>
> >       <html:p> bla </p> <!-- this is not painted -->
> >       <html:input name="c" value="x" type="hidden"/> <!-- this gets
>submitted -->
> >      </svg:svg>
> >     </html:form>
> >    </test>
> >
> > CSS defines how you render the non-SVG bits, SVG defines how you render
> > the bits from <svg:svg> to <svg:foreignObject>. DOM3 Events defines how
> > events flow through the whole thing.
>
>It seems to me that the above example is pretty much useless.  The SVG
>content is at the presentation level with known coordinate rendering on any
>platform.  But the HTML foreign block will almost certainly have different
>coordinate rendering on every platform.  Also, the SVG content can be
>scaled, but what happens to the HTML content - esp when it uses native
>controls?  It goes on and on...  The result is that the SVG content looks
>the same on all platforms, but there is a blob of HTML content that doesn't
>fit in on any platform.  Because of this I don't think the HTML content will
>ever be used this way - there is no presentation level control over how it
>looks.  And that's the whole point of SVG.

I agree with Denis.

I have the advantage of having been within the SVG working group when 
<svg:foreignObject> was introduced into the SVG language and I remember the 
intent of the SVG working group at the time.

Specifically, the only objective with <svg:foreignObject> was to provide an 
extensibility mechanism similar to the <html:object> tag. The contents 
inside the <svg:foreignObject> were meant for a totally separate, unknown, 
foreign (hence the name) user agent to parse the contents and render the 
contents, rendering what amounts to a rectangular raster image in return. 
During discussions, a common example was that a 3-D renderer (VRML or 3DIF) 
might be invoked to parse the contents inside the <svg:foreignObject> and 
do all of the processing of the content independently of anything that the 
SVG user agent might do. The specification talks about MathML and 
CSS-styled XML instead of the 3-D case because the working group felt it 
was better to talk about integrating SVG with W3C content types versus 
non-W3C content types. The exact wording from the spec, with emphasis added 
to the word "different":

-------------------------------------------
The 'foreignObject' element allows for inclusion of a foreign namespace 
which has its graphical content drawn by a DIFFERENT user agent....
-------------------------------------------

The SVG WG expected no interoperability between user agents that take 
advantage of <svg:foreignObject>. Anything within an <svg:foreignObject> 
has user-agent-specific behavior.

In the specific case of HTML within an <svg:foreignObject>, the SVG group 
believed that someday the W3C would figure out how to make that work in an 
interoperable manner, but that day has not arrived yet. The SVG 
specification shows an example of HTML inside of an SVG foreignObject, but 
note that the example contains a 'requiredExtensions' attribute which 
points to the URL which defines the user agent extension. The URL is a 
private URL (example.com/...), not the URL of the XHTML namespace. This was 
on purpose.

Denis points out one very difficult problem: native controls. If the Adobe 
SVG Viewer hosted the IE MSHTML control (which definitely counts as a 
DIFFERENT user agent) to render the embedded HTML, and the content was 
rotated or scaled, what would happen? It is not possible to transform 
native controls; they only know how to work when both upright and on top of 
everything else.

Note that the example only shows a <html:body> tag within the 
<svg:foreignObject>. Ian's example shows an <html:input> tag. Would it be 
legal to include include an <html:html> tag? Neither the SVG specification 
nor any other approved standard requires support for HTML within an 
<svg:foreignObject> and nothing today defines how it should work if you 
try. However, the Compound Document working group has started and perhaps 
they will define detailed processing rules.

Jon Ferraiolo
Adobe Systems, Inc.

Received on Thursday, 4 November 2004 05:36:00 UTC