Re: RCC question

> > Good point, but this would mean that for anything to ever get rendered
it
> > must be as if the shadow tree element was there instead of the custom
> > element.
>
> Not necessarily, I don't think you should think too much about
child/parent
> relationships, the custom element cannot be rendered, there's nothing to
> render - CSS styling has already been indicated is still an open issue, so
> we don't know about that.

Unfortunately I have to think about it, since I'm implementing this. My
current thinking is that the shadow node is a lot like a EntitiyReference
node, where the CHILDREN of the shadow node are used instead of the custom
element. Actually, one way of looking at things could be to say that RCC is
an extension of entity references.

> >>> <MyNamespace:DropShadow id="drop_shadow".....>
> >>>
> >>> <ellipse filter="url(#drop_shadow)" />
> >
> > Why do you think that? Basically, when the SVG UA searches for an
element
> > with id drop_shadow, it finds the custom element,
>
> No it doesn't, your custom element's id="drop_shadow" isn't an ID in XML
> terms (unless you've included the DTD etc. to make it so) so an SVG UA
would
> not find it like that, you'd need to use XPath or similar to get at the
> element.  That's the XML architectural problem.  I have no problem with
you
> being able to use and define filters in that way, that's useful, and XPath
> is mentioned for SVG 1.2 so it could be done, or we have a proper
revolution
> and sort out  xml:id  and the SVG WG are taking on all sorts of other
stuff
> so go for it!

You are of course right, but as you say, the id can be specified in a dtd,
an internal dtd for example, which I believe an xml processor must support,
and I don't think we should throw this idea away just because of that little
technicality, but at least we agree that it's useful :)

Also, we don't necessarily need a solution to it. If you think about what I
wrote above on.. "...where the CHILDREN of the shadow node are used instead
of the custom element"

so if you have

<prototype>
<filter...>
</prototype>

SVGBindEnd
{
evt.target.shadowTree.firstChild.setAttribute("id",
evt.target.getAttribute("id"))

// I assume that ids don't need to be unique across the custom elements
owner document and the shadow trees?
}

And then

<MyNamespace:DropShadow id="drop_shadow">

<ellipse filter="url(#drop_shadow)">

When searcing for the "drop_shadow" id, and it checks
MyNamespace:DropShadow, it doesn't look on that element, but searches the
shadow tree node on that element instead.

How's that?

> > I've come up
> > with a few more requirements for RCC, which are that RCC components
should
> > be able to fire custom events,
>
> I don't think anyone is suggesting otherwise, in fact most RCC components
> I've seen involving firing events, we need Namespace aware events (which
is
> why XML events are useless currently) but otherwise there's no problem
here.
>
> > have custom properties (no, I'm not talking
> > about attributes) and methods.
>
> So what sort of attributes do you mean?

I was just thinking about the htc approach, where you are making components,
a component usually have these three things:
EVENTS
PROPERTIES
METHODS

But I admit I'm a little unknowledgable at this particular time :)

what if you have

<elementDef name="Test">
<script>
function CallMe()
{
}
</script>
</elementDef>

<script>
someTestElement.CallMe()    // Calling a method
</script>

should the above work? or does it already work in some implementation? I
have no idea how the script context would be.

--
Sigurd Lerstad

Received on Monday, 24 November 2003 12:33:50 UTC