[Seaside] SVG design questions

Sebastian Sastre ssastre at seaswork.com
Wed Apr 9 14:49:27 UTC 2008

This encourage the initiative: 



Sebastian Sastre




	De: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] En nombre de Gerhard
	Enviado el: Miércoles, 09 de Abril de 2008 07:22
	Para: Seaside - general discussion
	Asunto: Re: [Seaside] SVG design questions
	It looks very cool, so please create a squeak package on squeaksource
and assign me as developer!
	AFAIK Inline SVG hast too many drawbacks (especially on IE), so the main
goal should be the rendering for linked SVG documents.
	BTW: Which version are you using!
	I think it should be developed for Seaside 2.9!

	On 4/9/08, Lukas Renggli <renggli at gmail.com> wrote: 

		Hi Holger,
		Gerhard is also interested working on that. So I suggest that
		collaborate ;-)
		>  The first issue is the canvas. Subclassing the existing
canvas seems to be
		> a bad idea:
		>  - SVG has an extensive set of tags. Combining this with the
extensive set
		> of HTML tags will end up in one large bulky mess
		>  - the SVG anchor has the same tag as the HTML anchor, but
requires the
		> xlink namespace for the href attribute, so it requires a
different anchor
		> brush
		>  - SVG and HTML cannot be freely mixed, so it's not necessary
to combine the
		> both in a single class.
		I suggest that you create your own "namespace" that you can
		from the html canvas. This would be an object that knows the
		underlying rendering context, but only has the SVG relevant
		So that you can write:
		  html svg line
		     from: 1 @ 1;
		     to: 100 @ 100
		Or for embedded SVG rendering I imagine writing something like:
		   html svg: [ html renderSvgOn: html svg ]
		Where renderSvgOn: would look like:
		   renderSvgOn: svg
		      svg line
		         from: 1 @ 1;
		         to: 100 @ 100
		>  Currently, I've subclassed WACanvas, not WARenderCanvas.
Rendering inlined
		> SVG will require switching the canvas. Currently I see no
problems here, but
		> maybe I'm wrong.
		I think that's the way to go.
		>  Another issue is inlining SVG vs. separate SVG documents.
Quite often I've
		> seen some caveats about inlining SVG (e.g. see
		> http://wiki.svg.org/Inline_SVG). On the other hand, I see some
		I have no experience with that.
		I think inlining seems simpler to start with. Have a look at the
		#iframe brush to see how to create a specific document as part
of the
		>  Embedding with <object>
		>  -----------------------
		>  I've tried to implement rendering of external SVG documents
that are
		> included as <object> in the HTML document, and kind of
		>  http://www.smallish.org:7777/seaside/SVG/example
		Wow, that looks already very cool.
		Lukas Renggli
		seaside mailing list
		seaside at lists.squeakfoundation.org

More information about the seaside mailing list