- From: Denis Bohm <denis@fireflydesign.com>
- Date: Wed, 3 Nov 2004 18:53:41 -0800
- 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