By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,625 Members | 2,235 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,625 IT Pros & Developers. It's quick & easy.

text wrap around image: how can we do it with css?

P: n/a
Hello. I have been using word processor like OOO for nearly 10 years and
such layout is very usual to me:

gopher://sdf.lonestar.org/I/users/we..._correctly.png

but I found it's very difficult to achieve the same layout with HTML/css.
The best result I can achieve is like this:

gopher://sdf.lonestar.org/h/users/weiwu/Expectation.xml

As you can see in Firefox, the list items which wraps around the image has
wrong indent. The list bullet is displayed on-top-of the image, which is
wrong.

I discovered the margin style (which should be what sets list item
indent) do not work when there is an image floated on the left side.

I knew the problem I got must be a very common problem so there must
already be solutions on the Internet, but I cannot figure out what proper
keyword to use to search for solutions, hance this post.

Thanks in advance!
Jan 20 '07 #1
Share this Question
Share on Google+
14 Replies


P: n/a
Rik
Zhang Weiwu wrote:
Hello. I have been using word processor like OOO for nearly 10 years
and such layout is very usual to me:

gopher://sdf.lonestar.org/I/users/we..._correctly.png

but I found it's very difficult to achieve the same layout with
HTML/css. The best result I can achieve is like this:

gopher://sdf.lonestar.org/h/users/weiwu/Expectation.xml

As you can see in Firefox, the list items which wraps around the
image has wrong indent. The list bullet is displayed on-top-of the
image, which is wrong.

I discovered the margin style (which should be what sets list item
indent) do not work when there is an image floated on the left side.
Then use padding instead of margin to indent list-items, and use
list-style-position: inside;
--
Rik Wasmus
Jan 20 '07 #2

P: n/a
On 2007-01-20, Zhang Weiwu <zh********@realss.comwrote:
Hello. I have been using word processor like OOO for nearly 10 years and
such layout is very usual to me:

gopher://sdf.lonestar.org/I/users/we..._correctly.png

but I found it's very difficult to achieve the same layout with HTML/css.
The best result I can achieve is like this:

gopher://sdf.lonestar.org/h/users/weiwu/Expectation.xml

As you can see in Firefox, the list items which wraps around the image has
wrong indent. The list bullet is displayed on-top-of the image, which is
wrong.

I discovered the margin style (which should be what sets list item
indent) do not work when there is an image floated on the left side.
It works for me in Firefox to put a left margin on <li>. In any case a
right margin on the image might be better instead, so the <li>s that fit
below it don't get an extra left indent.

But there is some question here whether what Firefox is doing is
actually correct. Each <liis a block box whose inline content is
offset to flow around the float. Should the list-item marker follow the
inline content or the <liblock box? We might expect the markers right
over on the left positioned somewhere near the left edges of the <li>
block boxes which are under the image.

Indeed that's where the CSS 2.1 spec implies they should be since it
says that the list-item-position property specifies "position with
respect to the principal [i.e. block] box". So whether the markers are
inside or outside, you'd expect them to be somewhere near the principal
box left edge, not near the left edge of the inline box inside it (which
in this case has moved right because of the float).
I knew the problem I got must be a very common problem so there must
already be solutions on the Internet, but I cannot figure out what proper
keyword to use to search for solutions, hance this post.
This is a real problem. list-style-position: inside should work as the
the poster suggested, since in that case the markers are inline boxes
and should go the right of the float. But you might not like the way
<li>s that span multiple lines come out.
Jan 20 '07 #3

P: n/a
On 2007-01-20, Ben C <sp******@spam.eggswrote:
[snip]
Indeed that's where the CSS 2.1 spec implies they should be since it
says that the list-item-position property specifies "position with
respect to the principal [i.e. block] box". So whether the markers are
inside or outside, you'd expect them to be somewhere near the principal
box left edge, not near the left edge of the inline box inside it (which
in this case has moved right because of the float).
Sorry, that was rather misleading and I should put it right. If the
marker position is "inside", it's positioned as if it were an inline box
first thing in the <li>'s block box (aka "principal box").

