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.
Related
I hope there is a solution to this IE7 issue. I put an example on jsfiddle:
http://jsfiddle.net/fCqm6/
If you switch to the IE7-Mode in your IE you will notice that the block inside the cell is positioned all the way to the right.
I wanted however it to stay positioned in the middle (as it is with Chrome or current IE version).
If I set the width of the box to a fixed value, the box is positioned quite differently. But I need to set both the width and margin as a percentage if possible (the end result is a sort of timeline where dynamic elements need to be positioned and stretched based on their duration)
Is there any hack or workaround so that these percentage margins work inside a table apart from javascript?
Thanks!
Well, I figured this out myself:
By adding a div between the table cell and the box with a set width of 100% IE7 renders the box correctly:
http://jsfiddle.net/fCqm6/1/
Please note that I am not trying to resolve any specific issue, but trying to understand what's causing this issue.
I have set the width, height and display of some divs, but the height/width settings are not being honored. The text is also being pushed downward.
http://jsfiddle.net/k7esv/
1) Why does it push the text downward when height is set in table-row then BUT when height is removed, it places text at the top?
2) Why are the width/height settings not honored?
3) Why doesn't setting the margin property have any effect on them either?
http://jsfiddle.net/k7esv/1/
1) This seems to be a rendering issue specific to Firefox. Setting the vertical-align property on the divs fixes it. top, middle, or bottom all seem to work. I don't understand myself what FF is doing when there is a height but no vertical-align set; it might be a bug.
2) The width and height are honored, but they are subject to table sizing rules. When a table does not have enough room to give each of the cells the width they have specified, it will give more room to cells that have more content. This is what was happening with your example. If you look at my example below, you will see that when the parent element is wider than the sum total of the table cells' widths, the cells respect the width. The height should always work (except in the case of the FF rendering issue I mentioned above).
3) Table cells don't have margins. Use border-spacing and display:table on a parent div.
http://jsfiddle.net/chad/k7esv/3/
I will just add (seeing as it seems to have been missed) that setting the heights on individual table cells in a table row can be pointless, as all cells in the same table row will become the same height as the tallest cell in said row.
Having said that, heights may want to be added for when dynamic content is served to different cells, meaning their heights fluctuate. It may be that you want to set a particular cell to never be less than height X, which will only come in to effect when another certain cell has less content.
Take a look at this jsFiddle in Safari or Chrome, then in Firefox: http://jsfiddle.net/brandondurham/LRJhm/
What it looks like in Webkit: http://cloud.smallparade.com/B4TE
What it looks like in Firefox: http://cloud.smallparade.com/B53R
You'll see the flexible box is broken in Firefox. The longer of the two boxes (.left) has the css property white-space set to nowrap because, well, I don't want it to wrap. This single property is making the flexible box break and extend to fit the entire contents of the .left div.
Anyone else seen this behavior? Have a fix?
While I think the accepted answer by robertc is correct (in that is how box flex is supposed to work). You can disable the "intrinsic" width he talks about by setting that width of the box explicitly to 0. This way, only your specified distribution of the widths is taken into account.
This behaviour can be explained, because, when you set all the box widths to zero, then all of the width will become "remaining", thus the distribution depends completely on what you specify.
Set width: 0 on the element and that will become it's "preferred width", and will make non-wrapping text items inside the element behave correctly.
http://lists.w3.org/Archives/Public/www-style/2011Jan/0201.html
That's how it's supposed to work. Flexbox distributes the left over space after the intrinsic width of the elements has been calculated, it does not control the intrinsic width of the elements themselves. This is why the results are unintuitive if you don't set explicit widths on things, though the working group is reviewing the spec.
My advice would be to try using display: table; instead, though you may encounter some similar issues.
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.
The font size I need to match the design I have is 85pt, which is extremely large. In IE6 and IE7, my design is affected because the divs that contain these elements become larger than they normally are, and as a result, elements under these are pushed further down, somewhat breaking the design. I have the height defined for these elements and when I decrease the font size, the elements begin to shrink to the correct size. I've added line-height: 0; to the element and this works in all modern browsers.
Unfortunately, the design I'm working on cannot be shown publicly, but I was hoping to get some insight into other possible techniques that I could try to get the design to render correctly. The height of the parent element is 144px, which includes 10px padding on top and bottom and a top and bottom 1px border.
Unfortunately there's not a lot more that I can add to this, but I'll include whatever info I can if asked.
line-height:0 is a great start. However, I'm a little concerned about the 10px padding on the parent element. Whenever you mix padding with IE, you start to lose control over width & height.
I'd start by removing the padding-top on the parent and convert that into a margin-top:10px on the actual child element. If that still gives you trouble, remove the margin and try a position:relative on the child with a top:10px.
Finally, try adding a overflow:hidden to your parent element to force it to not budge when the font-size gets larger.
All this depends on what your child element actually is. If you convert it to an inline element (like a span, em, or strong) it might help alleviate some rendering issues, depending on your predefined styles.
Another thing to consider - are you using floats? Sometimes you'll get a double-float issue with IE and floats. A quick google for "IE double float" will show you why.
Does that help?
Convert the font-sizes to pixels and use px instead of pt. Make sure there that padding, margin and border is 0. Verify that there are no whitespace in your HTML except for between words. Whitespace can end up being displayed as a newline or space, making elements bigger than intended. Also don't set line-height to 0, set it to either auto or the same as font-size.
Thank you all for your input. Originally I needed absolute positioning on the element in question, while the parent element had relative positioning. However, using this with line-height: 0 caused the text to disappear in IE6 and 7; after trying to figure out where the text was initially, I removed absolute positioning and decided to leave the text left aligned in IE6 and 7, which affected the position of other elements as a result. I revisited the original absolute positioning and added border to the element to reveal its location. Doing this showed that it was exactly as I defined it: an element with a line-height of 0px, so the top and bottom borders were next to each other. For IE6 and 7, I defined line-height: 100%; and my text was almost where I needed it. I added top and the needed pixels and now my element is in the correct position with its line-height not affecting any of the other elements because of the positioning.
Thank you all again for your assistance.
My first thought when reading your post was to adjust the line-height, but since you've already done that, I'm not sure how much more can be done. From your summary, I gather that the design cannot be modified to account for the large font sizes.
Another answerer recommended using pixel sizes, but I would recommend using ems as they are percentage dimensions and will be more consistent across browsers, screens, and resolutions.
Line-height can be left as 0 (or set it to the height of the parent element), but you will likely see the text floating over other elements if the text's height surpasses the line-height.
Any possible way you could use an image for the text instead? That's really the only fool-proof method for getting all browsers to look consistent.