I've been racking my brain trying to figure this one out as it's been a problem on the past few sites I've worked on (though they haven't gone live yet) and rather than trying to rig up a solution I'd like to try and discover the root of the problem.
Here's the site in question: (URL removed)
Basically I coded this homepage out as plain HTML and then inserted JavaScript and Flash elements as I completed them over time. When I got to adding the Flash (using SWF Object), I noticed that it had pushed the elements beneath it down roughly 5px, and only in Firefox and Safari (Internet Explorer, oddly enough, isn't affected). Turning off Flash or disabling JavaScript, which also turns the Flash off, removes this extra padding.
Can someone enlighten me as to what is causing this issue? I don't notice any major JS or CSS errors (other than a few hacks for IE), so I'm stumped.
Try to add line-height:0; to the div around the flash-swf:
<div id="flashDiv" style="line-height:0;">
This worked for me.
Try removing the whitespace between the DIVs on the page, and try putting the swf object into its own DIV. That way you can control what the page looks like without loading the swf, and it won't affect the other elements when it loads.
Try explicitly setting the margin and padding of the object element to 0px
You're using SWFObject 2.0, which does things slightly differently than the SWFObject of old. The old one would plant the embed INSIDE of a target div. The new one seems to actually replace the entire target DIV with an object tag.
Something I don't like, which is why I still use the old SWFObject.
SWFObject inserts an <object> element. Some browsers treat <object> as an inline element, some treat it as a block-level element.
The fix is to use CSS to ensure that objects are always treated as block-level elements:
object { display: block; }
See the SWFObject FAQ on the subject.
Related
I have a Raphael.js SVG element living inside a div. Occasionally—when the page loads, or when a jquery-ui-draggable is dragged over the main svg node—the whole SVG element (over?)flows almost below the page. That is, if it started at 0,0 and it's 500px high, it jumps to 0,500 all of a sudden, and not always. I've tried setting position:relative but that doesn't seem to fix it. Actually, tweaking the position: in the Chrome debugger makes it "come back", but keeping it there through a page load doesn't fix the issue permanently. It happens maybe half of all page loads.
Anyone know what might be causing this, or at least a way to keep it jammed at the top? I'm rather CSS-ignorant.
Apologies for not having an example; it's part of a large setup that I can't share at the moment. I'm hoping someone has a hunch.
Can you examine the generated source code while it's happening (I use the Web Developer tool and there's an option in there to view the generated source code — and am sure there0s something similar in Chrome) to see if there isn't an element being inserted before it (or that something in your program logic is causing the canvas to be duplicated). I once had some very strange behaviour with Raphael and found that it was linked to my inadvertently loading the same script twice on the page.
I could always suggest absolute positioning too in CSS but that doesn't sound like it would fix the underlying problem.
Good luck and a hope that helps.
Apparently it was some CSS transforms: the input paths weren't in the right coordinate space, so we were doing a -webkit-transform: translateY(400px) scaleY(-1); in the <svg> element. I'm gonna try scaling the paths before putting them in the DOM instead.
I've got a fairly simple design that I'm working on in ASP.NET.
The problem is when I take the design from flat HTML which works fine, to asp.net, it adds what looks to be a 20px blank margin at the top of the page and around certain elements.
I presumed this was to do with the not having set my margins to 0px on the body and form elements in the CSS. I've done this, and it still has the problem in Chrome and Firefox, but not in IE7 or IE8.
Any ideas?
I've seen some unwanted margins on ASP.NET pages and they had something to do with invalid markup (might have been because of a missing div end tag or something similar - I can't remember the exact reason). So check your markup. Also make sure that you are using a valid doctype (i.e. not in quirks rendering mode).
Firebug is often a great help in this kind of situations. You can inspect exactly which element is causing the extra margins. Chrome has a similar "Inspect element" functionality built in.
I have an issue with Google Chrome: 19.0.1084.52 m when I have the Ask Toolbar installed
it breaks the website layout.
See print screen:
Is it usual behaviour that toolbars in Chrome would effect the website?
EDIT: I guess I should wrap everything inside a <div> and move the background-image from the <body> although is there a better option without adding this extra markup?
Website link
A Javascript snippet can disable ask toolbar in chrome. I hope this function spreads quickly!!
function removeAsk(){
if(document.getElementById("apn-null-toolbar") != null){
// mainMenu had a style change for its top positioning, returning it to normal
// perhaps a function can be made which iterates over every element ask has changed
document.getElementById("mainMenu").style.top = "-16px";
// Just remove the iframe and style elements
(elem=document.getElementById("apn-null-toolbar")).parentNode.removeChild(elem);
(elem=document.getElementById("apn-body-style")).parentNode.removeChild(elem);
}
}
Call this method after body onload
<body onload="removeAsk()">
There is no Chrome extensions API for creating a toolbar so mentioned extension must have created it via content script. What it means is that for each page you open, CSS and JavaScript files are injected by this extension to create a DOM element within the page acting as a toolbar. Problem with this solution is that using the content script it is possible to mess up website look or even the way it works.
I ran into this exact same issue with the Ask Toolbar. I basically took out my positioning attributes and top/left/right/bottom 's and replaced with margins. Margin uses less space and it comes out cleaner.
Although i do agree, it's kind of ridiculous to accommodate for a toolbar because the end-user could have anything installed that breaks and gives your layout bugs. Even Skype extensions will break a layout just changing the phone number.
So there's not much you can do, but use margins and keep CSS to a minimum. Just my 2 cents. and if you have to use CSS then stick with margins.
I have a web page that includes an iframe as well a DHTML calendar widget. The page displays correctly as well as the content inside the iframe. The problem is when I activate the calendar which is positioned close enough to the iframe that some of the calendar is hidden by the iframe.
I have tried to manipulate the positioning of the iframe by using both javascript and CSS (Zindex, z-index) but the iframe always appears as the top most layer on the page obscurring any parent DHTML content that gets rendered in the same area as the iframe. I also changed the css of the DHTML calendar to values > 0 and wrapped the widget scriplet in a div/span with a high z-index value but no luck.
The z-index of an iframe is handled in a weird way by IE. If you can get rid of it, I'd recommend you do and just embeded the content in a regular Div.
If you don't have other choices than do it like this, keep in mind that the z-index of elements like and will be infinite in IE6. So the way to stack that is to use iframes with higher zindexes, so that it will be infinity vs infinity+1.
An example of this is vs stacking. Both have infinite z-index, but you can stack them. Checkout Stu Nicholls code, that could be helpful.
That's pretty bad thought, my fix would be to avoid having other fields in this area.
Google for "IE z-index bug" for a variety of examples and solutions to similar problems. The html specification states that z-index should be absolute, but in IE it can be determined for an element if a parent element is positioned. In extreme circumstances, I've had to trace back up the DOM tree from the element that's causing problems and set the z-index attribute on whatever parent element has position, not on the element that is being obscured (and should rightfully have its z-index set). IE Developer toolbar can help for dynamic debugging if it's really a mess, just start setting the z-index properties up the tree until you find the one that makes it looks right.
You can definitely cover the iFrame with a div.
The thing is you can't use z-index unless you use position:relative, or position:absolute, or position: fixed on the calandar div.
What you want to do is change the "position" CSS property of the calandar to be "relative". If your iFrame has the normal static positioning (meaning you didn't add any special positioning to it, this will work).
If your iFrame has "absolute" positioning, you might need to do "position:absolute" on the calandar.
See link: http://resopollution.com/test/test.html
(works in all modern browsers including IE6)
I just realized that the problem seems to be related to the MSXML and how IE transforms XML documents. The XML has an XSLT stylesheet association which the browser uses to transform the XML document. The output of the transformation is an HTML document. I didn't think it was import to disclose that I my HTTP response was XML since the HTML is what is rendered in the end, but it does matter.
When the source of the IFRAME is an HTML document everything works fine. The DHTML is not covered by the IFRAME. But when MSXML is used to transform the IFRAME content this is when the problem occurs. Below are some sample files that illustrate the problem.
For the DHTML compoenent I am using the spiffycalendar widget but I would imagine any DHTML element would produce the same results.
PARENT.HTML
IFRAME DHTML CONFLICT EXAMPLE
var pickupdate=new ctlSpiffyCalendarBox("pickupdate", "mainF", "PICKUP_DATE","btnDate1","",1);
</script>
PARENT WINDOW
FIELD
FIELD
FIELDpickupdate.writeControl();
FIELD
FIELD
FIELD
Save Changes
IFRAME.HTML
IFRAME.XSL
]>
TEST XML DOC
IFRAME CONTENT
Working on a rather small, and simple layout, I decided to use Meyer's CSS Reset rules to clear some of the expected discrepancies between browsers. All was working fairly well until I decided to add a few paragraphs into a couple nested divs.
Once I placed the paragraph-tags within the second nested div, the background images of both the parent, and the grant parent divs vanished in IE7.
Removing the paragraph tags (and going with untagged-text) returns the background images. Additionally, leaving the tags and removing reference to the reset.css file restores the background images.
Obviously I don't want to go with either of those routes to solve this issue. Any CSS gurus here know what is taking place?
Demo: http://www.sampsonresume.com/projects/patriot-depot/
It looks like a version of the disappearing content bug in IE.
Add zoom:1 to div.pd_horiz_content and div.pd_horiz_content_b. That will invoke 'hasLayout' in IE and your background will show up.
You can also invoke hasLayout by adding a dimension (width:960px) to the divs. This would probably make more sense in your case since your divs have a fixed width based on the background images.
Oddly enough, when I remove the following rule from the reset.css file, the issue is resolved:
background:transparent
This rule is applied to the first large block of matched elements, so I'm not sure the implications it will have in the long run. Hopefully there's a better solution, as I'm a little uneasy about editing Meyers' reset.css in order to "fix" my problem.