Inline paragraph???

[King of Red Lions]

Just a quick question. With an image you can code them to be inline. Is
it possible to do this with a paragraph instead of an image? Many thanks
in advance

 

[Neal]

Just a quick question. With an image you can code them to be inline. Is
it possible to do this with a paragraph instead of an image? Many thanks
in advance

Images are, by default, inline. I'm not sure what the point of an "inline
paragraph" would be. What exactly is your desired result?

 

[Kris]

Just a quick question. With an image you can code them to be inline. Is
it possible to do this with a paragraph instead of an image? Many thanks
in advance

p { display: inline; }

 

[Toby Inkster]

Just a quick question. With an image you can code them to be inline. Is
it possible to do this with a paragraph instead of an image?

What do you mean? A paragraph within a paragraph? <p>...<p>...</p>...</p>?
If so, no.

 

[Jeff Thies]

Just a quick question. With an image you can code them to be inline. Is

p { display: inline; }

Possible caveats. I believe some/most versions of Opera will not
recognize inlining a block level element.

Also it's bad structure as blocks are not inline, although the reverse
can be true. Not being sure what you are doing, you may wish to look
into float: left (with a width set).

Jeff

 

[rf]

Possible caveats. I believe some/most versions of Opera will not
recognize inlining a block level element.

My version (6.05) is quite happy inlineing p elements.

It'll even handle * {display: inline;}

Also it's bad structure as blocks are not inline,

Er, if an element is given display: inline; then it is no longer a block.

although the reverse
can be true.

Are you getting confused with "inline elements may not contain block level
elements but block level elements can contain either kind"?

Not being sure what you are doing, you may wish to look
into float: left (with a width set).

or even a <span>.

 

[Jeff Thies]

My version (6.05) is quite happy inlineing p elements.

It'll even handle * {display: inline;}

Hmmm. Looks like I'm out of date.

Some time ago I posted this:

<URL: http://thelimit.com/test/test_width.htm >

Now, I was told that the two inline span examples did not work in Opera
(acted like divs with the corresponding linebreaks)

But I see now that my Opera 7.3 (foolish me didn't have Opera then)
works as I expected. Perhaps this is an Opera 5 issue.

Er, if an element is given display: inline; then it is no longer a block.

Well, I thought that this was wrong, and this is what I meant:

p{display: inline; height: 100px; margin-top: 20px}

Having block level properties for a block element that have been inlined.

oddly, I know this is legal:

span{margin: 20px}

(block level properties for an inline)
the top and bottom margins are thrown away but are not "illegal".

Sometime my head just spins hacking throug CSS!

Jeff

 

[Mark Parnell]

<URL: http://thelimit.com/test/test_width.htm >
Perhaps this is an Opera 5 issue.

Works fine here in Opera 5.12.

 

[rf]

Jeff Thies wrote

rf wrote:
Well, I thought that this was wrong, and this is what I meant:

p{display: inline; height: 100px; margin-top: 20px}

Having block level properties for a block element that have been inlined.

oddly, I know this is legal:

Correct, it's legal but section 10.6.1 of the CSS 2.1 spec states that the
height doesn't apply. Further (this particular section is not very well
written) vertical padding, border and margin do not affect the spacing of
the element, only the line-height is used.

A telling test is to tip this into your browser:

span {border: solid 1px green; padding: 4px;}

<span>a lot of text to make the span flow onto more than one line on the
canvas and thus generate two or more line boxes</span>

http://users.bigpond.net.au/rf/t.htm

(I've thrown in margin: 20px; here to show what happens with the margins.
Not quite what you expected ?)

You will see that each of the line boxes (refer to section 9.4.2) is one
line-height high plus 10 (in this case, 8 for padding and two for the
borders) pixels however the line box vertical *spacing* or *layout* is one
line-height, the height of the content.

The line boxes actually overlap and their borders end up intertwined. They
even escape outside that enclosing red div

This is why if you throw a margin and some padding into an <a> to make it
look like a pretty button you usually have to fiddle with line-height as
well. Of course you must specify line-height in ems or things will screw up
when your viewer changes her font size.

The top and bottom margins are "ignored" in that they only ever affect
positioning of elements and vertical position for inline elements is based
on line-height only. It's probably kept floating around in the DOM somewhere
but it doesn't do anything.

