Re: RCC question

>
> "Sigurd Lerstad" <sigler@bredband.no> wrote in message
> news:009b01c3adee$4cfdd0b0$6e1273d5@mmstudio...
> > When a custom element has a shadow tree element. Does things work as if
> the
> > shadow tree element was there instead of the custom element, or as if
the
> > shadow tree element was a child of the custom element?
>
> AIUI a sort of child, it's not really there at all remember...

What does AIUI mean?

If it's as a child, then that would mean that the custom element must be a
graphical container for the (sort of ) child to be rendered.

> > The difference is important, let's say the custom element has a
transform
> > attribute,
>
> How could it have a transform attribute?  It's not an SVG element, you
can't
> put SVG attributes on it, the semantics won't translate.
>
> > or some style attributes,
>
> The same with style, consider jimML which has this:
>
> <donkey style="shiny" transform="SendTo(_mop)"/>
>
> The SVG UA cannot use the attributes as SVG ones.

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.

From ASV6 Implementation White Paper:

Interface SVGCustomElement:
Inherits from svg::SVGElement, svg::SVGStylable, svg::SVGTransformable,
events::EventTarget.

Can you explain that to me? It looks like they've made all custom elements
into graphic containers... I do not like that at all, and your point above
has convinced me.

> > <MyNamespace:DropShadow id="drop_shadow".....>
> >
> > <ellipse filter="url(#drop_shadow)" />
>
> the id on your element probably can't be used like that - you'll have to
use
> an XPATH selector or something.
>
> > What do you think?
>
> It'd be nice, but I don't think the XML architecture is appropriate to do
> the job.
>

Why do you think that? Basically, when the SVG UA searches for an element
with id drop_shadow, it finds the custom element, but instead of returning
the custom element, it returns the shadow element, and there you go :) I
should mention that I'm asking these questions because I'm an implementor,
and my tests so far have been very good and look promising. I've come up
with a few more requirements for RCC, which are that RCC components should
be able to fire custom events, have custom properties (no, I'm not talking
about attributes) and methods. One can simple use the same syntax as in htc.

And a definite YES to be able to attach components (or behaviors in htc
terminology) on custom elements through css styling.

Moreover, I don't think that RCC should be limited to SVG, there should be a
common syntax for all xml languages, at least xhtml and svg, to define
custom behavior on elements, there is a CSS draft from 1999 on this on the
css3 page, I don't know why they didn't continue work on that.

HTC is IE and XBL is netscape, there should be one standard, and RCC in SVG
seems like something that can become that standard (though it should be
renamed to something else)

--
Sigurd Lerstad

Received on Friday, 21 November 2003 14:30:08 UTC