The situation looks like this, where "F" is the float, and L and R are
the left and right edges of the list item's block box:

LFFFFFFFFF R

An outside marker (m) you would expect to be positioned somewhere like
this (exactly where is up to the UA):

m LFFFFFFFFFF R

off the left edge of the <li>'s block box.

i.e. not like this:

LFFFFFFFFmF R

which is roughly where Firefox seems to put it-- offset to the left of
the inline box containing the <li>'s content.

If the marker position is inside, it should reliably look like this:

LFFFFFFFFFF m R

since the marker is inline and therefore moves right of the float just
like any inline box.
Jan 20 '07 #4

P: n/a
Scripsit Zhang Weiwu:
gopher://sdf.lonestar.org/I/users/we..._correctly.png
Please use http URLs. If you want to author for the WWW, use an http server.

I think it was about five years ago I last saw discussions about Gopher
still being alive. Nobody had seen a living Gopher server.

IE 7 dropped support to the gopher: protocol.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jan 20 '07 #5

P: n/a
In article <4F****************@reader1.news.saunalahti.fi>,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
Scripsit Zhang Weiwu:
gopher://sdf.lonestar.org/I/users/we..._correctly.png

Please use http URLs. If you want to author for the WWW, use an http server.

I think it was about five years ago I last saw discussions about Gopher
still being alive. Nobody had seen a living Gopher server.

IE 7 dropped support to the gopher: protocol.
I was surprised... but delighted when my Mozilla browser dusted
itself off and fired up and opened it.

--
dorayme
Jan 21 '07 #6

P: n/a
于 Sat, 20 Jan 2007 15:02:07 -0600,Ben C写到:
On 2007-01-20, Ben C <sp******@spam.eggswrote:
[snip]
The situation looks like this, where "F" is the float, and L and R are
the left and right edges of the list item's block box:

LFFFFFFFFF R

An outside marker (m) you would expect to be positioned somewhere like
this (exactly where is up to the UA):

m LFFFFFFFFFF R

off the left edge of the <li>'s block box.

i.e. not like this:

LFFFFFFFFmF R

which is roughly where Firefox seems to put it-- offset to the left of
the inline box containing the <li>'s content.

If the marker position is inside, it should reliably look like this:

LFFFFFFFFFF m R

since the marker is inline and therefore moves right of the float just
like any inline box.
Your explaination is very prompt and clear. Thanks for helping me with
this issue.

It seems impossible in Firefox to layout the content exactly the way my
word processor has done. If I used 'inside' position the list item line
that wraps many lines looks strange, but acceptable to me.

Thanks a lot for explain this to me and other people on the group.
Jan 21 '07 #7

