Re: Does SVG 1.0 define this? (non-<svg> root element)

On Mon 14 Jun 2004, Ian Hickson wrote:

> On Mon, 14 Jun 2004, Dean Jackson wrote:
> > >    <foo>
> > >     <rect x="0" y="0" width="200" height="100" fill="blue"
> > >           xmlns="http://www.w3.org/2000/svg"/>
> > >    </foo>
> > >
> > > ...respectively.
> >
> > We only say what should happen when you use SVG in the context
> > of SVG. In your example, I assume that it would be the language
> > that owns <foo> that would decide.
> 
> Ah, interesting.  So if <foo> is being rendered according to CSS, then
> that SVG element would have no SVG semantics and should just be rendered
> as any arbitrary XML?  I guess that makes sense, yeah.

Yeah. The example I came up with was a speech markup. I have
no idea how you would "render" a <svg:rect> in that case, but
I'm confident that the speech markup would say how to do it.

> > Do you expect the SVG spec to say something in this case? Or, if this
> > isn't the behaviour you expect, what do you expect?
> 
> I didn't really have any expectations, I was just wondering if the SVG
> spec said something about how to handle elements in the SVG namespace
> outside of SVG contexts.
> 
> Unless I hear otherwise, I'll assume (for the purposes of conformance
> testing) that what you say above is what I should test. In other words,
> SVG elements in non-SVG contexts are handled as arbitrary XML elements and
> have no SVG-derived semantics.

I hate that word "semantics"! :)

Obviously it is still an <svg:rect>, but yes, as far as SVG is concerned
we don't expect any other grammar to handle our elements in a particular
way. Of course, they may choose to handle them differently, but that is
their choice.

> 
> Would you say this extended to the DOM interfaces too? That is, if I
> create an SVG element, does it have SVG interfaces if it is not in an SVG
> context?

Well, this is a really tough one. I don't think this is defined in any
spec, but I say "it depends".

As you know, in SVG we don't expect any non-SVG elements to have
their native DOM interfaces. The exception are elements in a 
<foreignObject> when you are in a processor that implements the
foreign namespace's native DOM.

Again, what another markup chooses to do is really up to it, but I assume
it has to respect the SVG rules when it is processing SVG.

eg.

<html:body>
  <svg:svg>
    <html:p id="a"/>
  </svg:svg>
</html:body>

Again, it's not explicit in the spec, but element a should not
have the HTML DOM interfaces. It's an unknown element in the SVG world.
If it were inside a <foreignObject> then it's up to the processor.

> (What about if it has no parent nodes, e.g. I just used
> createElementNS to create it?)

Ha. Well, that's pretty tricky isn't it?

These sound like really good compound document issues.

Dean

Received on Monday, 14 June 2004 08:50:34 UTC