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.
Related
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?
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.
EDIT*the issue apparently comes down to the fact that, i need to use relative position on the large image, so i can adjust the top value. this causes the thumbs to be put on top of the main image. When i remove the relative positioning of the main image, the flow looks fine, but the top positioning is disregarded- i sort of need both to have the dynamic manipulation of this app im developing*
I wish I could understand why this happens like 90% of the time I go to code div layouts.
You have content in your div with a certain height, and then you have another div directly after it - and somehow it just goes right on top of the first one.
I wish I knew where the problem was, but I can't figure out what CSS is the cause.
Anyways, if you care to take a look, this is the sandbox of the issue I'm having:
the reference is changing because i keep updating it to check sorry.
http://www.drewswinson.com/DP/
I'm making a dynamic jQuery gallery viewer and the thumbs just don't want to put themselves below the image.
It happens all the time though; is there any reason content inside a div would allow subsequent divs to not be placed below the content its supposed to be filled?
You problem is the position: relative attribute on imageDiv.
It pushes the image down from where it should be. If you remove that, the static flow of the page will be used, which is what you want in this case.
I'm having a problem with a textarea and submitbuttons in my form.
Here's a first screenshot of a seemingly normal situation:
And here's what happens if I set the textarea to have 30 columns:
The textarea just went right over the buttons. I'd expect the buttons to be pushed down. Or anything below it, for that matter. What do I need to set to make this happen?
Most likely (and you should show more CSS code to be sure) you have your labels/fields floated inside an element with fixed height..
Use an element with clear:both after the textarea..
I've been working on trying to fix an issue with print CSS and IE where things would disappear when printing in landscape mode.
It appears the issue is that the element I'm trying to print (a large DIV with content inside it) spans two pages when put into landscape mode. What is happening is when the element spans two pages, the first page is blank, and the second page is printing what would normally be left over from the first page.
I think it's related to contained floats:
wrapper div
floated div1
floated div2
If I set the two nested divs to float: none in the print CSS file, then IE will print them, albeit not in the layout we'd like.
Before I spend another hour on this, anyone know what, specifically, is the issue here and if there's a known workaround?
The problem for me was that I was setting display:inline-block for the main container div. This along with declaring a width is a method to make a parent div extend to contain the floats inside.
I've removed display:inline-block and used clearfix instead. Problem fixed.
It seems to be a problem with tables, but it may just be the nesting, but it is an IE bug.
http://support.microsoft.com/?kbid=257097
Still trying to work around the problem myself.