lining up photo's in css columns

On Thu, 16 Jul 2009 16:40:30 +1000
dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

[snip]

IE6 and 7 do not give good support for this, so you might be
doing various tricky things to make IE play along.

IE6/7 is easy to support compared to SeaMonkey or older mozilla
versions. With SeaMonkey version 2 this may change, and be able to drop
the extra markup and mozilla extensions.

[snip]

Got a URL of a page of pic/caption boxes of varying amounts of
text that have no problems on all major browsers and that adjust
to use available space in efficient manner?

http://bootnic.bounceme.net/TemporaryPages/inlineBlock.php



--
BootNic Thu Jul 16, 2009 11:22 am
"There is a wicked pretense that one has been informed. But no such
thing has truly occurred! A mere slogan, an empty litany. No
arguments are heard, no evidence is weighed. It isn't news at all,
only a source of amusement for idlers."
*Gibson-Sterling, The Difference Engine*

⁕ 361 days remaining

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkpfRc0ACgkQmo2774GZ7qk0tgCgohaH1w2joV 5vhTphKVjg00Sj
zVEAoINJLclg7pH53hpGzoQejNE+R2A+
=5WW2
-----END PGP SIGNATURE-----

BootNic wrote:

On Thu, 16 Jul 2009 16:40:30 +1000
dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

[snip]

IE6 and 7 do not give good support for this, so you might be
doing various tricky things to make IE play along.

IE6/7 is easy to support compared to SeaMonkey or older mozilla
versions. With SeaMonkey version 2 this may change, and be able to drop
the extra markup and mozilla extensions.

[snip]

Got a URL of a page of pic/caption boxes of varying amounts of
text that have no problems on all major browsers and that adjust
to use available space in efficient manner?

http://bootnic.bounceme.net/TemporaryPages/inlineBlock.php



I must say that is a creative use of text-align: justify to even the

margins between inline-blocks. Nicely done.

Jeff

In article <20090716112248.4cb21e9b (AT) bootnic (DOT) eternal-september.org>,
BootNic <bootnic.bounce (AT) gmail (DOT) com> wrote:

On Thu, 16 Jul 2009 16:40:30 +1000
dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

....

Got a URL of a page of pic/caption boxes of varying amounts of
text that have no problems on all major browsers and that adjust
to use available space in efficient manner?

http://bootnic.bounceme.net/TemporaryPages/inlineBlock.php

Ah, yes, I recall seeing this before.

Would it not be nice to have more intelligent css tools to solve various
box packing problems? We all seem destined to fiddling and predicting
and compromising. Perhaps that is part of the fun!

The float rules, to get on to a subject not bang on your URL but
generally behind some of the problems in this thread, were probably not
designed with full page layout questions with lots and lots of floats in
mind. Be nice to have an extra float rule that lets the float have x-ray
eyes to avoid dumbly snagging. If a left float could see a space for
itself to the left of what is threatening to snag it, it makes like a
ghost and passes silently through the snag to fit in to the left.

--
dorayme

dorayme wrote:

In article <20090716112248.4cb21e9b (AT) bootnic (DOT) eternal-september.org>,
BootNic <bootnic.bounce (AT) gmail (DOT) com> wrote:

On Thu, 16 Jul 2009 16:40:30 +1000
dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

...
Got a URL of a page of pic/caption boxes of varying amounts of
text that have no problems on all major browsers and that adjust
to use available space in efficient manner?
http://bootnic.bounceme.net/TemporaryPages/inlineBlock.php

Ah, yes, I recall seeing this before.

Would it not be nice to have more intelligent css tools to solve various
box packing problems? We all seem destined to fiddling and predicting
and compromising. Perhaps that is part of the fun!

The float rules, to get on to a subject not bang on your URL but
generally behind some of the problems in this thread, were probably not
designed with full page layout questions with lots and lots of floats in
mind. Be nice to have an extra float rule that lets the float have x-ray
eyes to avoid dumbly snagging. If a left float could see a space for
itself to the left of what is threatening to snag it, it makes like a
ghost and passes silently through the snag to fit in to the left.

Or you can just use inline-block, and have the advantage of aligning
top, middle or bottom. And justify which I'm pretty sure floats can't
do. All you need is two lines of conditional comments for old IE and one
for moz-inline-block. And this has the advantage of being unneeded when
when these aging browsers fade away.