P: n/a
[snip: Ben's explaination of boxing model and how float works ... ]

If all what you have described is true (obviously it is), then we will
again have problem with <blockquote>

If I float an image to the left side, and explain this image with normal
text flowing around this image, and during my text explanation I need to
use blockquote, then it doesn't work.

+-----------+ <pBlah Blah</p>
| | <blockquote><pQuote text here blach</p>
| | <p>Again quote text</p>
+-----------+ <p>again, blach</p>
<p>and quotes</p>
</blockquote>

For the above case, the first 3 paragrahs in the blockquote might get
incorrect left-side padding/margin, but the last paragraph in the
blockquote is correctly indented.

Is there a way to workaround this? (except floating image to the right
side instead)
Jan 21 '07 #8

P: n/a
On 2007-01-21, Zhang Weiwu <zh********@realss.comwrote:
[snip: Ben's explaination of boxing model and how float works ... ]

If all what you have described is true (obviously it is), then we will
again have problem with <blockquote>
Yes, what happens is the blockquote's block box's left edge is all the
way to the left, under the image, and that's where its margin goes. It's
only the words inside the blockquote (in this case inside <pelements,
which make more block boxes, also stacking up against the left of their
container-- the blockquote) that are moved right to avoid the float.
If I float an image to the left side, and explain this image with normal
text flowing around this image, and during my text explanation I need to
use blockquote, then it doesn't work.

+-----------+ <pBlah Blah</p>
| | <blockquote><pQuote text here blach</p>
| | <p>Again quote text</p>
+-----------+ <p>again, blach</p>
<p>and quotes</p>
</blockquote>

For the above case, the first 3 paragrahs in the blockquote might get
incorrect left-side padding/margin, but the last paragraph in the
blockquote is correctly indented.
Exactly.
Is there a way to workaround this? (except floating image to the right
side instead)
So long as the left margin you want on the blockquote is known to be
smaller than the width of the float, set the same amount also as right
margin on the float, and it should come out all right, provided that the
blockquote and the <p>s have transparent backgrounds.
Jan 21 '07 #9

P: n/a
Scripsit Ben C:
Yes, what happens is the blockquote's block box's left edge is all the
way to the left, under the image, and that's where its margin goes.
It's only the words inside the blockquote - - that are moved right to
avoid the float.
I think you meant "lines", not "words".
>Is there a way to workaround this? (except floating image to the
right side instead)

So long as the left margin you want on the blockquote is known to be
smaller than the width of the float, set the same amount also as right
margin on the float, and it should come out all right, provided that
the blockquote and the <p>s have transparent backgrounds.
But that would create a uniform right margin for the floated image, so that
<pelements and <blockquoteelements would still be lined up on the left,
instead of any visible indentation of <blockquote>.

I don't see any general workaround, but in many special cases, it might be
feasible to use

blockquote { float: left; }

(You'd need to consider what happens in different situations, especially
when the canvas width varies.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jan 21 '07 #10

P: n/a
On 2007-01-21, Jukka K. Korpela <jk******@cs.tut.fiwrote:
Scripsit Ben C:
>Yes, what happens is the blockquote's block box's left edge is all the
way to the left, under the image, and that's where its margin goes.
It's only the words inside the blockquote - - that are moved right to
avoid the float.

I think you meant "lines", not "words".
Strictly "inline boxes" or "line boxes". Either "words" or "lines" will
do I think though.
>>Is there a way to workaround this? (except floating image to the
right side instead)

So long as the left margin you want on the blockquote is known to be
smaller than the width of the float, set the same amount also as right
margin on the float, and it should come out all right, provided that
the blockquote and the <p>s have transparent backgrounds.

But that would create a uniform right margin for the floated image, so that
<pelements and <blockquoteelements would still be lined up on the left,
instead of any visible indentation of <blockquote>.
Yes it would. You're right this is a problem. A solution would be to
increase the left margin of blockquote by the width of the image. But
that wouldn't work for the part of the blockquote that flows below the
image (see below).
I don't see any general workaround, but in many special cases, it might be
feasible to use

blockquote { float: left; }

(You'd need to consider what happens in different situations, especially
when the canvas width varies.)
I thought of that too, but another problem there is that in the OP's
example the blockquote finishes after the image, and its contents are
expected to flow back to the left of the page under the image.
Jan 21 '07 #11

P: n/a
于 Sun, 21 Jan 2007 07:58:21 -0600,Ben C写到:
On 2007-01-21, Jukka K. Korpela <jk******@cs.tut.fiwrote:
>Scripsit Ben C:
[sinp]
>I don't see any general workaround, but in many special cases, it might be
feasible to use

blockquote { float: left; }

(You'd need to consider what happens in different situations, especially
when the canvas width varies.)

I thought of that too, but another problem there is that in the OP's
example the blockquote finishes after the image, and its contents are
expected to flow back to the left of the page under the image.
So, if this problem is basically not possible to solve completely using a
CSS method, I would try to avoid this kind of layout (e.g. float the image
to the right rather then to the left) as practical solution. But again
wouldn't this raise a question in W3C itself? Wouldn't be there any W3C
member propose something to adjust this? (a new "display: block-inline;"
concept?)

I suddenly realized why all the newspaper website float their news
pictures to the RIGHT when they often float image to the LEFT on printed
newspapers.
Jan 22 '07 #12

P: n/a
On 2007-01-22, Zhang Weiwu <zh********@realss.comwrote:
? Sun, 21 Jan 2007 07:58:21 -0600?Ben C???
>On 2007-01-21, Jukka K. Korpela <jk******@cs.tut.fiwrote:
>>Scripsit Ben C:
[sinp]
>>I don't see any general workaround, but in many special cases, it might be
feasible to use

blockquote { float: left; }

(You'd need to consider what happens in different situations, especially
when the canvas width varies.)

I thought of that too, but another problem there is that in the OP's
example the blockquote finishes after the image, and its contents are
expected to flow back to the left of the page under the image.

So, if this problem is basically not possible to solve completely using a
CSS method, I would try to avoid this kind of layout (e.g. float the image
to the right rather then to the left) as practical solution. But again
wouldn't this raise a question in W3C itself? Wouldn't be there any W3C
member propose something to adjust this? (a new "display: block-inline;"
concept?)
There is already "display: inline-block". An inline-block would flow to
the right of a left float, and its left margin would be to the right of
the float.

But its contents wouldn't flow underneath the float, it would remain as
a square block. The effect would be similar to Jukka's suggestion of
using float:left on the blockquote.

I think you're right that this problem is a limitation of the CSS
box-model.

Could it have been done better and with how much additional complexity?
An interesting question. One problem is that you often want the border
of a block box under a float to be in its usual place (all the way over
to the left, as if the float weren't there). The margin and padding go
either side of the border and it would be unreasonable to change that.

As you suggest, some new display type might be possible, for a kind of
inline block box which split vertically around floats. Not impossible,
but it would make the specification and implementation more complicated.
I suddenly realized why all the newspaper website float their news
pictures to the RIGHT when they often float image to the LEFT on
printed newspapers.
You also can't do columns in CSS. I mean proper columns, like in a
printed newspaper, with the browser working out at what point text
should start filling the next column.

Personally I'm in favour of keeping CSS simple though because the box
model already takes some time and effort to understand, and is also
apparently already difficult to implement judging by the relatively
large number of non-conformances we see even in non-Microsoft browsers.
If you make something too difficult to understand the problems that
causes can outweigh the advantages-- C++ might be considered an example
of that (a design that was also encumbered by a requirement for
historical compatibility).
Jan 22 '07 #13

P: n/a
于 Mon, 22 Jan 2007 04:56:04 -0600,Ben C写到:
[snip]
>I suddenly realized why all the newspaper website float their news
pictures to the RIGHT when they often float image to the LEFT on
printed newspapers.

You also can't do columns in CSS. I mean proper columns, like in a
printed newspaper, with the browser working out at what point text
should start filling the next column.

Personally I'm in favour of keeping CSS simple though because the box
model already takes some time and effort to understand, and is also
apparently already difficult to implement judging by the relatively
large number of non-conformances we see even in non-Microsoft browsers.
If you make something too difficult to understand the problems that
causes can outweigh the advantages-- C++ might be considered an example
of that (a design that was also encumbered by a requirement for
historical compatibility).
I can fully understand your point of keeing CSS simple would be much
easier to implement, but I have a second non-technical worry. I suggest CSS
to be as compete as possible, define a lot of possibilities and even for
complicated issue like text-flow-through-columns. Reasons:
as we have saw in history, if standard didn't say how it should be done,
each vender might produce there own implementation and ends up nothing
compatible.

then some people might say it's good each vendor work on their own and
later let them compete for the best solution, and the standard group will
have a chance to adopt the best solution. The fact is they don't have such
chance. People will get the best solution from competition if the
competition of browser is a technical competition, but it's not, it's a
market competition. Suppose IE have a solution to the multi-column problem
and my current problem, but implemented it in a bad way, Firefox
implemented in a different but much better way, the result is likely
standard group take IE solution as standard because otherwise they are
making standards without vendor (=market) support. If CSS standard
group has a solution, that is a good reason to suggest other vendor start
on the right path, ah, yes, IE will still act on its own but at least they
are doing things on their own way with a little bit of pressure.

I am a bit surprised to find how much w3 adopt new ideas from IE even when
they didn't plan it that way. box-sizing is the case, writing-mode is
another. (writing-mode is not bad, I just thought maybe w3 was trying to
solve this problem start from DIR property).

P.S. other missing feature of CSS: no style setting for Asian style
emphasizes (there are two styles: one single big dot underneath each
ideaograph and one single circle underneath each ideograph), no style
setting for strong emphasize for ideographs (one circle around each
ideograph, sometimes require the circle to be in a different color or
shifted lower-left or lower-right a bit), no style for per-ideograph
background (this is sometimes useful for Asian users, to be able to set
same background for each ideograph without having to enclose each ideograph
with <span>). I didn't mention there is a font-varient in Asian that
horizental strokes can lean upward, right? These features better make
their ways into CSS and let Firefox go ahead of IE to implement them. IE
is ABSOLUTELY NOT motivated to implement these features because they
already took asian market, there is nothing to motivate improvements.
(while in German 1/3 people use Firefox, in China should less then 1%)
Jan 23 '07 #14

P: n/a
On 2007-01-23, Zhang Weiwu <zh********@realss.comwrote:
? Mon, 22 Jan 2007 04:56:04 -0600?Ben C???
[snip]
>>I suddenly realized why all the newspaper website float their news
pictures to the RIGHT when they often float image to the LEFT on
printed newspapers.

You also can't do columns in CSS. I mean proper columns, like in a
printed newspaper, with the browser working out at what point text
should start filling the next column.

Personally I'm in favour of keeping CSS simple though because the box
model already takes some time and effort to understand, and is also
apparently already difficult to implement judging by the relatively
large number of non-conformances we see even in non-Microsoft browsers.
If you make something too difficult to understand the problems that
causes can outweigh the advantages-- C++ might be considered an example
of that (a design that was also encumbered by a requirement for
historical compatibility).

I can fully understand your point of keeing CSS simple would be much
easier to implement, but I have a second non-technical worry. I suggest CSS
to be as compete as possible, define a lot of possibilities and even for
complicated issue like text-flow-through-columns. Reasons:
as we have saw in history, if standard didn't say how it should be done,
each vender might produce there own implementation and ends up nothing
compatible.
Yes, good point.

[snip]
P.S. other missing feature of CSS: no style setting for Asian style
emphasizes (there are two styles: one single big dot underneath each
ideaograph and one single circle underneath each ideograph), no style
setting for strong emphasize for ideographs (one circle around each
ideograph, sometimes require the circle to be in a different color or
shifted lower-left or lower-right a bit), no style for per-ideograph
background (this is sometimes useful for Asian users, to be able to set
same background for each ideograph without having to enclose each ideograph
with <span>).
Do you mean set all occurrences of a given ideograph some colour
(without having to put a span around each occurrence)?
I didn't mention there is a font-varient in Asian that horizental
strokes can lean upward, right?
Wouldn't this last one come down to using a font that supported it?
These features better make their ways into CSS and let Firefox go
ahead of IE to implement them. IE is ABSOLUTELY NOT motivated to
implement these features because they already took asian market, there
is nothing to motivate improvements. (while in German 1/3 people use
Firefox, in China should less then 1%)
What about vertical text-flow? CSS supports rtl and bidi, but not for
top-to-bottom right-to-left.
Jan 23 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.