I've encountered some bizarre CSS behavior. However, it works exactly the same across Firefox, Chrome and IE (9) so I suspect it is a part of the CSS standard, however, I cannot find any reference to why it might be the case.
I have a div with some text in it. When I set the font-size larger than the line height, the height of the div is calculated using the line-height, but the content is much larger. That is, the text in the box is much larger than the box itself. I have a jsfiddle with the situation here:
http://jsfiddle.net/RVgzV/4/
If you move the mouse to above the bounding box, you can see the hover css activates before you enter the div. Similarly, clicking close to, but still outside of the box activates the javascript click event. It's slightly easier to see where the content box is here:
http://jsfiddle.net/RVgzV/5/
The height is correctly calculated when the display property on the div is set to inline (which I can't do for various styling reasons). Also, the issue is solved if I set the overflow property to hidden. To me this indicates that the content is larger than its containing box, but I am not sure why. In particular I want to know why the "height" css box model property of the object is smaller than its actual height as displayed on the page.
I've had a look through the CSS spec, and I didn't see my answer there, but I suspect there may be something there I am missing.
Edit
I've found the following link which makes some reference to the problem I am having, but I have no idea what their source is, or why it might be the case.
Also, in response to some answers I have received, I am not looking for how to fix my css so the hover issue doesn't appear anymore, I am looking for why it's happening in the first place.
Edit Again
Apparently, any content of the box, no matter whether inside the box's boundaries or not invokes hover on the box. (See Mr. Lister's comment on This answer. What I'd really like to know is where in the specification this behavior comes from. Is it in there? Or is it an implementation that all browsers have agreed on?
Use overflow:hidden to hide anything outside of the div.
Its acting correctly as children can exist & be hoverable outside of the block area of an element.
This technique is used frequently to move inner pieces of block elements by using negative-margin/padding/absolute positioning etc. yet those pieces will always maintain the hover-ability of the parent.
The div is not incorrectly sized. It is the normal behavior.
You have used CSS incorrectly. The div-height is defined by the number of lines in it. You have given a bigger font-size than line-height, that means it can be only taken the max-line-height to define the number of needed lines.
By the way, what sense makes it to define the font-seize larger than the line-height?
Related
Code sandbox: Code sandbox
I have a column of Icon like this:
I css it with overflow-x:auto so that It can scroll the icon outside the container.
But when It bounced out. The overflow-y: visible didn't work for me so the Icon is still inside the box.
I tried using oveflow-y but didn't work for me. I coded a code sandbox so that you guys can have a look. Thanks for all of your help! Have a nice day!
For overflow-y to work, the height of the content in the element needs to exceed the specified height.
I just removed the height of container and slightly increased the padding of AppBar to make it work. Yes, you have to little workaround to meet the height of the container actual to the design.
Another solution, for now, I can suggest is to play with z-index property of the elements.
SanBox
from mozilla : "Setting one axis to visible (the default) while setting the other to a different value results in visible behaving as auto."
source : https://developer.mozilla.org/en-US/docs/Web/CSS/overflow...
You could avoid this side effect either by controlling the scroll another way (css and javascript driven scrollbar) (this would by the way avoid the different scrollbars on some browser which can be a little ugly (ie under edge), either by setting the container bigger, and setting a nested element for the background.
I am using bx Slider, using external controls for previous and next slide.
All is working fine. However, I am using floating elements for the controls, since I want them in a line and filling the whole containing div (as in this question CSS three inline elements with align from left to right, how to occupy all available width )
However, the controls are generated dynamically by bxSlider, and for some strange reason, if the elements are floating hover is not recognized
Here is an example page: http://demitogroup.comuv.com/d_store/copia.html
If I turn the float off with firebug to #external_promo_controls div hover is recognized again.
If the links are not generated dynamically the problem does not show up.
On Chrome the same happens.
I have totally no idea about what is happening.
Could try to figure out something avoiding to use float elements, but then I will be back again to my first question...
If you expect your floated element to fill the whole space, try setting it to display:block explicitly, if it is not already. If that doesn't work, try setting a large z-index on it to guarantee nothing hidden is getting above it.
I have found an issue when using absolutely positioned content within a td element. The td element is not being recognised as a positioned element so the content is being positioned relative to the body. This issue is only in FireFox and the expected layout is visible in other browsers - jsfiddle.
Doing a little digging around it seems that the issue is related to FireFox using display:table-cell as the default display type for table cells. I can resolve the issue by changing the display to block or by adding a div container to act as a positioned container to the content.
Is there any reason to avoid changing the display type of the cell to block? I would prefer to use this method rather than adding additional elements to correct an issue in one browser.
This is not the same issue as described in either div style absolute in a table cell or Why "display: table-cell" is broken when "position: absolute".
If you set the display of the cell to block it will get wrapped in an anonymous table cell. The resulting CSS box tree is the same as if you created a <div> inside the cell and set all the cell's styles and attributes on that block.
This might be OK for many purposes. It'll break if the cell has a rowspan or colspan (because those don't mean anything on blocks) or if the cell has border styles that you expect to take part in border collapsing or if you have two such cells next to each other (because then the two blocks will be wrapped in a single table cell, not in two separate table cells). There are probably other situations where the behavior will be unexpected. But if you have enough control over the styles and content and aren't doing too much styling of the cell, this will work.
Did you try to set the position of the TD explicitly to relative?
This should reset the positioning. Actually, it is correct behavior what you are getting, and should not be only related to TD, but you know, browsers are fun.
For details on why you need to explicitly set it, check:
http://css-tricks.com/791-absolute-positioning-inside-relative-positioning/
..
Update:
This answer suggested trying an option. It's written earlier than accepted answer, and is not deleted just for archival reasons and as it is another related possibility for those coming here from search engines for slightly similar but not same problem. I appreciate your understanding.
I was very surprised when I found that a <div> with a size of - say - 200px becomes 220px wide if you give it 10px padding. It just makes no sense to me, the external size should not change when an internal setting does. It forces you to adjust the size every time you tweak the padding.
Am I doing something wrong, or is there a reason for this behavior?
EDIT: I know this is how it's supposed to work, my question is why? Is it logical in a way I don't understand? Does this give any advantage over the opposite approach of keeping size and padding separate?
There are two different so-called "box models", one adds the padding (and border) to the specified width, while the other does not. With the advent of CSS3, you can luckily switch between the two models. More precisely, the behaviour you are looking for can be achieved by specifying
box-sizing: border-box;
ms-box-sizing: border-box;
webkit-box-sizing: border-box;
moz-box-sizing: border-box;
width: 200px;
in your div's CSS. Then, in modern browsers, the div will always stay 200 px wide no matter what. For further details and a list of supported browsers, see this guide.
Edit: WRT your edit as to why the traditional box model is as it is, Wikipedia actually offers some insight:
Before HTML 4 and CSS, very few HTML elements supported both border and padding, so the definition of the width and height of an element was not very contentious. However, it varied depending on the element. The HTML width attribute of a table defined the width of the table including its border. On the other hand, the HTML width attribute of an image defined the width of the image itself (inside any border). The only element to support padding in those early days was the table cell. Width for the cell was defined as "the suggested width for a cell content in pixels excluding the cell padding."
CSS introduced margin, border and padding for many more elements. It adopted a definition width in relation to content, border, margin and padding similar to that for a table cell. This has since become known as the W3C box model.
The reason why it's like that is that technically the width of elements is supposed to apply to the content, not the container.
According to the CSS1 specification, released by the World Wide Web Consortium (W3C) in 1996 and revised in 1999, when a width or height is explicitly specified for any block-level element, it should determine only the width or height of the visible element, with the padding, borders, and margins applied afterward.
More info about this behavior*
* Disclaimer: Yes, this is my own blog and I think I did a thorough job of explaining the box model so I'm putting it as reference.
Padding is supposed to be in addition to the given width of an object.
See the CSS 2.1 specification for box model.
While it is true that you can view padding as either an internal or an external attribute, the fact of the matter is that according to the current specifications it is an external attribute. It was a choice between two, as far as I can tell, equally valid options.
I haven't read up on the box-model attribute, but assuming that alex is right, then in the future you will be able to choose between the two ways of interpreting padding.
If the size increases with padding, it's working as intended. In browsers with broken box models like older Internet Explorer versions, the div will be 100 pixels wide, but that's incorrect handling of the CSS.
http://www.w3schools.com/css/css_boxmodel.asp
If the box model did not work this way, how would you deal with padding around an image? Would you prefer that the size of an img element with padding not match the image's pixel dimensions? Or that the padding covers the image?
It's better that the default behaviour is that the width of the container is not affected by padding or margin values.
If your box is within a box, remove the inner box's width (the one with the padding) and it will fix the problem.
""If the box model did not work this way, how would you deal with padding around an image? Would you prefer that the size of an img element with padding not match the image's pixel dimensions? Or that the padding covers the image?""
First of all, any good web developer would know better than to put an image into a container where it doesn't fit. That is developing 101. If the padding doesn't allow for the image, the image or the padding should be changed. Pure and simple. So the argument mentioned above is faulty.
Padding is an internal setting, internal to the boundries of the container. So when something is inside that container, and you increase the container's padding, the item(s) inside that container should coded so the can be reduced in size.
The word "padding" itself says it all. Can you imagine if UPS added padding to thier boxes to protect the contents inside, only to find that the box increases in size! Rediculous, right? Of course it is! Padding is meant to add space around the inside of a container WITHOUT the container breaking and expanding in height or width.
It's browsers like mozilla, gecko, and opera that have broken box models, not IE. The box model that the "consordium" implements is faulty at best and reaks havoc on web develpers.
If the "consordium" implemented the same box model as IE, than we developers would have a much easier time with the columns of our webpages. I think you have to agree with me on that point. Plain and simple.
I am so tired of people saying that IE is inferior. I can give tons of examples where IE holds strong while the cheaper browsers like firefox break under the pressure.
My two cents. Hate me if you want, but what I speak is common sense and nothing else.
I'm working on an application with a map and there is a div in the corner with some stuff in it. You can click on this map to bring up some information in a little window. The window is, in some cases, being covered by the div in the corner.
I want the opposite effect (window covers div). I figured this would simply be a z-index issue but I'm unable to get it to work. This is with IE7 and from reading up a bit it seems like z-index won't work unless it's inside of an element that is positioned.
The elements seem to be positioned properly to get the z-index to work right but I'm having little luck. I've played around with adding styling via Firebug but haven't had any luck in getting anything to change. The window really is just two divs one absolutely positioned one and a relative one inside of it.
Is the z-index the only thing that could be the problem here or is there something else I don't know about?
Are there any other methods to achieve the effect I want? I cannot simply hide the div via jquery or something because part of it should be visible from behind the window that opens on the map.
You are hitting the stacking context bug
http://therealcrisp.xs4all.nl/meuk/IE-zindexbug.html
Every positioned div in IE will create a new stacking context and prevent z-index from diferent stacking contexts to come on top of others.
The solution is to have the window you want on top up in the tree (into the body for example) and z-index value grater than z-index of all parents of the other div covering your window.
Extensive information to understand the problem here:
http://richa.avasthi.name/blogs/tepumpkin/2008/01/11/ie7-lessons-learned/
positioning and negative margins is the only way to get elements to overlap that i know of. z-index is just used to explicitly tell the browser how to layer the elements.
as to your problem, IE requires the container elements and/or elements that you are overlapping to have position:relative; or position:absolute; for z-index to work properly. When someone say positioning they're usually implying having the position property set in CSS. Also when working with z-index make sure that the overlapping elementa are at the same level with each other.
Hope this helps
Quite simply, the order of the elements in your HTML file will determine stacking order. If you want an element to be above another then make sure it comes later in the HTML.
You can only swap the stacking order on elements that are all in the same containing element. For example if you have two divs and they both contain 3 images you cannot make images from the second div go below images from the first div.
You need to plan your HTML ahead if you need complex stacking orders.
As hinted by the other answers, position:relative and position:absolute reset the "stacking-context" in IE.
If you want a lazier answer you could use javascript and hide the div when you click on the map, and show it when you close the map.
You will have to do this with any selects on the page anyway because in ie they don't work with z-index.
I ran into this same issue a couple days ago and found the negative margin as suggested by Darko Z worked great. (My rep isn't good enough yet to vote for Darko)
I wrote a quick post on it.
http://www.swards.net/2009/03/layering-html-elements-without-using.html