Inline block is a better answer than floats for this kind of work.
With the old floats I would either use clearing divs after fixed row
count, specify a height greater than to be expected, or use js to pad
out the boxes to the same height. None of which is needed with inline-block.

We really are at the dawn of being able to do very creative design
without resorting to convoluted html. In fact using very plain html. I
fail to see why so many are falling back on old "solutions".

Jeff
>

jeff <jeff_thies (AT) att (DOT) net> wrote:

dorayme wrote:
In article <20090716112248.4cb21e9b (AT) bootnic (DOT) eternal-september.org>,
BootNic <bootnic.bounce (AT) gmail (DOT) com> wrote:

On Thu, 16 Jul 2009 16:40:30 +1000
dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

...
Got a URL of a page of pic/caption boxes of varying amounts of
text that have no problems on all major browsers and that adjust
to use available space in efficient manner?
http://bootnic.bounceme.net/TemporaryPages/inlineBlock.php

Ah, yes, I recall seeing this before.

Would it not be nice to have more intelligent css tools to solve various
box packing problems? We all seem destined to fiddling and predicting
and compromising. Perhaps that is part of the fun!

The float rules, to get on to a subject not bang on your URL but
generally behind some of the problems in this thread, were probably not
designed with full page layout questions with lots and lots of floats in
mind. Be nice to have an extra float rule that lets the float have x-ray
eyes to avoid dumbly snagging. If a left float could see a space for
itself to the left of what is threatening to snag it, it makes like a
ghost and passes silently through the snag to fit in to the left.

Or you can just use inline-block, and have the advantage of aligning
top, middle or bottom. And justify which I'm pretty sure floats can't
do. All you need is two lines of conditional comments for old IE and one
for moz-inline-block. And this has the advantage of being unneeded when
when these aging browsers fade away.

Inline block is a better answer than floats for this kind of work.
With the old floats I would either use clearing divs after fixed row
count, specify a height greater than to be expected, or use js to pad
out the boxes to the same height. None of which is needed with inline-block.

We really are at the dawn of being able to do very creative design
without resorting to convoluted html. In fact using very plain html. I
fail to see why so many are falling back on old "solutions".

Jeff

This inline block method looks interesting. I was playing around with
floated fixed-height divs which seemed to work alright but of course you
need to predict the maximum amount of text.

I tried to convert it to the inline block method. It works with Mac
Safari 3, Firefox and Opera, but IE 6 and 7 don't like it. I tried to
adapt some conditional styles from dorayme's site, but I don't really
know what I'm doing! I'm limited to testing through IE NetRenderer. Any
pointers on how to fix it in IE?

Original fixed-height floated divs here:
http://tinyurl.com/nwj6er

Adapted to inline block method here:
http://tinyurl.com/ngpkw5