Sometime my head just spins hacking throug CSS!

You have to read the spec. Then you have to read it again. Then you have to
have somebody explain each bit to you. Then you have to go away for a quiet
week at the snow/beach/pub to get ready for another read of the spec.

After a year or two a couple of facts will sink in. Most notably the fact
that the spec itself is not very well written. Vital bits (like what happens
to the top margin of an inline element) are sort of glossed over or
mentioned in passing or, more often, implied by the *lack* of comment about
them. This probably stems from the fact that the spec was originally written
partly to describe what the then current browsers actually did. It also
causes lots of arguments in usenet on the correct interpretation of a
particular paragraph

 

[Jeff Thies]

Correct, it's legal but section 10.6.1 of the CSS 2.1 spec states that the
height doesn't apply. Further (this particular section is not very well
written) vertical padding

border and margin do not affect the spacing of
the element, only the line-height is used.

A telling test is to tip this into your browser:

span {border: solid 1px green; padding: 4px;}

<span>a lot of text to make the span flow onto more than one line on the
canvas and thus generate two or more line boxes</span>

http://users.bigpond.net.au/rf/t.htm

I've fiddled with this a bit, and read your post a few times.

Unexpectedly, I completely understand it! I realize this took a while to
compose and I'd like to thank you for your time.

You have to read the spec. Then you have to read it again. Then you have to
have somebody explain each bit to you. Then you have to go away for a quiet
week at the snow/beach/pub to get ready for another read of the spec.

After a year or two a couple of facts will sink in. Most notably the fact
that the spec itself is not very well written.
Vital bits (like what happens
to the top margin of an inline element) are sort of glossed over or
mentioned in passing or, more often, implied by the *lack* of comment about
them. This probably stems from the fact that the spec was originally written
partly to describe what the then current browsers actually did.

That adds up to the worst of both worlds. If they were written strictly
as documentation, then there would be someone who would maintain them
and rewrite the parts that are ambiguous. Realistically, I can't imagine
anyone *wanting* to rewrite them!

Cheers,
Jeff

 

[Jukka K. Korpela]

Er, if an element is given display: inline; then it is no longer a
block.

Yes and no.

It is no longer a block in CSS terms. Thus, for example, properties that
apply to block elements only won't apply to it.

It is still a block in HTML terms if the element name is one that is
defined to be a block by HTML specifications. A <p> element cannot appear
inside a <span> element for example, without violating HTML specs, no
matter what you say in a style sheet.

It is essential to understand that the "block" concept in HTML is
many-sided (and not very rigorously defined in all respects), and only
one set of the aspects is relevant in CSS, and changeable in CSS.
It might have been better if different terms were used.

 

[Jeff Thies]

Yes and no.

It is no longer a block in CSS terms. Thus, for example, properties that
apply to block elements only won't apply to it.

It is still a block in HTML terms if the element name is one that is
defined to be a block by HTML specifications. A <p> element cannot appear
inside a <span> element for example, without violating HTML specs, no
matter what you say in a style sheet.

Let say we have this:

div{display : inline}

Can that div then contain block level element like "p"?

Can you set vertical margin/padding? (You just answered this for inline
native)

What I would like more than anything is this:

<div style="display: inline; width: 200px">
<h3>product 1</h3>
<img ...><p>...</p>
</div>

<div style="display: inline; width: 200px">
<h3>product 2</h3>
<img ...><p>...</p>
</div>

I've thought that those answers were: No, no and no.

Inline elements always wrap back to the left margin, unlike float: left
which is more like floatart_way_left!

Jeff

 

[Mark Parnell]

Let say we have this:

div{display : inline}

Can that div then contain block level element like "p"?

Yes, because according to HTML, it is a block-level element.

 

[rf]

Jeff Thies wrote

Let say we have this:

div{display : inline}

Can that div then contain block level element like "p"?

Can you set vertical margin/padding? (You just answered this for inline
native)

What I would like more than anything is this:

<div style="display: inline; width: 200px">
<h3>product 1</h3>
<img ...><p>...</p>
</div>

<div style="display: inline; width: 200px">
<h3>product 2</h3>
<img ...><p>...</p>
</div>

