Posted some times ago on SO Span to take full height on a TD, as I tried some workaround, I've found a suitable code to do what was expected (the accepted one), but wasn't able to determine why this is working, so why
<td style="padding:0px;">
<span style="height:100%; width:5px; background-color:pink;"> </span>
</td>
make so much difference with
<td style="padding:0px;">
<span style="height:100%; width:5px;
background-color:pink;display:block;overflow:auto">
</span>
</td>
Here's a jsfiddle to explain more http://jsfiddle.net/7kkhh/2/
Can someone who know in depth the mechanism behind display and overflow explain this? (is it related to this particular situation or is it commonly used ?)
EDITED:
This seems to only happen on Chrome
A span element is, by default, rendered as an inline-block, just like text-nodes. They collapse around their child elements (or: they take up as much space as their child elements need, but nothing more than that).
A div element is, by default, rendered as a block. They expand to the size of their parent element, unless their child elements don't fit in it. If overflow (actually a shorthand for overflow-x and overflow-y) is auto (default), the element will expand until it's child elements fit. That will in turn expand it's parent elements, unless they have an other value set for overflow. If overflow is scroll, the element will not be expanded if the child elements don't fit in this element, but instead scroll bars will be displayed. If overflow is hidden, the element will not be expanded, but the (parts of) the child elements that are outside the parent element will be hidden (this doesn't mean that you can't scroll the element, but no scroll bars will be visible).
As inline-block conflicts with height: 100%;, the CSS style is ignored while rendering. A table cell has a display value of table-cell or something similar. I am not sure about it's behaviour. Tables and layout are always a troublesome combination to get a consistent layout in different browsers. Validating your document in xhtml-strict will usually help with displaying your document consistently across browsers.
overflow determines what happens if your block does not fit it's given dimensions. This is especially important if you are loading a picture as well.
For display you might want to read up on this :
SPAN vs DIV (inline-block)
Now the difference:
prepare the size of whatever I estimate to be in here and make it pink
vs
background-color:pink;display:block;overflow:auto">
make it pink now this was actually a block not a span and it it does not fit increase size until it does.
But seems you code shows unwanted behaviour on firefox as well and only works on chrome suggesting that maybe this is not the solution you are after.
Related
This is the scenario.
I have a simple table with a header row including several columns which have a dynamically changing width. Within the head row there are lists of a height that is longer than the head rows height, they are however only supposed to be visible on hover, but when on hover they are supposed to be ontop of the headrow but still having the the original 100% width of the parent being the <td> element of the column.
What I did was to set position: absolute on hover but as soon as that happens the element obviously took all the width it can get, fixable only with a specificly applied width, but that doesn't really help me as the column can be resized.
My Question is if there is a way in CSS ( NOT Javascript ) to achieve a behaviour where the element would still use the parent's width.
The answer to your question will vary wildly depending on what you're trying to accomplish. Most blanket solutions require:
The addition of extra positioning elements (often added using Javascript)
Setting display: block; on the TH, TD elements (often makes the TABLE behave erratically)
The reasons for this is that adding positioning to a table cell removes it from the flow, which affects table alignment (see this bug report comment). A much longer discussion about this issue and the possible solutions can be found at Does Firefox support position: relative on table elements?
That aside…
If you are using the TABLE for site layout, stop now and re-think your choices in life. There are better options:
The best option will be the CSS3 Flexible Box Layout model, if and when it becomes widely supported. Support at the time of this writing is minimal, scattered, and doesn't always follow the same standard (caniuse.com: flexbox)
Until that becomes an option, it's a little known fact that absolutely positioned elements can be positioned inside absolutely positioned elements. See this fiddle for an example of a 100% width/height layout made possible with absolutely positioned elements. Alternatively, the same layout can be made inside a relatively positioned parent element.
If you're not using a TABLE for site layout, then there may be other options open to you. It depends on the desired effect.
I was writing the layout of an app using the box-flex property (in Chrome) and I have found a strange behaviour, in my opinion, that I am wondering if might be a bug or that I just ignore the reason for those workings.
The code looks like this: http://jsfiddle.net/5tuCh/
There is a weird "div" resize when resizing the "textarea" so that the dimension of the "div" minus the "textarea" is equal to the dimension of the second "div", in order to satisfy "box-flex:1.0" I guess. Now if the reason for box-flex was making it easier to arrange the layout, this behaviour makes it unusable in this case.
Might it be that I am missing something?
Thanks.
This is in fact correct behaviour. From MDN:
The containing box allocates the available extra space in proportion
to the flex value of each of the content elements.
In your example, div.text boxes actually render with a height, meaning that any space beyond that would be spread evenly (or, rather, according to the flex ratio) between the elements. Setting height:0 on these elements would force behavior that I believe you're after (fiddle: http://jsfiddle.net/5tuCh/16/); I also had to remove the height:100% declaration on your textarea to prevent it from collapsing inside an element with zero height. I'd speculate that you may accomplish the textarea to take up full height of the parent element by setting its box-flex property as well.
Update:
OP's having issues with textarea behaviour could possibly be addressed by the following style:
textarea {
position:absolute;
top:10px;right:10px;bottom:10px;left:10px;
resize:none;
}
The parent element, of course, has to have position:relative set, which would result in the textarea taking up all available space in the container (w/10px spacing between the borders). Not sure if that's what you were after though. Fiddle: http://jsfiddle.net/5tuCh/36/
Can someone explain to me why overflow has the following effect.
In the jsfiddle below I have a Div floated to the left with a width and height set.
Next I have a Content div. You could think about this as a left navigation and a content of a site layout.
Inside the content I have two Divs which are identical apart from one has overflow:auto the other doesn't. The one with overflow:auto currently respects the floated div and shortens its width to not clash with it. Were as the other one simply keeps its full width and runs underneth the floated div.
Although the overflow:auto gives a very userful behaviour I do not understand why it cares about the floated item. I thought if a element has a certain width and the content inside that cannot fit, then it will do your requested behaviour but this is sort of applying the behaviour to the element itself
http://jsfiddle.net/9bEDj/1/
Can someone clarify this for me and explain why this is the behaviour or if it shouldn't actually be doing this and its a quirk!
Here is a fabulous description on the float/overflow magic
http://colinaarts.com/articles/the-magic-of-overflow-hidden/
It's the intended behaviour that elements with overflow other than visible should respect the floats, so you can use it with not causing any fuzz
It happens because setting overflow establishes a new block formatting context, and block formatting contexts do not overlap floats.
I have a block-level element of unknown width. This element needs to be horizontally centered on the page, and its position needs to be relative so that its absolutely positioned child will show up in the right place. You can see it in action here.
As far as I know, the best way to center an element of unknown width is to set its display to table. Semantically, this seems incorrect, because my element has nothing in common with a real table. Even worse, Firefox doesn't apply position to tables, so the absolutely positioned child shows up in the wrong spot:
Are there any workarounds for this that:
don't add any extra elements to the html
don't calculate and set the element's width with JavaScript
I'd like a pure CSS fix, and I'm running out of ideas...
Adding display: inline-block; to the element (#box) should suffice. This will cause it to become an inline element and still keep its "boxy" properties. Its width will automatically take up the width of its children.
Then you can set its alignment by setting text-align: center; on its parent.
IE7 does not support this display value (only on naturally inline elements), but the situation is the same with table (no support at all). You can use a hack though to make inline-block work in IE7.
jsFiddle Demo
If worst comes to worst, you could try text-align: -moz-center; which is a Firefox-specific method of centering block elements like inline-elements.
Take this trivial example and open it:
<html>
<body style="background-image:url(http://upload.wikimedia.org/wikipedia/commons/2/21/Mandel_zoom_00_mandelbrot_set.jpg);background-repeat: no-repeat; background-position: top center;">
<div style="width: 8000px; border: 3px solid red;">Demo</div>
</body>
</html>
The page is made so that the body has a top-centered background picture and a containing element which overflows window boundaries so there is horizontal scrolling (if you have a monitor wider than 8000px then you're really cool, please make the window smaller and refresh).
The problem is that for some reason the <body> doesn't stretch to contain the <div>. It just stays the same width as the viewport and the <div> overflows it. This in turn causes the background to be centered at the wrong place and crops it to the size of the viewport. Quite ugly when you scroll to the right.
I've already found a solution to this problem, but I'm wondering WHY this is so? It seems to be consistent across browsers too. But in my opinion this is quite counter-intuitive and basically plain wrong. The container element should be big enough to contain it's children - unless they are absolutely positioned of course in which case they don't participate in the layout calculations.
Blocks simply do not stretch horizontally to accomodate their child content, at all; never have.(1) That's something that only happens in the vertical axis.(2) Logically, both dimensions can't be stretchy; one has to be fixed (wrt parent). In CSS, the width of a block element in normal flow is derived solely from the parent (minus paddings, margins, borders), and then the height follows on from that, seeing how much content you can fit in the block's width and flowing it.
The background image can appear in a confusing place that misleads you to what is actually happening because of this quirk of CSS:
For documents whose root element is an HTML "HTML" element or an XHTML "html" element that has computed values of 'transparent' for 'background-color' and 'none' for 'background-image', user agents must instead use the computed value of the background properties from that element's first HTML "BODY" element or XHTML "body" element child when painting backgrounds for the canvas, and must not paint a background for that child element. Such backgrounds must also be anchored at the same point as they would be if they were painted only for the root element.
This is a nasty hack put in place because people were used to putting backgrounds on ‘body’ and having it fill the viewport, even though the <body> element itself does not represent the viewport.
(1) except in a few special cases, like float and position: absolute elements without a declared width.
(2) unless you deliberately stop that by setting height/overflow.
The exception to expanding is the viewport. Nothing expands the viewport unless its direct or attached contents require it -- this includes that div and table elements (eg, display: table-cell on body) -- but not a block container.