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.
Related
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'm using the CSS word-wrap property (set to break-word) to display a single no-spaced string in its entirety within a div element of fixed width and variable height. The div element itself is within a table cell <td>. The word break works as expected, breaking the word at the defined fixed width. However, in IE9 (with IE7 document standards), there appears to be some extra space after the div, causing the table cell to extend in width (not desired). The div width itself appears to be correct, as specified by its CSS. I used borders around the div and table cell to verify. I've tried explicitly setting the table cell width (and max-width) but neither approach works. This behaviour is not observed in Firefox or Chrome.
Edit: Added sample code here. The problem only occurs with IE (Browser_Mode=IE9; Document_Mode=IE7).
Apparently the td is making room for the full length of the word, as though it weren't breaking. You can prevent this by setting overflow: hidden on the div.
jsFiddle: http://jsfiddle.net/gmDpe/6/
I came across a similar problem once.
Have you tried to use table-layout : fixed on your table element ?
table-layout is a very little known but widely supported property which can be quite helpful in cases like this.
I am trying to float divs horizontally, however its falling into a new line.
http://jsfiddle.net/nyCrY/4/
It works only if I set width of the #holder higher than its content.
Is there a way to do this without setting the fixed width on #holder?
Thank you!
Not really with pure CSS.
You can use a static width (which you don't want to do), you can use floats + whitespace (which is unreliable), or you can dynamically calculate the necessary width with javascript and set the style's width to that number.
According to this tutorial: http://css-tricks.com/how-to-create-a-horizontally-scrolling-site/
I spent some time playing with the float property and the white-space
property to see if I could find a way to fight browser auto-wrapping,
but I didn't have much luck. Page elements which are floated but do
not have a width exhibit a property where they expand to the width of
the content inside them. I thought perhaps if I put a bunch of float
elements inside of that, it might just keep expanding beyond the width
of the browser window. No dice. There is also a white-space: nowrap;
property in CSS which I thought might be able to be exploited to fight
the auto-wrapping, but it only works for text elements, not blocks or
just any old thing you set to inline. Oh well.
So, he basically is saying, no its not possible with just css.
But he goes on to say that you can do some javascript magic to achieve it:
JavaScript clearly has the ability to manipulate page elements and do
calculations on-the-fly.
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 sometimes find myself creating a div which serves no other purpose than to hold another element.
For example when creating a menu, I would create a div and assign it a background colour, position etc. Then within it I would create an unordered list.
I could surely assign all the properties I assigned to the DIV to the UL and not use a div at all.
Any ideas of what is best practice and reasons for it.
Thanks
Zenna
DIVs can be useful for grouping semantically related elements. If you are simply wrapping a single element that is also a block element, then you are simply adding bytes to the file.
No, they are not. The purpose of a div element is to create block level structure in the document. If you can lose them just lose them. Never use divs to solve design purposes, css is for that. Use html elements each like list, data definitions or tables (which were overabused in the past and used as the divs are now for css purposes). The more diverse your HTML knowledge is the less you are using divs all over the place.
I use often divs to keep child-padding/margins from ruining parent-width. But you need to be careful with this type of stuff - you could end up adding a bunch of nonsense.
The real issue is that we are using HTML in ways that its creators had never imagined. The need for 'all those divs' is because some really smart people have found some very creative ways to take a very old standard and do some very modern things with it.
Best practice should be to use as few div elements as possible. If you've got a div elements with only one child, chances are it's a useless div. The div element should really only be used when you need a block element and there is no semantic pre-defined element at hand. This includes grouping elements as Renesis suggests.
In the case of a UL, yes, the DIV is unnecessary. They are both block elements, so anything you can do with a DIV wrapped around the outside you can do directly to the UL itself.
However, because of the Box Model problem with some IE browsers, some people tell you to add these DIVs as a workaround. When you combine padding and width, IE6 disagrees with other browsers about what the final size of the element will be. So one workaround is to put padding but no width on an inner element, and width but no padding on an outer element.
Div's are really a necessary evil without a more semantically rich set of tags.
Their purpose is to server as a generic container. Therefore, I suppose you could say they do their job well.
If you can do what you're trying to do without the additional div, then leave it out. If it's an important part of your design that you can't fix with some clever CSS, then it's still a whole lot better than using tables...
I use DIVS primarily for at least one of two main reasons:
I need it to provide a new physical level of CSS in some way (either child padding inside a fixed width element, a shadow or a double border around an image, etc.)
It logically groups the elements it contains (for future portability and semantics in both HTML and CSS - I.E. "div#menu .label". This way I can use the "label" class several places but have a specific style applied to labels within the "menu" div).
For example, if you were to transfer all attributes to the UL, but then decided you wanted a caption or image above or below the menu but in the same location, you would have to create the DIV again to place the new element inside, and transfer half of the attributes back to it.