iframe = Inline?
While debugging some layout problem today I was surprised to see that <iframe> elements have a default display property of inline.
For me this seems strange, especially considering that you can apply a height and width to an <iframe> that is respected by the browser, which should not be the case for a simple inline-element.
So can anyone explain me the reasoning behind this?
Demo
HTML
<iframe id="test"></iframe>
CSS
alert($('#test').css('display'))
https://jsfiddle.net/0tdLr9pq/
Thanks!
Because the HTML4 spec said so:
The IFRAME element allows authors to insert a frame within a
block of text. Inserting an inline frame within a section of text is
much like inserting an object via the OBJECT element: they both
allow you to insert an HTML document in the middle of another, they
may both be aligned with surrounding text, etc.
The "be aligned with surrounding text" part means they shouldn't be block-level by default.
And it's true that, usually, inline elements ignore the height and width properties:
10.3.1 Inline, non-replaced elements
The width property does not apply.
10.6.1 Inline, non-replaced elements
The height property does not apply.
But that's not true for replaced elements, like iframe. This is explained in 10.3.2 and 10.6.2 sections.
IFRAME stand for Inline Frame. See this : http://www.w3.org/TR/html401/present/frames.html#h-16.5
Related
I'm upgrading my site to use the <details> tag, for accessibility purposes.
My question is this. When the "open" attribute is set on the <details> tag, as below:
<details open>
<summary>more info</summary>
<ul>
<li>blah</li>
</ul>
</details>
is there anything different in CSS terms about the <ul> tag? It seems to have display: block set whether it's visible or not.
I'm trying to write front-end tests to check that the <ul> becomes visible when the element is clicked, and I'm not sure how to do this without something actually being different in CSS.
JSFiddle here: http://jsfiddle.net/6x2Kc/
In terms of how to detect visibility, Mathijs Flietstra's answer seems to fit the bill.
On the broader matter of what the CSS is actually doing, the HTML5 spec has something to say here:http://www.w3.org/html/wg/drafts/html/master/rendering.html#the-details-element-0
It says:
... the [details] element is expected to render as a 'block' box with its 'padding-left' property set to '40px' for left-to-right elements (LTR-specific) and with its 'padding-right' property set to '40px' for right-to-left elements. The element's shadow tree is expected to take the element's first child summary element, if any, and place it in a first 'block' box container, and then take the element's remaining descendants, if any, and place them in a second 'block' box container.
The first container is expected to contain at least one line box, and that line box is expected to contain a disclosure widget (typically a triangle), horizontally positioned within the left padding of the details element. That widget is expected to allow the user to request that the details be shown or hidden.
The second container is expected to have its 'overflow' property set to 'hidden'. When the details element does not have an open attribute, this second container is expected to be removed from the rendering.
In other words, the content of the details element other the summary element is put into an anonymous block box. (This is a bit similar to how if you make an element display:table-cell then it will be wrapped in anonymous boxes for table-row, table-row-group and table.) It is this anonymous box (and thereby its contents) that is hidden or shown, which is why you can't see the CSS specified values change for any element that you select, only the computed values.
A word of warning though. We don't have many implementations of the details element yet, and the spec text above doesn't require browsers to do it like that, it only says "expected to", so the other browsers may choose to achieve the effect by other means. We can only wait to find out.
In Chrome, the computed values of the ul's height and width properties change to auto when details is closed. Here's a jsFiddle which alerts the ul's height when you click on details.
Setting the open attribute of a <details> element determines whether the height of the content will be the natural height, or zero. If open is present, the height will be the content's normal height, if the attribute is absent, or the content is toggled closed, the height is zero. Here's a quick jsFiddle example.
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.
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.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What is the difference between HTML tags DIV and SPAN?
I know when coding HTML, I'm supposed to keep semantics in mind, e.g., h1 needs to be a main header, h2 needs to be a subheader, tables need to be tables, use <em> for emphasis instead of <i>, etc. Is there a proper difference between divs and spans except one is a block and the other is in-line?
When I was learning I was told that <span>'s were for styling text mid-line. If I had a small blurb of text that I needed positioned at a certain point in my webpage, one that doesn't warrent a <p> tag, would I use a span should I stick with div's? What if that text needs to cover two lines (i.e., it needs a width) if it contains nothing but text, what should I use?
Semantically, neither <div> nor <span> has any intrinsic meaning. They're "catch-all" tags meant to be used with stuff where no existing tag really fits. Use divs and spans as a last resort, if you care about semantics.
The only difference between them is that divs are block-level elements, and spans are inline. Meaning by default, a div will start a whole new block, and technically only inline elements and certain CSS would be allowed inside a span. Most browsers seem to process the tags regardless of the rules (assuming "tag soup"), and you can actually make either act like the other with CSS, but don't do any of that if you care about validation or cross-browser compatibility (which you DO care about, right?).
The primary difference between a span and a div is that a span is an inline element whereas a div is a block element, like a p or paragraph element. So, in essence
span { display: block; }
Is essentially turning all spans into divs. You use a span for just a line of text, like to apply effects or padding or something. Divs are generally for dividing up your web page, so if you had to position a piece of text somewhere I would recommend using a div.
Div is a division block, span is for spanning inline text.
So Div is a box/block with height and width, span is inline. Basically.
If you want to read the spec, here's a link.
The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.
<span> and <div> are both very generic elements. In themselves, they have no meaning.
The main difference is that <span> is an inline element. That means if you have something like:
<span>Some text.</span> Some other text
You don't have "Some other text" on a new line. If you replaced the spans with <div> (a block element), there would be newlines. Note that it is not proper syntax to have a block element inside an inline element. Therefore, you can have <span>'s inside <div>'s, but not vice versa.
See here for more:
Wikipedia - Span and div
About.com - Span vs. div
There is a fundamental difference: <div> is a block-level element, while <span> is an inline element. The difference is that block-level elements start and end with line breaks, and inline elements don't.
Perhaps even more importantly, depending on the HTML version, there are different rules for what other elements are valid inside block and inline elements.
Well, to give you a fast and simple answer, DIV is a division! The goal is to use it when certain elements are in need to be treated as a group!
Ex:
Use a div to have a login panel, lets say, hidden # the left side of the screen, that show's up when the mouse hovers the div :)
You've got it. Span = inline, Div = block. That's all.
If a blurb of text needs it's own layout, (You want to put it somewhere on the screen) then it's a div.
If a blurb of text participates in the layout of the other text right next to it, then it's a span.
An inline element can't have its own layout -- then it wouldn't be inline.
I have a form I'm floating. When there is an error, via jquery, I'm adding some content to a p within the form. However, the form doesn't vertically resize to fit the new content. Is there something I have to do to get a floated element to resize when the content within it changes?
Do you have height or other css styling applied that would prevent it from vertically resizing?
Also, what browser(s) is it happening in? It may be a browser bug.
If the is floated, too, then depending on the styling (position: absolute), its dimensions may not be considered to be "in" the form.
Is there a height set on the content? When float is on, the default is to fix height to line height. It is possible that your width on the form is set too low, and the text is trailing off through the block element containing your form Try messing with the line-height property and see what you get. Also, position absolute will mess with you (as Richard mentions below)
Also, consider min-height. This won't work in IE6, but you can substitute with a height in IE6 which acts like min-height in certain circumstances.
Post you code so I can be more specific.