Re: Third release of Constraint SVG browser

[Hmm, I notice that my Reply-To didn't get noticed here on www-svg.
Maybe the Mail-Followup-To the list software inserted overrode it?]

Doug Schepers:
> "I have not had the leisure to check out your browser, but I did read an
> early version of your work, and I think it's brilliant and very useful.
> IIRC, there has been some speculation for the inclusion of XPath in SVG, and
> I think that the WG would do well to be inspired by your extensions."

Thanks!

> I especially like that your content is now backwards-compatible with other
> viewers, though the necessary verbosity make me hope something like this, in
> the future, will be available in standard SVG, at least in certain profiles.
> 
> I should read more before speculating, but I can't help but mention that
> this seems like it would make a table/grid be a snap.

Yes, I think having shapes position themselves relative to text is
pretty handy.

> I may be reading too much into it, or speculating too far, but adding
> limited script elements could even be used for pseudo-declarative
> drag-and-drop:
>      <rect x="40" y="35" width="100" height="100" c:draggable="false">
>          <set c:nameSpace="c" attributeName="draggable" begin="mousedown"
> value="true"/>
>          <set c:nameSpace="c" attributeName="draggable" begin="mouseup"
> value="false"/>
>          <c:constraint attributeName="x" value="evt.clientX"/>
>          <c:constraint attributeName="y" value="evt.clientY"/>
>      </rect>

Now that would be cool!  Couple of problems though.  Firstly, Batik
doesn't support SMIL animation (yet!) so the set wouldn't work.  And
secondly, the values would still have to be written as XPath, not
ECMAScript.  Some way of providing access to event objects to the XPath
expressions sounds like a good idea, though.

> This is an instance where having the constraints as child elements is
> actually useful, rather than merely verbose. I'm not sure that this is a
> useful example, but other things like it would certainly be... nice work,
> Cameron et al.
> 
> How CPU-intensive is this approach? I know that there was some concern that
> XPath would be "costly".

Done properly, I don't think it should be an issue.  (In my
implementation at the moment there is still some work to be done on
efficiency, though.)  You can compile down XPath expressions into
something that is more easily executable.

Cameron

-- 
Cameron McCormack
|  Web: http://mcc.id.au/
|  ICQ: 26955922

Received on Thursday, 26 February 2004 18:24:52 UTC