By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,918 Members | 1,923 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,918 IT Pros & Developers. It's quick & easy.

EOLAS and SVG graphics

P: n/a
VK
Does anyone knows a reputable comment on the EOLAS beserk in
application to imported SVG / VML graphics?

Say if I have a SVG graphics in the DOM tree and I script it onload (so
it starts blinking/shrinking/whatever) is it an EOLAS violation?

May 24 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
VK wrote:
Does anyone knows a reputable comment on the EOLAS beserk in
application to imported SVG / VML graphics?
I'm guessing that means, has anyone had any problems with scripting
SVG in Internet Explorer after installing the active-x patch that
resulted from the EOLAS ruling?
Say if I have a SVG graphics in the DOM tree and I script it onload (so
it starts blinking/shrinking/whatever) is it an EOLAS violation?


The EOLAS patent patch affects activeX components and user
interaction with them. If you are loading your SVG via an activeX
component (say, the Adobe SVG viewer), your scripts will work, but the
user will have to click once or press the spacebar to "activate" the
component. You aren't "violating" anything, you can't "violate"
anything - that's the point of the patch.

If you have SVG elements as part of the DOM, I've no idea what will
happen as I've no experience of rendering SVG this way.

One change I have noticed with IE after the patch is that it will not
render SVG in the adobe viewer activex if the source file does not have
the extension ".svg" or ".svgx" - it completely ignores the mimetype,
so if you (like us) are generating your svg server-side, you have to
have your server-side script end in .svg (and set up your server to
process script in these files)

May 24 '06 #2

P: n/a
VK

ne**@chthonic.f9.co.uk wrote:
If you have SVG elements as part of the DOM, I've no idea what will
happen as I've no experience of rendering SVG this way.


Unfortunately it is exactly my problem as I don't use any plugins -
only build-in renderers (SVG/Gecko VML/IE) and direct DOM Tree
handling. That is what I cannot catch out of EOLAS: whether it applies
to <object> / <embed> only or on anything moving/singing/playing by
default on the page, no matter what origin would be?

May 24 '06 #3

P: n/a

VK wrote:
ne**@chthonic.f9.co.uk wrote:
If you have SVG elements as part of the DOM, I've no idea what will
happen as I've no experience of rendering SVG this way.


Unfortunately it is exactly my problem as I don't use any plugins -
only build-in renderers (SVG/Gecko VML/IE) and direct DOM Tree
handling. That is what I cannot catch out of EOLAS: whether it applies
to <object> / <embed> only or on anything moving/singing/playing by
default on the page, no matter what origin would be?


The EOLAS patch only affects IE and only covers object and embed
elements
that aren't written to the page by JavaScript. Ok, that's a
simplification, but
it's good enough for this discussion.

IE has no built in renderer for SVG as far as I know - you have to
trigger the
Adobe SVG Viewer to render the content. For Example:
http://jwatt.org/svg/demos/xhtml-with-inline-svg.xhtml

For whatever reason, this doesn't trigger the EOLAS workaround, even
though
there is an object element on the page.

Why do you need to ask this? Can't you test your implementation and see
how
it works for you?

May 24 '06 #4

P: n/a
VK

ne**@chthonic.f9.co.uk wrote:
IE has no built in renderer for SVG as far as I know
IE has build in VML renderer which I use (SVG/Gecko - VML/IE)
Why do you need to ask this? Can't you test your implementation and see
how it works for you?


I don't care about technical obstacles (I don't have any in application
to EOLAS). My question is about "legal purity" of solutions made for
US-residing clients.

May 24 '06 #5

P: n/a

VK wrote:
ne**@chthonic.f9.co.uk wrote:
IE has no built in renderer for SVG as far as I know


IE has build in VML renderer which I use (SVG/Gecko - VML/IE)
Why do you need to ask this? Can't you test your implementation and see
how it works for you?


I don't care about technical obstacles (I don't have any in application
to EOLAS). My question is about "legal purity" of solutions made for
US-residing clients.


It is the browser that is violating the patent, not your pages. Sure
the workarounds that Microsoft implemented can affect the way your
content is presented, but you haven't violated the patent, as far as I
can see.

May 24 '06 #6

P: n/a
VK

ne**@chthonic.f9.co.uk wrote:
It is the browser that is violating the patent, not your pages.


Hah! This aspect did not dawn on me. You are possible very right, as I
see EOLAS now it is about UA capabilities, not about content providers.

May 24 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.