(some text and thumbnails taken from the OP's site for testing)

In article <1j37acf.g5jfvh18y7lw2N%j1 (AT) macunlimited (DOT) net>,
j1 (AT) macunlimited (DOT) net (j) wrote:

Original fixed-height floated divs here:
http://tinyurl.com/nwj6er

Adapted to inline block method here:
http://tinyurl.com/ngpkw5

Yes, clearly the inline method is far superior in that it does not
impose the height of the largest pic/caption box on all of them.

btw, in your float example, there is another very important factor that
you failed to take sufficient account for and that is use text size. You
eyesight is probably very good! See what happens on text enlargement.
Probably best to specify height in ems if you are going to go the float
way.

If you know the tallest box, and the order in which the thumbs go is not
important you might be in a position to simply not put in a height at
all and avoid the snag on wrap problem by careful organisization of the
order, the tallest boxes last of all...

Come to think of it, even doing this 'intelligent organization' for the
inline block way will solve the packing problem better (the problem
being wasted space)

--
dorayme

dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <1j37acf.g5jfvh18y7lw2N%j1 (AT) macunlimited (DOT) net>,
j1 (AT) macunlimited (DOT) net (j) wrote:

Original fixed-height floated divs here:
http://tinyurl.com/nwj6er

Adapted to inline block method here:
http://tinyurl.com/ngpkw5


Yes, clearly the inline method is far superior in that it does not
impose the height of the largest pic/caption box on all of them.

btw, in your float example, there is another very important factor that
you failed to take sufficient account for and that is use text size. You
eyesight is probably very good! See what happens on text enlargement.
Probably best to specify height in ems if you are going to go the float
way.

I've tried another float method with width and height specified in ems.
Also, I've specified the photo dimensions as a percentage of the
container div.

http://tinyurl.com/nzvr2k

Getting the right proportions of width and height for the photo was done
by trial and error. It creates a zoom effect in Safari. However, I don't
know if specifying image dimensions like this is bad practice.

j wrote:

jeff <jeff_thies (AT) att (DOT) net> wrote:

dorayme wrote:
In article <20090716112248.4cb21e9b (AT) bootnic (DOT) eternal-september.org>,
BootNic <bootnic.bounce (AT) gmail (DOT) com> wrote:

On Thu, 16 Jul 2009 16:40:30 +1000
dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

...
Got a URL of a page of pic/caption boxes of varying amounts of
text that have no problems on all major browsers and that adjust
to use available space in efficient manner?
http://bootnic.bounceme.net/TemporaryPages/inlineBlock.php
Ah, yes, I recall seeing this before.

Would it not be nice to have more intelligent css tools to solve various
box packing problems? We all seem destined to fiddling and predicting
and compromising. Perhaps that is part of the fun!

The float rules, to get on to a subject not bang on your URL but
generally behind some of the problems in this thread, were probably not
designed with full page layout questions with lots and lots of floats in
mind. Be nice to have an extra float rule that lets the float have x-ray
eyes to avoid dumbly snagging. If a left float could see a space for
itself to the left of what is threatening to snag it, it makes like a
ghost and passes silently through the snag to fit in to the left.
Or you can just use inline-block, and have the advantage of aligning
top, middle or bottom. And justify which I'm pretty sure floats can't
do. All you need is two lines of conditional comments for old IE and one
for moz-inline-block. And this has the advantage of being unneeded when
when these aging browsers fade away.

Inline block is a better answer than floats for this kind of work.
With the old floats I would either use clearing divs after fixed row
count, specify a height greater than to be expected, or use js to pad
out the boxes to the same height. None of which is needed with inline-block.

We really are at the dawn of being able to do very creative design
without resorting to convoluted html. In fact using very plain html. I
fail to see why so many are falling back on old "solutions".

Jeff

This inline block method looks interesting. I was playing around with
floated fixed-height divs which seemed to work alright but of course you
need to predict the maximum amount of text.

I tried to convert it to the inline block method. It works with Mac
Safari 3, Firefox and Opera, but IE 6 and 7 don't like it. I tried to
adapt some conditional styles from dorayme's site, but I don't really
know what I'm doing! I'm limited to testing through IE NetRenderer. Any
pointers on how to fix it in IE?

<!--[if IE]>
<style type="text/css" media="screen">
div.landscape {
display:inline-block;
^^^^^^^^^^^^^^^^^^^^^^^^


display: inline;



zoom:1;
}
</style>
<![endif]-->

Original fixed-height floated divs here:
http://tinyurl.com/nwj6er

Adapted to inline block method here:
http://tinyurl.com/ngpkw5

(some text and thumbnails taken from the OP's site for testing)

j wrote:

dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <1j37acf.g5jfvh18y7lw2N%j1 (AT) macunlimited (DOT) net>,
j1 (AT) macunlimited (DOT) net (j) wrote:

Original fixed-height floated divs here:
http://tinyurl.com/nwj6er

Adapted to inline block method here:
http://tinyurl.com/ngpkw5

Yes, clearly the inline method is far superior in that it does not
impose the height of the largest pic/caption box on all of them.

btw, in your float example, there is another very important factor that
you failed to take sufficient account for and that is use text size. You
eyesight is probably very good! See what happens on text enlargement.
Probably best to specify height in ems if you are going to go the float
way.


I've tried another float method with width and height specified in ems.
Also, I've specified the photo dimensions as a percentage of the
container div.

http://tinyurl.com/nzvr2k

Getting the right proportions of width and height for the photo was done
by trial and error. It creates a zoom effect in Safari. However, I don't
know if specifying image dimensions like this is bad practice.

The downside is image degradation. For soft images (like you have)
this won't cause much trouble. Look at it in IE as IE seems to have the
poorest image resizing rendering, Safari, the best.

Jeff

jeff <jeff_thies (AT) att (DOT) net> wrote:

!--[if IE]
style type="text/css" media="screen"
div.landscape {
display:inline-block;
^^^^^^^^^^^^^^^^^^^^^^^^


display: inline;



zoom:1;
}
/style
![endif]--

Thanks. I had to adapt the first line otherwise IE8 breaks completely.

<!--[if lte IE 7]>