In the chrome dev tools bar I see these details at responsive.css:1101
But when I go to line 1101 of responsive.css I don't find margin-right of -20px:
So what is causing -20px right margin?
I've searched in whole of responsive.css but I could not find the rule causing -20px right margin.
Under styles tab
Under Computed Tab Same Time
The browser is calculating that value automatically. From MDN:
auto is replaced by some suitable value, e.g. it can be used for centering of blocks.
div { width:50%; margin:0 auto; }
centers the div container horizontally.
The -20px that you are seeing is on the "Computed" tab of the developer's tools. This tab shows the actual amounts that have been calculated based on the all the style rules that apply for a given element.
So, if you have a style rule that says something like width:50%, then at some point, the browser needs to figure out exactly how big that is. This is what the "Computed" style tab shows you. You will not necessarily see these values in the source .css files.
Instead, look at the "Styles" tab of the developer tools and locate the item in question. In that tab, you'll be able to see the style rules that apply to that element and if there is more than one, you'll see them all, but some may have a line running through them, which indicates that they are being overridden by a more specific rule somewhere else.
Now, in your case, you are setting the content to 960px; and the margins to auto. The developer's tools is only telling you that the margin is what it is because of the value specified at line 1101. But since you've used auto there could be a number of other styles contributing to the final result and the size of the viewport when you test factors in as well.
Related
Is there a way to find out the actual value the browser uses when the CSS value is set to "auto" or similar? I'm looking at the computed CSS values for an element in the inspector but it stills says "auto" and I would like to determine the exact value.
UPDATE: Looks like most properties automatically compute, but some don't. Here are examples of properties that still show up as "auto" when you look in the computed panel:
top
bottom
left
right
Not sure why.
If anyone was wondering, the reason I was even trying to figure this out is because I'm currently maintaining a website using an older version of Bootstrap (v2.1.1), which sets top for .modal.fade.in to "auto" when in a browser with a width < 768px. Which, for my browser at least, results in the modal vanishing from view. So naturally I wondered where the modal had gotten to and wished I could see the actual value Chrome set top to.
Looks like one of the changes in (v2.2.x) was changing top: auto to top: 20px which would probably fix the issue.
In chrome you have tab computed. You see those values there.
Computed tab
http://jsbin.com/yefofe/edit?html,css,js,output
The HTML below specifies a button and a div that have identical class and contents.
<div class="root"><!--
--><button class="outer"><div class="middle"><div class="inner">label</div></div></button><!--
--><div class="outer"><div class="middle"><div class="inner">label</div></div></div ><!--
--></div>
In this example, I have explicitly set every CSS property1 for the classes outer, middle, and inner2.
This means that both the button.outer and div.outer sub-trees of the DOM should have completely identical CSS settings. Presumably, as well, no CSS properties for these elements are getting their values from anywhere else besides the provided stylesheet.
As the example shows, the side-by-side button and div look quite different. Specifically, in the button, the label appears at the bottom of the element, whereas in the div it is vertically centered. (The label is centered horizontally in both cases. Also, note that all the classes have the setting vertical-align: middle.)
I have observed this difference with all the browsers I've tested so far (Chrome and Firefox).
Since there is no difference in the stylesheet settings for the button.outer and div.outer elements, and their descendants, I figure that the difference in their appearance is due to some CSS property with a value (such as auto or normal) that gets interpreted differently by the browser depending on the whether the context is a button or a div element.
My immediate goal here is to understand sufficiently well why the button and the div are being rendered differently so that I can adjust the CSS intelligently.
My longer term goal is to make CSS coding more predictable. Currently I find that my CSS is completely unstable due to gross inconsistencies like the one shown in the example.
My question is:
how can the difference in appearance between the button and the div be explained?
1 As reported by Chrome's devtool.
2 I took the vast majority of the values for these settings from Chrome's devtool's listings. The point was to ensure that both the button and the div elements had the same setting (whatever it may be) for each CSS property.
This is likely due to different meanings for the value of auto for the position of elements inside of a button. If you expand the size of a div, the content by default will be in the top-left corner. If you do the same for a button, the content will be centered horizontally and vertically.
Since the button's top and left values for auto is to be centered and not in the top left corner, you can reset top and left to always act like a typical div would. These are the properties to change on .middle:
.middle {
top: 0;
left: 0;
}
Here's the forked JSFiddle with those changes to .middle.
Different elements have different default settings. There is an enormous amount of CSS in your demos, and it's largely overkill and very hard to determine where exactly the differences in rendering are coming from.
Have you tried a CSS reset instead? These will resolve most of the discrepancies between elements and browsers, giving you a blank slate to add your own styles.
how can I determine the property (or properties) that account for the difference in appearance between the button and the div?
By clicking through them one by one and toggling them on and off in Dev Tools. If you turn off position:absolute on the middle class, you'll see what you're probably expecting in layout. I found this by clicking through all the properties in the Elements > Styles panel. See:
https://jsfiddle.net/vfdd9p8L/
This is probably a bug that you're encountering. Browsers have lots of them! By layering on so many styles at once, you're probably backing into a weird corner case with respect to the layout algorithms. To isolate the bug for help and/or reporting, try to create a reduced test case, which creates an unexpected discrepancy, but using the minimal number of elements and declarations.
(Also note that your fiddle is including jQuery CSS, which includes Normalize, which is a whole other layer of styling.)
I'll temporarily open this live URL, otherwise this problem will be too hard to explain:
[test URL closed]
Please open this in a browser that supports media queries and resize the browser to mobile, at around 400px of viewport width or lower:
As you can (should) see, the "Tags" option in the global navigation menu is visible, active and aligned to the right. This works correctly and is accomplished by floating it to the right:
.nav-option-active { #include inline-block; float:right; }
(note: I'm using SASS, hence the #include syntax)
So far, so good. However, as the viewport grows, more room becomes available to show the navigation options, both this active one and additional ones, as they normally should appear. With room available, they should not float. You can see how this work for the other navigation options when you resize the viewport into something larger:
See above. The global navigation options appear unfloated, as they should, however the active navigation option (which in this case is the tags link) remains floated to the right. All I want to do in larger viewports is to undo that float, so that the link will behave as an inline-block, unfloated, and appear as in the markup just like the other links. My attempt to do so is as follow:
.nav-option-active, .nav-option-active a, .nav-option-active a em { float:none; }
Note that the code is kind of desperate, it really should be a matter of setting float:none on only the .nav-option-active element.
As you can already see from the screenshot, the float is not undone, and I can't figure out why. In Firebug I see that float:none is indeed applied, and that float:right is striked through, overruled by float:none. So the CSS is definitely applied, but it has no effect. Clear:both has not effect either, although I think that isn't the right property to use. Strangely, if in Firebug I actually get rid of the float rules during runtime, the desired behavior is achieved.
I have a feeling that I'm overlooking something very basic or misunderstanding something fundamental, so how can I undo a float once set?
Your other list items are floated left. You'll need to float that one left, too.
I'm using section to determine different parts of my page. These sections have a bottom margin of 90px but when a section with the ID of 'clients-full' is created/put in the page, I want whatever section that appears before/above it to have a bottom margin of 0. Can I do this using CSS selectors/pseudo selectors?
Currently, this bit of code styles the section with the ID of 'clients-full' but can it be reversed so I can apply a bottom margin of 0 to the section that is before it?
section + section#clients-full {
margin-top: -90px; // Negative margin to get around this problem...not ideal.
}
In CSS as currently defined an implemented, selectors cannot be used in a manner that selects an element depending on what comes after it, only on what comes before it. Well, selectors linke :nth-last-child(...) are an exception in a sense, but they don’t help in a case like this.
Thus, a better approach is to separate the sections by setting a top margin on them, dealing with the first section as a special case if needed (no top margin on it) and perhaps the last section, using :last-ot-type (setting bottom margin on it if needed). Then you can easily handle the case described, simply with #clients-full { margin-top: 0; }.
I have an editable iframe and I want to insert two DIVs at the [b]top [/b]and [b]bottom [/b]part(as header/footer) of iframe body respectively. Now, the question is : how to insert a div [b]at the top of iframe body[/b] and fix it there? (Will insertFirst() work?)
Also, how to fix the footer div always [b]at the bottom of the iframe body[/b]? I tried make its position absolute and gave a margin top/bottom, but the problem comes when the body height of the iframe increases and footer DIV position does not change.
I want the same thing google docs does, i.e. fixing separate part for header/footer (though google docs page is not an iframe).
Any work around?
I assume by "fixed" you don't mean position: fixed but "not editable"?
I don't know of a native way to do that, the only thing I do know is CKEditor's protectedSource configuration setting. It allows to specify regular expressions; content matching those expressions cannot be removed by the user.
If you mean "fixed" as in "position", the position: fixed CSS property should work for you (Doesn't work in IE6 though).