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.
Related
According to MDN, a button is an inline element.
However, button elements have default styling with display: inline-block (See this question)
button, textarea,
input, select { display: inline-block }
So far so good.
However:
If I now set the button with display:inline - width still applies!!
DEMO
button,
div {
width: 200px;
border: 1px solid red;
display: inline;
}
<button>button</button>
<div>div</div>
Now, according to the spec: width does not apply to inline elements (which are non-replaced)
Applies to: all elements but non-replaced inline elements, table rows,
and row groups
That being the case:
Why does width still apply to an inline button element?
As mentioned in the comments, I'm pretty sure this has to do with browser-specific rendering behavior as is so typical of form elements. What I believe is happening when you set display: inline on the button is... nothing. Effectively, it's the same as the typical browser default display: inline-block, on which the width property does apply.
Refer to section 10.2, which describes the width property itself. In particular it explains why exactly the width property does not apply to inline elements (or inline boxes):
This property does not apply to non-replaced inline elements. The content width of a non-replaced inline element's boxes is that of the rendered content within them (before any relative offset of children). Recall that inline boxes flow into line boxes. The width of line boxes is given by the their containing block, but may be shorted by the presence of floats.
In short, it's because the content of inline elements resides in line boxes. The width of a line box cannot be controlled directly; it is determined entirely by the containing block and any incidental floats. You can see an example of line box rendering in section 9.4.2, which describes inline formatting contexts.
If display: inline actually made a button render as an inline box, all its contents would spill over and it would no longer look, or function, like a button. It makes sense to want to prevent that from happening, and I think that's just what browsers do.
So what exactly do they do to prevent this? Is a button a replaced element? I can't say for sure. But note, in section 9.2.2, it says:
Inline-level boxes that are not inline boxes (such as replaced inline-level elements, inline-block elements, and inline-table elements) are called atomic inline-level boxes because they participate in their inline formatting context as a single opaque box.
Section 10 does not explicitly mention atomic inline-level boxes, but it does have sections for calculating dimensions for inline replaced elements, as well as inline-block elements whether replaced or non-replaced, all of which are considered atomic inlines as mentioned above. In all of these cases, the width property applies as normal if it's not auto.
So, while it's still debatable whether or not a button is a replaced element, it probably doesn't matter at all for the purposes of this question. But it is still some kind of atomic inline element, since it still participates in an inline formatting context. For what it's worth, though, it appears to shrink to fit its contents if you don't set a width, so its behavior is probably closer to that of an inline-block in that case. One could say then that the actual value of display becomes inline-block, although this is never reflected in the developer tools because the computed value does not change (again a side effect of browser-specific rendering behavior).
Since like Boltclock, I don't think that there's a simple answer to this, this is as much a dump of my thoughts on the subject as an answer, but I hope it will be informative.
Although the CSS display property is superficially quite simple, it actually contains a multitude of aspects. The CSS level 3 draft spec css-display captures some of this complexity, but still doesn't seem to cover it adequately.
The HTML5 spec says for the rendering of <button> elements:
When the button binding applies to a button element, the element is
expected to render as an 'inline-block' box rendered as a button whose
contents are the contents of the element.
An inline-block box has a number of aspects to it:
1. An inline-level element
This means that it participates in a inline formatting context within a line box. It flows in sequence with other elements that are on the same line. The line box's content can be centre aligned with text-align:center property on its container, and the line box is shortened by avoiding floated elements.
2. Applies a width property and the auto value is shrink-to-fit
Unlike non-replaced display:inline elements, the width value applies. But also, if a width value is not specified, a shrink-to-fit algorithm is applied to determine the width. This is like floated elements, or display:table elements, but different from display:block elements which are as wide as possible if no width is specified. It's also unlike replaced inline elements and replaced inline-block elements which, if no width is specified, use their intrinsic width if they have one and a default value of 300px if they don't. Shrink-to-fit is a meaningless concept for replaced elements.
3. A block-container element
Block container elements are make up of a stack of line boxes. The content flows from one line box to the next and the height of the inline-block elements grows (subject to overflow) to fully contain all the line boxes.
4. The baseline is the baseline of the last contained line box
When the inline-block element contains multiple lines, its baseline is the last of those lines. This is unlike floats or display:table-cell elements which are also shrink-to-fit, block container elements. Floats are outside normal flow so they do not have a baseline, which display:table-cell elements have a baseline that is the baseline of their first line box. A button that has multiple lines does vertically align according this last line box rule.
Now, this is fine for the default display setting. and the HTML5 rendering requirement means that the used value of display for buttons is inline-block even when the specified value is inline. But it doesn't account for the behaviour when specified value is block. In this case, the element has a line-break before and after it, and margin:auto centres the box as a display:block element would, and is not what would be expected of inline-block.
However, its width for a specified value of auto is shrink-to-fit like inline-block, whereas the expected behaviour for display:block is as-wide-as-possible. As far as I know, the only display value that behaves like that is display:table, but there is nothing else to suggest that display:table is being used.
So there's nothing in the spec that I can find which matches this precisely. We can only hope that when the css-display spec gets completed, that it will cover this behaviour.
There are 2 types of element.
Non-replaced elements
Replaced elements
Button belongs to replaced element category.
You can find more on below link.
Littlewebhut
SitePoint
So, for button, according to spec, it becomes right.
Inline, non-replaced elements
The width property does not apply. A computed value of auto for margin-left or margin-right becomes a used value of 0.
Inline, replaced elements (This section applies to button)
A computed value of auto for margin-left or margin-right becomes a used value of 0.
If height and width both have computed values of auto and the element also has an intrinsic width, then that intrinsic width is the used value of width.
If height and width both have computed values of auto and the element has no intrinsic width, but does have an intrinsic height and intrinsic ratio; or if width has a computed value of auto, height has some other computed value, and the element does have an intrinsic ratio; then the used value of width is:
(used height) * (intrinsic ratio)
If height and width both have computed values of auto and the element has an intrinsic ratio but no intrinsic height or width, then the used value of width is undefined in CSS 2.1. However, it is suggested that, if the containing block's width does not itself depend on the replaced element's width, then the used value of width is calculated from the constraint equation used for block-level, non-replaced elements in normal flow.
If width has a computed value of auto, and the element has an intrinsic width, then that intrinsic width is the used value of width.
If width has a computed value of width, but none of the conditions above are met, then the used value of width becomes 300px.But, if 300px is too wide to fit the device, UAs should use the width of the largest rectangle that has a 2:1 ratio and fits the device instead.
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.
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.
I am trying to give my div and textarea some padding. When I do this, it increases the size of the element, instead of shrinking the content area inside of it. Is there any way to achieve what I am trying to do?
You could add box-sizing:border-box to the container element, to be able to specify a width and height that don't vary when you add padding and/or border to the element.
See here (MDN) for specifications.
Update (copied comment to answer)
Right now, the value border-box is supported in all major browsers, according to MDN Specs
Some browsers of course requires proper prefix i.e. -webkit and -moz as you can clearly see here
According to CSS2 specs, the rendered width of a box type element is equal to the sum of its width, left/right border and left/right padding (left/right margin comes into play as well). If your box has a width of '100%' and also has margin, border and padding, they will affect (increase) the width occupied by the object.
So, if your textarea needs to be 100% wide, assign values to width, margin-left/right, border-left/right and padding-left/right in such a way that their sum equals 100%.
In CSS3 we have three box-sizing models. You can use border-box model:
The specified width and height (and respective min/max properties) on
this element determine the border box of the element. That is, any
padding or border specified on the element is laid out and drawn
inside this specified width and height. The content width and height
are calculated by subtracting the border and padding widths of the
respective sides from the specified ‘width’ and ‘height’ properties.
This was a mess on W3C part and various browsers only added to this complexity with their own versions of box models. Personally, instead of thinking which browser or CSS setting will do the trick I just wrap the box' content in yet another DIV statement and use margins on that DIV, instead of using padding, like this:
<div id="container" style="width: 300px; border: 10px solid red;">
<div id="content" style="width: 250px; margin: 25px;">
Some content
</div>
</div>
Although this only works for fixed size containers
It depends on the browser and it's implementation of the box model. What you are experiencing is the correct behavior.
IE traditionally got it wrong: http://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug
For a more cross-browser solution, you can avoid this behavior, by wrapping whatever tag that needs padding into another tag with fixed width, and giving it width:auto. This way, if the parent has a width of x, and you add padding to the child, the child will inherit the full width of x, applying the padding correctly without modifying the parent width or its own.
A div by default takes the width of its parent container, so to avoid browser compatibility issues, you could add a child div in the specified div then add the required padding to the child div.
N.B - don't specify width to the child div because it would increase if you add padding
Do elements before they are part of the dom have the width and height set properly? ie if I create a div containing markup can I measure its intended width and height without appending it to the dom?
I don't formally know the answer, but a little gedankenexperiment lets us see that it can't, in general, happen. If you create an HTML element with a fixed width and height, then yes - you can know the width and height.
However, if you don't specify them (or they might not be obeyed), then the width and height are always going to be calculated by the contextual position of the fragment in the DOM; for example, a DIV with width: 50% cannot know it's actual width until it is added to the DOM and laid out - there's no other way to answer "50% of what?".