I've thought that those answers were: No, no and no.

Inline elements always wrap back to the left margin, unlike float: left
which is more like floatart_way_left!

Hmmm. You are missing the point.

It may be legal to use

<div style="display: inline; width: 200px">
<h3>product 1</h3>
<img ...><p>...</p>
</div>

but it simply does not make any sense. It's like putting your wallet inside
your ten dollar note. It just does not happen.

Block level elements and inline elements are subject to two very different
layout algorithms. If you put a block level element inside an inline element
(by whatever method, legal or not) you destroy the algorithms. The browser
is free to error correct (*) your document as it sees fit. The result will
usually be dramatically different to what you would expect.

(*) This is not error correction at the HTML level, it is at the DOM level,
the document tree, after all the HTML and CSS has been parsed.

Remember
http://users.bigpond.net.au/rf/t.htm ?

Apply display: inline to that outer red bordered div and we get

http://users.bigpond.net.au/rf/t1.htm

Not a pretty sight.

Before proceeding any further you really *must* read chapter 9 of the spec,
Visual formatting model.
http://www.w3.org/TR/CSS21/visuren.html

Pay particular attention to the concept of box generation, and the fact that
inline elements do *not* generate boxes of content, block boxes, but rather
generate inline boxes, entirely different things. Don't forget to trip over
the rather strange "anonymous inline box".

 

[Spartanicus]

What I would like more than anything is this:

<div style="display: inline; width: 200px">
<h3>product 1</h3>
<img ...><p>...</p>
</div>

<div style="display: inline-block; width: 200px">
<h3>product 1</h3>
<img ...><p>...</p>
</div>

inline-block is a nasty omission from CSS 2.0, added in 2.1 and
currently supported by Opera.

Inline elements always wrap back to the left margin, unlike float: left
which is more like floatart_way_left!

I've no idea what that refers to.

 

[Toby Inkster]

Let say we have this:
div{display : inline}
Can that div then contain block level element like "p"?

Yes of course. <div><p></p></div> is valid HTML and no amount of CSS
tricks will ever change that.

 

[Jeff Thies]

<div style="display: inline-block; width: 200px">
<h3>product 1</h3>
<img ...><p>...</p>
</div>

inline-block is a nasty omission from CSS 2.0, added in 2.1 and
currently supported by Opera.

Awesome! Now to wait for NS and IE.

I've no idea what that refers to.

Hard for me to put into words

<div height: 200px; width: 400px; float: left>.</div>
<div height: 100px; width: 400px; float: left>.</div>
<div height: 100px; width: 400px; float: left>.</div>

on a 900px container the third div wouldn't float to the left margin but
stick just after the first. That makes for some ugly layouts!

Cheers,
Jeff

 

[Spartanicus]

Hard for me to put into words

<div height: 200px; width: 400px; float: left>.</div>
<div height: 100px; width: 400px; float: left>.</div>
<div height: 100px; width: 400px; float: left>.</div>

on a 900px container the third div wouldn't float to the left margin but
stick just after the first.

Apart from the obvious errors in the above code, of course it does. It's
doing exactly what you asked it to do. It may not be what you want it to
do, but I suspect that this is due to your flawed understanding of
floats.

Post a url plus a description of what you are trying to accomplish.

 

[Arondelle]

Apart from the obvious errors in the above code, of course it does. It's
doing exactly what you asked it to do. It may not be what you want it to
do, but I suspect that this is due to your flawed understanding of
floats.

Post a url plus a description of what you are trying to accomplish.

It looks like this code wants to be a pseudo-table of 2 columns with the
right-hand column split into 2 rows.

What are the errors in this code, please? Newbies want to know.

I just built a sucessful CSS "table" of 2 columns and five rows (and
made it "squishable"!) by floating the first <div> in each row, and not
the second. (http://www.red-death.com/~arondelle/misc/miscindex.html)

Would getting the third <div> to line up under the second one (thus
creating the split column) be produced by placing #2 and #3 in another
nested container? Or, more easily, by not floating either #2 or #3?

Arondelle

 

[Mitja]

It looks like this code wants to be a pseudo-table of 2
columns with the right-hand column split into 2 rows.

What are the errors in this code, please? Newbies want
to know.

They should know without being told. Look harder.