W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

RE: Agenda, Thu 26 Feb, 2009 telcon

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Fri, 27 Feb 2009 05:42:07 -0800
To: "alexander.adam@examotion.com" <alexander.adam@examotion.com>, 'Erik Dahlström' <ed@opera.com>, "'Chris Lilley'" <chris@w3.org>
CC: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <D23D6B9E57D654429A9AB6918CACEAA97C2F40D3E2@NAMBX02.corp.adobe.com>
That implies that you would need a browser-specific method?  How would my plugin know who its parent is?  Again, no standard API for integrating the DOM of the browser with the DOM of the plugin - or even just communicating back to the DOM?

Wouldn't it make more sense if we could convince the HTML5 committee, in their work to improve "browser experiences" for users to also focus on the needs of plugin developers?   It seems from my reading of HTML5 that they would rather replace all common plugins with "internal solutions" and support some standards (like SVG, to some extent) but not others (like MathML)?  And how does that help the innovation that plugins also bring for various other standards or even proprietary formats?

Am I missing something??


-----Original Message-----
From: Alexander Adam [mailto:alexander.adam@examotion.com] 
Sent: Friday, February 27, 2009 8:12 AM
To: Leonard Rosenthol; 'Erik Dahlström'; 'Chris Lilley'
Cc: public-svg-wg@w3.org
Subject: RE: Agenda, Thu 26 Feb, 2009 telcon

You could pickup the state by simply interacting with the browser, find your
parent, gather it's current transform stage and so on.. or within IE you
could also use binary extensions. However.. thanks to IE, it all is a hell
lot of work to properly to so :-)

mfG / Regards,
Alexander Adam
Geschäftsführer / CEO
examotion GmbH
Ostendstraße 115
90482 Nürnberg, Germany

Fon: +49 911 - 504901-11
Fax: +49 911 - 504901-20
E-Mail: alexander.adam@examotion.com
Web: http://www.examotion.com
Geschäftsführer: Alexander Adam
Amtsgericht Nürnberg HRB Nr.: 23803
Gerichtsstandort: Nürnberg

LEGAL DISCLAIMER: The information in this email is confidential and may be
legally privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted to be
taken in reliance on it, is prohibited and may be unlawful.

> -----Original Message-----
> From: public-svg-wg-request@w3.org [mailto:public-svg-wg-request@w3.org]
> On Behalf Of Leonard Rosenthol
> Sent: Freitag, 27. Februar 2009 14:09
> To: Erik Dahlström; Chris Lilley
> Cc: public-svg-wg@w3.org
> Subject: RE: Agenda, Thu 26 Feb, 2009 telcon
> AFAIK, there is no information about the current graphic state (which now
> includes transformations) provided to a plugin so that it can use that
> information to perform the necessary operations on its content.  The
> browser isn't going to do my styling/transforming for it...I have to do
> that myself, and in order to do so, I need information not currently
> provided...
> Leonard
> -----Original Message-----
> From: Erik Dahlström [mailto:ed@opera.com]
> Sent: Friday, February 27, 2009 7:42 AM
> To: Leonard Rosenthol; Chris Lilley
> Cc: public-svg-wg@w3.org
> Subject: Re: Agenda, Thu 26 Feb, 2009 telcon
> On Fri, 27 Feb 2009 13:25:15 +0100, Leonard Rosenthol <lrosenth@adobe.com>
> wrote:
> > I am sure this has come up during the actual telecons (which I apologize
> for not attending), but for those folks who have implemented SVG in a
> browser plugin (Adobe, Renesis, etc.), how are transforms expected to be
> supported?  AFAICT, the plugin model of the various browsers do not
> support this level of functionality...
> >
> > Leonard
> How are the transform properties any different from other CSS properties?
> In what way is the plugin model preventing this from being implemented?
> Cheers
> /Erik
> --
> Erik Dahlstrom, Core Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
> Personal blog: http://my.opera.com/macdev_ed
Received on Friday, 27 February 2009 13:43:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC