I tried it in different browsers,but it seems to be not working.If I change the number(min-height),then beyond 50 it works and below 50 with any range of values it stays at the same height.So,is there any way to keep min-height of a textarea below 50,say at 10px?
<textarea style="width:700px;resize:none;min-height:10px;"></textarea>
<textarea style="width:700px;resize:none;height:10px;"></textarea>
That is related with the default value of the attribute rows in the text area!
The default is 2 according to http://www.w3schools.com/tags/att_textarea_rows.asp.
So try to change it to 1 an play with the height attribute a little.
If you want your textarea even littler that 1 row size, then adjust your text area style in css "line-height".
The min-height property sets the minimum height of an element, as its name suggest. This means a height that is used unless nothing requires a larger height. For a textarea element, the default height is determined by the number of rows (specified by the rows attribute, which is defaulted to 2 by browser practice and by HTML5 CR) and by browsers’ calculation of line height.
Thus, you can set min-height even to 10px, and it works as defined – the actual height is larger, but that follows from the definition.
To set the height, you would use the height property, as in your example, and/or the rows attribute, which indirectly sets the height. As usual, it sets the content height. The total height of a textarea box is content height plus top padding plus bottom padding plus top border plus bottom border.
It is difficult to imagine a situation where it would make sense to set textarea height to 10px, which is not enough for even one line of text in a size that is legible to most human beings. Moreover, if you really want to have an input box that is one line tall and is not resizable, an input type=text element would be a much more practical and much more logical choice than textarea.
Related
I am reading the book Head First HTML and CSS and there it is written that a requirement for any floating element is that it must have a width. I tried floating right a div element without specifying width on it, and the float property works(it moves the div furthest right as possible) as supposed. Does this mean that there is an error in the book, or it is something that i am missing ?
Yes, you can have floated elements with no width values declared in the cascade. Then, through a defaulting process, the specified value will be the initial value.
For width, the initial value is auto.
CSS explains what should happen when a floated non-replaced element has width: auto:
If width is computed as auto, the used value is the
"shrink-to-fit" width.
Calculation of the shrink-to-fit width is similar to calculating the
width of a table cell using the automatic table layout algorithm.
Roughly: calculate the preferred width by formatting the content
without breaking lines other than where explicit line breaks occur,
and also calculate the preferred minimum width, e.g., by trying all
possible line breaks. CSS 2.1 does not define the exact algorithm.
Thirdly, find the available width: in this case, this is the width of
the containing block minus the used values of margin-left,
border-left-width, padding-left, padding-right,
border-right-width, margin-right, and the widths of any relevant
scroll bars.
Then the shrink-to-fit width is:
min(max(preferred minimum width, available width), preferred width)
The "shrink-to-fit" algorithm is now called fit-content measure.
float:right is simple stacking of elements, left to right until a line width is filled, then top to bottom. Like writing an English newspaper page.
float:left is used for things like a sidebar, it would take up the whole page, unless its width is constrained. This is why the width must be specified.
<div style = "float : left; background-color: #dd3fb8;">
<a style = "margin-left : 10%;">a</a>
<a>b</a>
<a>c</a>
</div>
In the example above, the letter "c" would be on new line, but if I set "margin-left" to px unit, "c" would be on the same line as "a" and "b". Why does this happen?
Unfortunately, the CSS2.1 spec doesn't appear to have a clear answer to this. In fact, I would say this is well within the realm of undefined behavior.
Here are the relevant points I can find:
Floats without a specified width will shrink to fit their contents. In the case of floats with only inline content, the float needs to be made just wide enough to fit its contents on a single line (notwithstanding explicit line breaks) and no more.
Percentage margins are calculated based on the width of the containing block.
Note that it says:
If the containing block's width depends on this element, then the resulting layout is undefined in CSS 2.1.
... but as far as I can see, the behavior is consistent across all browsers.
That being said, the reason this statement applies is because since the margin of the inline element falls within the content bounds of the float, it can be said that the width of the float (the containing block of the inline elements) depends on the this element (the element having the margin).
Here's what I can deduce based on the points above:
When the margin is specified as a percentage, the width of the float is calculated without taking the margin into account, because it's not possible to calculate the margin until the width of the float has been determined.
The margin is then calculated based on the used width of the float, and the letter "c" wraps to a new line as a result of being pushed forward by the margin on "a". The width of the float does not change.
Again, none of this behavior is specified at all, and so technically it's not in violation of the spec. However, it seems sensible.
When the margin is specified as a pixel value, the margin is calculated first. The width of the float is then calculated taking this margin into account (remember that horizontal margins do apply to inline elements as normal). Per the shrink-to-fit algorithm, this is the preferred width: just wide enough to contain all the inline elements on a single line.
Unlike with percentage margins, this is very clear-cut, as implementations should have no trouble calculating computing absolute values for margins first.
I would be hard-pressed to call this a bug in any of the browsers, especially since they all behave consistently.
Lastly, of course, you can avoid this undefined behavior entirely simply by giving your floats explicit widths where possible. It does help to understand why you should do so, however.
Since your div is floated, and its width is auto (implicitly), http://www.w3.org/TR/CSS21/visudet.html#float-width applies:
If 'width' is computed as 'auto', the used value is the "shrink-to-fit" width.
“shrink-to-fit” width basically means, let the element be as wide as its content requires it to be.
Now without the margin-left, that is no problem: All three of your a elements are inline elements that contain a specific character each – easy enough to determine their individual widths, and add them up.
But now you want a margin-left in percent, and here things get complicated – if we look at the definition for margin-left, it says:
Percentages: refer to width of containing block
Now, that leaves us in a bit of a pickle, since the width of the containing block (which is established by the floated div element), is computed based on its content – but now this margin-left would change the overall width of that content, but is in itself dependent on the width of the containing block, which it itself influences …
That’s a classical problem of two measurements that are dependent on each other … and that is therefor basically unsolveable.
http://www.w3.org/TR/CSS21/box.html#margin-properties says,
The percentage is calculated with respect to the width of the generated box's containing block. […]
If the containing block's width depends on this element, then the resulting layout is undefined in CSS 2.1.
Edit: Basically the same as what BoltClock said in his answer, just took me a little longer …
The link has a left margin of 10%, 10% of how much? The parent element is floated left which means it does not have a width of its own, instead it expands as much as its contents. If you try to imitate how the browser would compute the resulting box and you will find yourself in a fix:
Let the width of the content (and therefore the container) be 30px
Add 10% of 30px = 3px left margin to the link
The resulting width of the container is 30 + 3 = 33px
This creates a loop where margin increases as outer width is increased and outer width increases as the margin is increased (10% of 33px = 3.3px means container width changes from 33px to 33.3px and so forth). For such computations the resulting behavior is undefined (as pointed out by CBroe).
The browser seems to avoid the loop and sticks with the 30px width. The 3px margin introduced after calculation causes the third link to flow into second row. The browser again avoids the loop by sticking with 30px width.
Here and there I see suggestions that I should always set width on floated items. But when I'm exploring CSS of popular web-services (such as Twitter/Google), I see that almost nobody does that.
Is it still considered good style to always set width on floated items? In which cases should I set 'width' property and when it can be safely omitted?
Some quotes:
SmashingMagazine says that:
“You should always set a width on floated items (except if applied directly to an image – which has implicit width). If no width is set, the results can be unpredictable.”
HTML and CSS: Design and Build Websites book says:
When you use the float property, you should also use the width property to indicate how wide the floated element should be. If you do not, results can be inconsistent but the box is likely to take up the full width of the containing element (just like it would in normal flow).
Well it really depends on the browser, you must check the results in multiple browsers to be sure that none of them "misunderstood" your settings. I'd set a width anyway, because no browser can misunderstood that.
Block element takes the full width of the parent. If you use float it will not take the full width, the width would be how much the element width it is.
i use width with floating elements in percentage of the containing div , the only problem you get is that the containing div might not wrap arround its content , so you have to put on the main div overflow:auto
I tried setting position:absolute and then left, top, right and bottom to fixed values in pixels, but unless I also set width and height I cannot get it to work properly on Firefox 11.
The rendering looks ok on safari/chrome... but is this a Firefox bug or something that isn't indeed standard? Using 100% for width and height is sometimes a solution, but not when the element is not completely covering the parent container.
See http://jsfiddle.net/EjS7v/6/
This is Chrome (and the desired result)
Firefox (width/height to 100%)
Firefox (without width/height)
Are there alternatives to using Javascript to compute width and height at runtime?
Note that in this example I've used a fixed size div as container, but the most interesting and useful case is when the container is elastic.
Actually there's a simple alternative, use presentational markup to contain that textarea and then just 100% width height for the textarea itself.
Indeed, CSS is very limited.
This is because textarea, unlike, say, a div, has a default width and height:
If the element has a cols attribute, and parsing that attribute’s value using the rules for parsing non-negative integers doesn’t generate an error, then the user agent is expected to use the attribute as a presentational hint for the width property on the element, with the value being the textarea effective width (as defined below). Otherwise, the user agent is expected to act as if it had a user-agent-level style sheet rule setting the width property on the element to the textarea effective width.
The textarea effective width of a textarea element is size×avg + sbw, where size is the element’s character width, avg is the average character width of the primary font of the element, in CSS pixels, and sbw is the width of a scroll bar, in CSS pixels. (The element’s letter-spacing property does not affect the result.)
If the element has a rows attribute, and parsing that attribute’s value using the rules for parsing non-negative integers doesn’t generate an error, then the user agent is expected to use the attribute as a presentational hint for the height property on the element, with the value being the textarea effective height (as defined below). Otherwise, the user agent is expected to act as if it had a user-agent-level style sheet rule setting the height property on the element to the textarea effective height.
The textarea effective height of a textarea element is the height in CSS pixels of the number of lines specified the element’s character height, plus the height of a scrollbar in CSS pixels.
How can you enforce the minimum width for a TD that can optionally contain an image? I ask this because I'm using a Javascript chess widget but when there are no pieces in any of the squares of a particular column, regardless of the width style of the td's being set to 36px, this column renders much narrower than those that have at least one row that contains the image of a chess piece.
Note that all the style is being set directly on each td cell. I read somewhere that a possible solution would be to instead create a div inside the td and set the width on that. Am hoping to avoid that as it might require significant modification to the underlying Javascript library. I've tried specifying !important along with the width but it had no effect.
Using firebug I can modify the width attribute but it seems the numbers are incorrect. For instance I can decrease the width all the way to 0 and it still appears the same. Or I can set the width to more than 36 and it appears to grow by width-36, but if for instance I set both the height and width of one of these narrow cells to the same number, lets say 60px, the height of what gets displayed is greater than the width and it appears as a rectangle not a square.
Furthermore not only can the td optionally contain an image, but each square specifies a background image too. So I am at a loss :( Thanks in advance
When I alter the CSS in your file using Firebug or the JS inspector in Chrome, setting the min-width property instead of the width property does the trick. Might want to try that? Not sure how IE will like that, though.
BTW: Why not use classes to do the CSS? It's kinda horrible to debug, this way.
By default tables will auto-size their columns.
If you set the table style to include:
table-layout: fixed;
then you'll have much better control of it via css and attributes.
You can use the td tags width attribute or you could use css and set the width.