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

EMBED + overflow

P: n/a
Hi all.
I don't have a very deep understanding of CSS and this question might
sound stupid for you. Sorry for that.

Can the overflow CSS property be applied to the embed tag?

I have an embed tag whose source is big SVG file, whose dimensions are unknown.
If it is bigger than the screen, the rest of the SVG is clipped and not shown.
I would like to force the embed tag to scroll in that case.

But setting the overflow to scroll doesn't have any effect.

Can I set the overflow property on embed tag at all?

Thank you very much for help.

Anna
Jul 20 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Anna wrote:
Can the overflow CSS property be applied to the embed tag?
Since <embed> would be a replaced element, I would assume that it
does, however, <embed> is a non-standard, proprietary Netscape element,
so maybe that's why it doesn't.
I have an embed tag whose source is big SVG file, whose dimensions are unknown.


You should be using <object> as defined in the HTML 4.01 and XHTML
1.1 specifications, instead. However, IE doesn't support the standard
very well, only it's proprietry extensions. You should also be able to
use the <img/> element for SVG, when it's deleivered correctly as
"image/svg+xml".

--
Lachlan Hunt
http://www.lachy.id.au/
la**********@lachy.id.au.update.virus.scanners

Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!
Jul 20 '05 #2

P: n/a
On Sun, 30 May 2004 08:58:53 GMT, Lachlan Hunt
<la**********@lachy.id.au.update.virus.scanners> wrote:
Anna wrote:
I have an embed tag whose source is big SVG file, whose dimensions are unknown.
You should be using <object> as defined in the HTML 4.01 and XHTML
1.1 specifications, instead.


Nope, OBJECT isn't well enough defined for SVG (do links within the
object navigate the parent or jus the object's container?) use
IFRAME.
However, IE doesn't support the standard
very well, only it's proprietry extensions.
IE supports OBJECT for SVG just fine.
You should also be able to
use the <img/> element for SVG, when it's deleivered correctly as
"image/svg+xml".


Why should you be able to?

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #3

P: n/a
Jim Ley wrote:
On Sun, 30 May 2004 08:58:53 GMT, Lachlan Hunt
<la**********@lachy.id.au.update.virus.scanners> wrote:

Anna wrote:
I have an embed tag whose source is big SVG file, whose dimensions are unknown.


You should be using <object> as defined in the HTML 4.01 and XHTML
1.1 specifications, instead.


Nope, OBJECT isn't well enough defined for SVG (do links within the
object navigate the parent or jus the object's container?) use
IFRAME.


Why not, I thought you could use
<object type="image/svg+xml" data="image.svg">
<p>Alternate Content...</p>
</object>

From my experience, experementing with embedding XHTML documents
using <object> instead of <iframe>; links within an object's content
replace the contents of the object, not the parent/window, without
explicit use of the target attribute.
However, IE doesn't support the standard
very well, only it's proprietry extensions.


IE supports OBJECT for SVG just fine.


What? this seem contradictory. First you said OBJECT isn't well
defined for SVG, yet now you say IE supports it just fine. IE has
trouble supporting things which are well defined, let alone those which
are not.
You should also be able to
use the <img/> element for SVG, when it's deleivered correctly as
"image/svg+xml".

Why should you be able to?


Because SVG is an image format, which is why it should be served as
"image/svg+xml", so I assumed using <img/> would work. I included the
mime type, because I wasn't sure how UAs would work if it were delivered
as "application/xml" or "text/xml". It's possible they would work fine,
but it would mean the UA would need to read the file to determine which
type of XML it was, whether or not it was an XML image format, such as
SVG, and whether or not it supported the format.

--
Lachlan Hunt
http://www.lachy.id.au/
la**********@lachy.id.au.update.virus.scanners

Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!
Jul 20 '05 #4

P: n/a
you could just add it in your XML markup
Jul 20 '05 #5

P: n/a
On Sun, 30 May 2004 15:22:36 GMT, Lachlan Hunt
<la**********@lachy.id.au.update.virus.scanners> wrote:
From my experience, experementing with embedding XHTML documents
using <object> instead of <iframe>; links within an object's content
replace the contents of the object, not the parent/window, without
explicit use of the target attribute.
What even with flash?
What? this seem contradictory. First you said OBJECT isn't well
defined for SVG, yet now you say IE supports it just fine. IE has
trouble supporting things which are well defined, let alone those which
are not.


IT supports it, and something happens when you perform a navigation,
the problem is, it's not something that's been defined in the
specification - hence the problem with the definition of object.
You should also be able to
use the <img/> element for SVG, when it's deleivered correctly as
"image/svg+xml".

Why should you be able to?


Because SVG is an image format, which is why it should be served as
"image/svg+xml", so I assumed using <img/> would work.


Why is that a reasonable assumption to make? there's lots of image/*
which aren't rendered by browsers, and there's certainly no browser
out there which does a wide amoung of SVG that supports it under an
img ref.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #6

P: n/a
Firstly, this is completely off topic, and has turned into a discussion
which should probably be on c.i.w.a.html instead; however, I will still
attempt to answer you questions.

Jim Ley wrote:
On Sun, 30 May 2004 15:22:36 GMT, Lachlan Hunt
<la**********@lachy.id.au.update.virus.scanners> wrote:

From my experience, experementing with embedding XHTML documents
using <object> instead of <iframe>; links within an object's content
replace the contents of the object, not the parent/window, without
explicit use of the target attribute.


What even with flash?


