Parent Block Style Issue

23 views
Skip to first unread message

Jeff Coughlin

unread,
Dec 4, 2007, 9:46:07 PM12/4/07
to SWFObject Mailing List
I've had a site using SWFObject for over a year (v1.4.4 and later 1.5)
and I have a display problem after upgrading to 2.0_rc1.

The div where I have SWFObject replace it's output to <div
id="flashcontent"> has a style of "margin-top: -65px;" which is being
ignored when using SWFObject 2.0_rc1 (thus my swf file is being pushed
down). Other than that, the swf is loading fine (it's accepting all
of my custom vars, etc). For the record, I'm using option 2
(specifically the example using dot notation).

I've tested this in FF2.x, FF3.0_b1, Opera 9, and Safari 3 (on my Mac)
all with the same results.

Is this a bug or is something else going on?

Next I plan to view the DOM that SWFObject is producing from its js
and compare it with the output from 1.5 (I have a feeling that the
problem lies somewhere in there... perhaps I have to apply the style
to a child element?). Any advice is appreciated.

Regards,

---
Jeff Coughlin

Bobby

unread,
Dec 5, 2007, 6:37:34 AM12/5/07
to SWFObject
SWFObject 2.0 replaces your div element with an object element, so any
styles attached to that div will be replaced too.

You can solve your issue by:
- Attach the same styles to the div and the object element by adding
an id to the object element that refers to the same style rules or use
a class attribute for both
- Nest your div inside a container that applies the style to both the
alternative content and Flash content.

Jeff Coughlin

unread,
Dec 5, 2007, 9:20:24 AM12/5/07
to swfo...@googlegroups.com
Ahh, I see. I can live with that (I have tested it and it works now
by nesting an extra block element and placing the style on the parent
element).

Can you just verify that this new change is done by design and not a
bug? I just want to make sure before I start going and updating a lot
of sites that are currently using swfobect 1.5... and modify them to
use nested block elements <div><div></div></div> in order to display
the same data.

Regards,

---
Jeff Coughlin

Bobby

unread,
Dec 5, 2007, 5:56:01 PM12/5/07
to SWFObject
This was a design decision, and it departs from the replace methods
from both SWFObject 1.5 and UFO, which only replace the content inside
the id-ed HTML element.

Main reason is that the new way of replacing is more flexible. E.g.
with the new method you could assign different style rules to the HTML
element as the container of the alternative content and your Flash
content (or: your Flash content will not be locked up in styles that
should apply to alternative content only). On the other hand, when you
assign the same id to your Flash content as the id of your HTML
container (the first will replace the latter, so the id will say
unique), or by using the same class, you are also able to reuse style
rules when you want to.

Jeff Coughlin

unread,
Dec 5, 2007, 7:25:59 PM12/5/07
to swfo...@googlegroups.com
Thanks for the clarification, Bobby.

I noticed in the other thread (to which you referred back to this
thread) you mentioned placing the js within the <head>. My question:
If I did this on a site using xhtml strict (1.0 or 1.1), would it
still be semantically correct to use // <![CDATA[ ... // ]]> in the
<script> block if it's inside the <head>?

---
Jeff Coughlin

Bobby

unread,
Dec 6, 2007, 5:36:26 AM12/6/07
to SWFObject
It is syntactically correct, but a lot of times there is no need to
use it. If you look at necessity: most XHTML pages are served with
MIME type text/html instead with a real xml MIME type (e.g. to make
things work in IE), so it isn't needed to parse the page itself. When
validation is a project requirement or your personal preference, you
may choose to use this (you could also put your JS code in an external
file to achieve the same).
Reply all
Reply to author
Forward
0 new messages