This question already has answers here:
How to calculate the height of an inline element
(5 answers)
Closed 6 years ago.
JSFiddle :https://jsfiddle.net/cs2tegy1/
As you can see, the content of inline item (<span>) are inside green box.My question is where is height of the box from .
Firstly it is not the height property which is not applicable to inline at all.
Secondly ,it is not line-height as well ,the only thing it affect is that space between the boxes.
So, where is the height from?
it's just the font-size (and height), including the space for the ascenders and descenders of letters like j, Q, p T F etc. (which can be different for every font)
line-height:normal is the default, which is about 1.2xfont-size for the major browsers. Look in the Computed Style tab.
On non-replaced inline elements, line-height specifies the height that is used to calculate line box height.
See https://developer.mozilla.org/en-US/docs/Web/CSS/line-height
That span is a non-replaced inline element and it's height defaulted to auto (which is irrelevant, since height doesn't apply to it unless it was anything but inline) it defers to line-height of about 1.2.
In the case of a line which contains only inline non-replaced elements which are all the same font-size and line-height, and all of which have the same vertical alignment, the solution is simple. The content-area is defined by the font-size of the elements, and the height of the line-box is equal to the value of line-height.
http://meyerweb.com/eric/css/inline-format.html
Sorry, 16px x 1.2 = 19.2px
From the conversation in comments, I understand your question is how the height of the green box/area is being calculated.
This area is not calculated by either height or line-height attributes. This area is, without any padding, the minimum area which covers all the letters in the span element - which is actually the font-size of your text.
Adding a border or padding to the span, it will make the green area bigger by that size.
Related
This question already has answers here:
CSS: Width in percentage and Borders
(5 answers)
Closed 2 years ago.
In my online text editor I get the warning when I specify both height/width together with a border in a CSS-file (see the picture below). I understand the message and that it could have an unwanted impact on my design... But in this case it's no problem for me.
But it raises a more general question: Is there a smart way to work with both height/widths together with a border width? Some best practice?
You can use box-sizing css property to handle it
By default in the CSS box model, the width and height you assign to an element is applied only to the element's content box. If the element has any border or padding, this is then added to the width and height to arrive at the size of the box that's rendered on the screen. This means that when you set width and height, you have to adjust the value you give to allow for any border or padding that may be added.
You can use box-sizing: border-box if you want the width and height include any border or padding you added. More details can be found in the docs.
I am projecting an image, then inspecting it:
The height is 20px. which is correct.
I then inspect the data-radium element containing the img and to my surprise:
The element has "grown" by two pixels in height, despite having no content. In addition, the data-radium element has no padding, no margins and nothing I can think of that would inflate the height.
Does anyone have any idea where those extra 2 pixels can come from? This is driving me nuts.
As I can't inspect the code, I'll try to guess: As images are inline by default, any line-height definition is inherited. Setting the image as a block element could work, as setting the line-height to 1.
This question already has answers here:
Why does an inline element accept width and height when floated?
(2 answers)
Closed 5 years ago.
I was unable set the width for an inline element <span> while creating a table-row with multiple span elements. I was able to modify the width once I put a float: left as well.
Why was I not able to set the width and height of inline elements? How does adding a float change things?
Answer A:
You can't explicitly set the width of an inline element because it is relative to the surrounding elements, and thus is restricted by their widths.
Answer B:
Floating an element with float automatically makes it into a block-level element by applying display: block to it. A block-level element occupies the entire space of its parent element (container), thereby creating a 'block'.
Hope this helps! :)
Inline elements by definition do not take explicit width or height but are inline and conform to the surrounding elements. They only occupy space bounded by the tags. For example:
This is some <span>text</span>
<span>text</span> only occupies the space that houses text. It's in the same line with the other text nodes in the HTML.
The float property implies block layout and the display property of elements is changed to block (in most cases) thus making them block-level elements where you can set explicit width and height because they occupy all of their container. Per the MDN documentation:
As float implies the use of the block layout, it modifies the computed value of the display values, in some cases
In this case, the table (viewable at the MDN documentation) shows that any elements with display: table-row would blockified and have display: block when floated.
I've set up a test here
http://jsfiddle.net/WZyF7/11/
Firefox seems to differ from Chrome and IE7-9 on how to calculate the width. Instead of giving the content as much width as it needs, it makes the div as wide it's widest child element. This stacks the elements vertically in FF, while horizontally in other browsers.
Is there any way to make all browsers handle this the same way without setting a width to the parent element or using JS? And does anyone have information on exactly how this is calculated across browsers? (width:auto; ? )
The relevant spec bit is http://www.w3.org/TR/CSS21/visuren.html#floats where it says:
The border box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap the margin box of any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. They may even make the border box of said element narrower than defined by section 10.3.3. CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower.
And the part in http://www.w3.org/TR/CSS21/visudet.html#float-width which says:
If 'width' is computed as 'auto', the used value is the "shrink-to-fit" width.
and following. Note that the actual computation of preferred width, which is what matters here, is not all that well defined. So basically, per spec behavior in this situation is undefined.
In any case, what's happening here is that Firefox is giving the overflow: hidden block the width it should have per section 10.3.3 and then clearing it past the float, while Chrome and IE seem to take the "they may even" path. And in particular, it's assuming it will do that when computing the preferred width of the parent.
All that said, I think the Firefox behavior is more correct in this particular narrow case: your "container" is 400px wide. The "parent" has 20px of horizontal padding. The "floated" is 300px wide. The "content" has 20px of horizontal padding. That leaves 60px of width for the text inside "content", but the longest word ("available...") is about 70px wide with my fonts. In Chrome, for example, the only way "content" fits next to the "floated" is because the right padding of the "content" disappears entirely. Firefox will do the same thing if you give a fixed width to the "parent" here.... but then you're forcing a width, instead of asking the browser to pick a reasonable one via the shrink-wrap algorithm, of course.
Your best bet here is to just give the "parent" a specific width if you want it to have that width, instead of relying on shrink-wrapping to produce a width that's actually too small for the content.
When you have two inline elements that share the same line, and the bigger one is vertical-align: baseline and the smaller one is vertical-align: middle why does the middle aligned element appear below the baseline element?
I've put together a demo illustrating what I'm talking about:
http://jsfiddle.net/mLSG2/
It appears that the smaller element's mid-line is aligned to the larger elements baseline, but that doesn't seems to make much sense to me. If this is true, what is the rational behind it?
More generally, can someone explain how alignment is calculated when elements of varying line-heights and varying vertical alignment declarations share the same line? Is there a place in the spec that defines this?
By the specification, vertical-align: middle should “align the vertical midpoint of the box with the baseline of the parent box plus half the x-height of the parent”. In this case, the vertical middle of the line box for the italic text should be aligned to the baseline of the div element plus half the x-height of that element. This makes it rather close to that baseline, really.
Since fonts are not set here, browsers will typically use a default font size like 16px. The x-height depends on font, but let’s assume the rough average: half of the font size, 8px. Half of that makes 4px, making the difference rather small. (The font size of the div element is not changed by the presence of inner elements with larger font size.)
The situation may be obscured by browser bugs. The vertical-align property has a buggy history. Often it’s better to use relative positioning.