I don't know, my experience with embedding flash, and other
technologies is minimal, that's one reason why I explicitly mentioned
embedded XHTML documents. Flash on other sites I've been to, tend to
open links in the parent, so I guess it depends on what's being
embedded. Although I'm at a loss, as to where that question came from,
and why you asked about linking when that wasn't the topic; but anyway,
I did my best to answer it.
You should also be able to
use the <img/> element for SVG, when it's deleivered correctly as
"image/svg+xml".

Why should you be able to?


Because SVG is an image format, which is why it should be served as
"image/svg+xml", so I assumed using <img/> would work.

Why is that a reasonable assumption to make? there's lots of image/*
which aren't rendered by browsers, and there's certainly no browser
out there which does a wide amoung of SVG that supports it under an
img ref.


I never mentioned anything about how well it was or was not
supported, I only mentioned that it should be able to be used. The HTML
4.01 specification's definition of the <img> element [1] only provides
examples of widely used image formats, and does not limit the formats
which can be supported in any way. Therefore, it should be completely
valid to embed SVG, or any other "image/*" type, using the <img/> element.

As it turns out, now that I've had time to test the various methods
of embedding SVG, the following lists the support using Internet
Explorer with Adobe's SVG Viewer 3.01 plugin.

<object>: Not Supported (standard implementation only,
not IE's confusing proprietary
implementation)
<img/>: Not Supported
<iframe>: Supported
<frame/>: Supported (within a <frameset>)
<embed>: Supported (but non-standard element)
Inline: Not Supported (using the XHTML 1.1 + MathML 2.0 + SVG 1.1 DTD)

I'd also like to know which ones work in an SVG enabled build of
Mozilla, or Opera if there's a plugin available for it, or with any
other plugins available for IE.

[1] http://www.w3.org/TR/html401/struct/....html#edef-IMG

--
Lachlan Hunt
http://www.lachy.id.au/
la**********@lachy.id.au.update.virus.scanners

Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!
Jul 20 '05 #7

P: n/a
On Mon, 31 May 2004, Lachlan Hunt wrote:
I never mentioned anything about how well it was or was not
supported, I only mentioned that it should be able to be used.
With respect - your original wording was capable of misinterpretation.
The HTML 4.01 specification's definition of the <img> element [1]
only provides examples of widely used image formats, and does not
limit the formats which can be supported in any way.
Fair comment.
Therefore, it should be completely valid to embed SVG, or any other
"image/*" type, using the <img/> element.

^^^^^^^^^^^^^^

NCSA X Mosaic used to support application/postscript as an image
format from <img...>, by the way. But, as you say, this is off-topic
for the present group.
Jul 20 '05 #8

P: n/a
Mozilla SVG-enabled build
<object>: Supported
<img/>: Not Supported
<iframe>: Supported
<frame/>: Supported (within a <frameset>)
<embed>: Not Supported
Inline: Supported (just using the svg namespace)

It's too bad <img/> isn't supported. Plus you can't use SVG with the
background: url() css property.
Jul 20 '05 #9

P: n/a
On Mon, 31 May 2004 10:42:03 GMT, Lachlan Hunt
<la**********@lachy.id.au.update.virus.scanners> wrote:

As it turns out, now that I've had time to test the various methods
of embedding SVG, the following lists the support using Internet
Explorer with Adobe's SVG Viewer 3.01 plugin.

<object>: Not Supported (standard implementation only,
not IE's confusing proprietary
implementation)
<img/>: Not Supported
<iframe>: Supported
<frame/>: Supported (within a <frameset>)
<embed>: Supported (but non-standard element)
Inline: Not Supported (using the XHTML 1.1 + MathML 2.0 + SVG 1.1 DTD)


I think these results are more due to the limitations of Internet
Explorer's plugin interface than anything else.

It seems that a lot of recent new ideas have shown that IE wasn't
designed with future expansion in mind. Observe the image loader only
supporting 1-bit transparency, the fact that plugins are limited to
rendering in a child window in response to a non-standard OBJECT
element, and the quite shaky XML namespace support.

They designed it for how things were at the time, and aren't doing
anything to make things better now.

I suspect (but do not know) that Mozilla would (could?) do a better
job of all this given that its SVG support is part of Gecko rather
than a plugin. I don't have an SVG-enabled version handy to test,
however.

Regards,
-Claire
Jul 20 '05 #10

P: n/a
On Mon, 31 May 2004 14:52:14 +0200, loufoque
<ma****************@nospam.wanadoo.fr> wrote:
Mozilla SVG-enabled build
<object>: Supported
<img/>: Not Supported
<iframe>: Supported
<frame/>: Supported (within a <frameset>)
<embed>: Not Supported
Inline: Supported (just using the svg namespace)

It's too bad <img/> isn't supported. Plus you can't use SVG with the
background: url() css property.


I had a hunt through Mozilla's bugtracker and found this:

Bug 231179: SVG Images in CSS
http://bugzilla.mozilla.org/show_bug.cgi?id=231179

I couldn't find anything for SVG images in IMG, but I imagine fixing
one would fix the other unless Mozilla does something very bizarre. I
guess one problem would be what to do with the interactive elements of
the graphic, if any; I suppose IMG could theoretically support them,
but having them interact with client-side image maps would be hairy.
Background images are non-interactive.

Then again, W3C probably thought of this and made accomodations for
non-interactive uses of SVG in the spec... I'm not really up on SVG
since I've not had much use for it thus far.

I think it's just the case that Mozilla's SVG support isn't finished.
This is probably why they don't include it in the official builds,
too! :)

Regards,
-Claire
Jul 20 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.