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.
Related
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.)
In the past days I switched my menu to mobile friendly version. Is nearly done so far, only one issue remains: In the desktop version I've positioned the submenus absolutely so that they cover what is below when made visible. However, in the mobile version I would like to have them in regular textflow, so that what is below slides down when I make them visible. I'm using mediaqueries and have tried to set the position attribute to "static" but this didn't work:
#Navigation li ul {
position: static;
display: none;
}
My test page: http://ulrichbangert.de/indexr3.php (Resize the viewport to a small width until the menu has one column.) I've used this tutorial: http://www.menucool.com/ddmenu/create-mobile-friendly-responsive-menu.aspx where it works just as I want it to. However I cannot use this one-by-one as I wanted to keep the layout of my existing menu. Best regards - Ulrich
In the meantime I was able to solve this problem on my own: Apparently some CSS attributes cannot be changed when they are in a nested list and not on top level. In this case the attribute position. Afterwards I had the same problem with the attribute width which I could not change to 100% and the attribute padding-left which I could not change either. And some years ago when I implemented the initial version of this menu with the attribute height, which I could not change to auto on hover after setting it to 0 initially. Only setting to a fixed height worked.
How can this be? Is it intended or is it a bug in the browsers implementation? (I tested with firefox).
Anyway my menu works fine now, just as I figured it.
I was just checking out 906.gs css code and noticed that they made all the floated divs inline.
http://960.gs/demo.html
Just wondering what the purpose of that is...I am always interested in learning CSS theories.
An element with float: left is forced to have a computed display value of block.
For more information on that, see: jQuery in Chrome returns "block" instead of "inline"
The purpose of also adding display: inline is to fix an IE6 bug, the "double margin bug":
http://www.positioniseverything.net/explorer/doubled-margin.html
A coder innocently places a left float
into a container box, and uses a left
margin on the float to push it away
from the left side of the container.
Seems pretty simple, right? Well it is
until it's viewed in IE6. In that
browser the left float margin has
mysteriously been doubled in length!
It's a free fix with no downsides (even in IE6):
That means that {display: inline;} on
a float should be no different than
using {display: block;} (or no display
value at all), and indeed all browsers
follow this specification, including
IE. But, this does somehow trigger IE
to stop doubling the float's margin.
Thus, this fix can be applied
straight, without any fussy hiding
methods.
In fact, you could just apply the
Inline Fix to all floats if you like,
since there are no known side-effects.
That way the bug can never gain
traction regardless of any margins you
might or might not use.
i'm having a very strange problem with the wordpress template.
i'd like to place 2 divs besides each other like this:
<div style='float:left;'>
left div
</div>
<div style='float:right'>
right div
</div>
normally this works as it should - both divs should stick directly to each other -
but something in the style.css (which uses css reset) causes the right div to overlap the left div with ~ 5pixels.
i searched the whole .css for it but couldn't find out :((
it's just a fact that it must be something with the default css.
anyone knows what is causing this - some fix?
thanks
Do either of your divs have widths? Give them a width, float BOTH left and add margin-right to the first div.
Make sure your width + margin doesn't add up to more than the surrounding div. For example if your surrounding div is 600px your boxes shouldn't be more than width:290px; a margin-left:20px; on the left div.
Also, you can use Firebug or any other web development broswer tool to check to see what styles in your stylesheet/s are affecting your divs.
Float both left or use inline-block. You can also just float the first one left.
I would highly recommend that you (if you don't already have it) download FireFox and install the Web Developer Toolbar plugin. This plugin is GREAT for tracking down problems like this. Under the CSS portion of this toolbar when you're viewing the page with the issue you can select to "View Style Information". Then just click on the divs that are the issue on the page. Off to the left you should see a little window pop up that shows all the styling that is affecting those divs and what css source they are coming from. With CSS if you rely on "bug" fixes to fix things that aren't really bugs then you'll just cause more headache later on in most cases.
I think the problem is probably with parts further on in your code. May I suggest clearing the floats:
Html:
<div class="clear"></div>
CSS:
.clear {
clear: both;
}
The code you have posted would work fine, but I expect you have more divs or containers or something somewhere which is messing it up.
Total width = margin_width + border_width + padding_width+ width of the box + (the same for the other box).
Make sure you have width defined for both floating device. The best way is to debug the code by hitting F12. You can do it FireFox, IE,Chrome or Safari but usually you have to enable this option yourself.
I am seeking some advice regarding unnecessary scrollbars appearing on certain form items. A screenshot of the issue appears below. Note it is the right-most scrollbar that is unnecessary.
bad_scrollbars http://img21.imageshack.us/img21/9307/scrollfu.png
The culprit appears to be the following css, adding overflow: auto; to form items within windows in gecko-based browsers (the problem appears on Firefox):
.ext-gecko .x-window-body .x-form-item {
outline: medium none;
overflow: auto;
}
Removing this style solves the problem, but I am wary of possible side effects - though I haven't noticed any as yet, this style was obviously included for a reason.
Does anyone who knows more about Ext styling know if overriding this css to remove the overflow: auto; style will cause other problems?
As an aside, this is only an issue (so far) with a certain component - a custom extension of the Ext.ux.form.MultiSelect component - even though other components use more vertical space. Does anyone know of a possible reason for this?
Thanks for any help.
overflow: auto tells the browser to add a scrollbar to the element if the content of the element is larger than the elements client area minus any padding. Getting rid of the scrollbars in CSS does exactly that. It makes the scrollbars go away, no matter what.
The side effect of your work around is if there is content outside of the client, the use will not be able to see it. Additionally, this will not only happen with this form but every form in your application unless you apply your workaround in a custom class.
The right fix is to figure out why your content area is larger than the form's client area. Firebug can be a big help with this as you can inspect the DOM and see the size of the container as well as the size of all the child items.
I suspect that your clear selections control (is this a custom control?) is not properly sizing itself (i.e in your form layout you're telling it to be x pixels high but it's actually sizing itself x+1 (remember margins and padding). The form layout is doing all the work to decide how big to make the wrapper area (the area with the scroll bar) and the control must fit within that area.