W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: Text Selection

From: Denis Bohm <denis@fireflydesign.com>
Date: Wed, 3 Nov 2004 18:53:41 -0800
Message-ID: <004701c4c219$8af88410$71307f42@DRAGONFLY>
To: "Ian Hickson" <ian@hixie.ch>, "Doug Schepers" <doug@schepers.cc>
Cc: <www-svg@w3.org>

On Wednesday, November 03, 2004 5:10 PM, Ian Hickson wrote:
> On Mon, 1 Nov 2004, Doug Schepers wrote:
> >
> > | This section doesn't define what should happen if the
> > | selection crosses out of the <svg> element into other
> > | content. For example, why is the |selection| attribute on the
> > | SVGSVGElement interface instead of the document?
> >
> > Why would we need to worry about that? Surely, the SVG Spec need only
> > define what happens within the scope of an SVG document, and a Compound
> > Documents Spec should fill in the gaps on interaction between other
> > Specs.
>
> No. SVG will be implemented by user agents that support other namespaces
> natively, and SVG needs to describe how its features will work in all
> contexts, otherwise it can't be implemented.
>
> It is definitely not in the CDF charter to come behind other working
> groups and clean up their mess if their specs are under-defined.
>
>
> > Otherwise, HTML would have to define, as part of its Spec, how every
> > HTML element or attribute interacts with every SVG element; in that
> > case, no Spec would ever be able to leave Last Call.
>
> SVG and HTML together _do_ define how every HTML element and attribute
> interacts with every SVG element and attribute, at least to the same
> extent as HTML attributes are defined in pure-HTML environments.
>
> 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.
Received on Thursday, 4 November 2004 02:54:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC