I am messing with a wordpress theme. I am using firefox and have webdeveloper (and other tools) installed. I am trying to adjust a div width but it is not listening to me. I suspect theres a % used since when i tried setting a max-width to a parent it became MUCH shorter (then the size i specified). The style file is 3k... I tried narrowing it down but its troublesome.
What tools and technique can i use to spot the problem?
Use firebug and inspect the element to see all affecting attributes.
Related
I am working on a wordpress project. The issue is though the container where the content area and sidebar along with the top logo positions seems perfect in chrome with 30px margin-top.
But in firefox the margin seems to go down more, though the margin value is same. Any recommendation for FF compatibility with css would be great...
Hard to see without code, but you may have some problems with the two browsers' base CSS styles being different. You could try using a thing like normalize.css as a way of normalising these styles before your own stylesheet.
You could also use the web inspector/Firebug in firefox to see what surrounding elements have an effect on the positioning.
I have created a page that has similar functionality to that of the DiggBar (i.e. a header of specified height and an iframe below filling the rest of the page).
I had this working a while back with desired results, but all of a sudden the height of the iframe has gone from 100% of the remaining page height to only 44.8px. The catch is that this is only occurring in one browser — Firefox on Ubuntu.
I thought that this should be happening in all other browsers, but it's not. It displays correctly in IE, FF, & Chrome on Windows and Chrome on Ubuntu.
Finally, using Firebug, I have selected inspect element to try to determine what's going on, but it only tells me that my height is defined to be 100%, but that it is computed to be only 44.8px.
I am looking for some guidance as to how best to debug this issue because I have completely run out of ideas. I didn't think that it would be necessary to post all of the code that produces this problem, but if any is absolutely needed, just ask.
Thanks.
Unfortunately the Cascading part of the Cascading Style Sheets threw me off. I had another (let's call it 'hidden') reference to the parent of the iframe which caused the weird height calculation issue.
Funny that this only happened in my Ubuntu version of Firefox, though.
If you have a complicated layout structure, setting height of all divs to 100% may break the page layout. In this case I recommend using javascript to set the height of iframe to 100%. In my case I used JQuery, but I believe pure javascript DOM functions should also work. I set the height of iframe equal to parent div height:
$('#doc-preview iframe').height($('#doc-preview').height());
Here the doc-preview is an id of iframe's parent div.
Make sure to run this script after the page has been loaded.
I've created a custom widget, which uses a bunch of floated divisions, I'm having a issue with internet explorer though. After playing around a bit, I found that the problem was with setting inline css.
I have a class extending ComplexPanel, which sets the element to a division, and offers a bunch of helper functions to set various inline CSS.
If I add say, 3 divisions using this DIV wrapper class, which all are being floated left, and set to 100px using inline css (set with getElement().getStyle().setProperty()), then they act odd in IE8. (it works fine in IE9).
Basically, none of the inline CSS is being picked up. Using the developer tools shows the CSS is there, but its not being applied. If I disable the float (or width for that matter) and enable it again, using the developer tools, the inline CSS is picked up and it works as intended.
So, how can I inform IE8 that it needs to re-interpret inline CSS on dynamically generated elements?
We had problems using setProperty()... in ie8. So, avoid it.
Try using one of predefined methods in Style.
Try using getElement().getStyle().setFloat(Float.Left).
and getElement().getStyle().setWidth(100, Unit.PX).
I have a Blogger template which is wider than the screen-width and causes the horizontal scrollbar to be displayed. I want to change it so that it fits and no scrollbar is shown. But the problem is I don't know what is causing this. I have downloaded the template file and in my code editor looked for all width properties and changed all 100%s to 90% and pix width values to value-100, but still the page is as before.
In finding the effective rule/rules in a such cases, what else should I look for/do? What is a comprehensive procedure to check things to find the rules?
Instead of changing the width, try adding the CSS property overflow: hidden to everything you think might be causing the issue and then remove them one-by-one until the scroll bar reappears and you'll have the culprit. You might need to add it to html and body as well. If the scrollbars aren't revealing any actual content, you can leave the overflow: hidden on the culprit to resolve the issue.
It might not be a width property that's causing the problem - there might be a block element inside your template that doesn't wrap or float that might be stretching out your container if the widths of the containers are defined using percentages.
Define the root container using a fixed width and this should eliminate many of those sorts of issues. Try that first and let us know if it works.
Procedure:
1). Understand the box model and how this varies on IE. It is just as likely that a problem "width" may actually be caused by padding, margin, or even border as width.
2). Check the rendering in other browsers. If you can reproduce the problem in FF get Firebug and use that to find out the calculated dimensions of the element in question, and tunnel down through it's children which may well be causing the issue. Chrome has a similar debugger to Firebug iirc, but I'm not familiar with it.
3). If that doesn't tell you what the problem is, start removing rules or whole patterns from your CSS until the problem goes away (or remove everything and add it back in piecemeal until the problem returns) - at that point you know what is causing the issue, if not why, and you can always update the question to ask us why when you've identified it.
hth
(Apols if any of this was already obvious)
Well, % always begins with "100". See the percentage of width of body tag is set to 100%. then according to it, just set other component % as per the requirement in your display.
Personally I do believe that, use of % is better then 'px'. If you know CSS, then try to change 'px' to % as per the requirement.
It seems that the component has min-width style and overflow property set to auto. You may want to set it to visible and do it in FireBug Firefox Page Inspector first, to see the effect alive before making post edit. If you just want to adjust the whole post width, blogger has standard interface. You can also edit the template manually
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.