table td padding

D

dorayme

....

It is better because it gets you the look you want, it uses the
crucially relevant shrink-to-width of cells *without* this feature being
nullified by interactions with cell widths in different rows. There are
no other rows! And it is less code if you count the elements, the saving
summing to greater and greater economy the more the rows of pics. Plus a
bit more flexibility in that you have more control over spacing between
rows of pictures via CSS.

Nevertheless, it was quite intelligent of you to use tables within a
table. Because the inner table shrinks to width and gets you the look
you want, the cell it is in acts merely as grid space, the latter's size
can happily be left to width itself by both content (the inner table)
and the interactions of rows.

When I suggested getting rid of the inner table, replacing with a div,
we get simpler code but lose the crucial feature of shrink to fit where
it is needed when multi rows are used. A div will (by default) fill its
container, in this case a table cell. If the cell's width is determined
by outside forces like having to line up with other cells in other rows,
this rather buggers things up because you are depending on the divs'
border to roughly respect the aspect ratio of the images! Hence my
suggestion to be rid of multi row tables.

....

If there are a lot of pictures and someone has a big screen, be *nice*
for them to be able to take advantage of it and not have just three
items per row and this fact would not constrain others with smaller
screens. In fact, mobile phone and other small screen users would surely
appreciate seeing one per row - so they scroll vertically (that is
always a given) - no need for horizontal scrolling. This would happen if
you made some compromises but yes, it would be harder to do given your
fancy border requirements. To stop snagging on browser width reduction
would require careful management and dimensioning. And you would not get
*so easily* the rather nice feature you are obviously wanting with
table, the easy vertical aligning.

....
So far as I see it I basically have 2 options:

(1) https://files.nyu.edu/emf202/public/temp/polytima.html

The original one, with tables within tables.

(2) https://files.nyu.edu/emf202/public/temp/polytima2.html (*revised*)

This has a less elaborate visual effect, its code, however, is much
simplified by eliminating <div> altogether. One could argue that the
lesser visual effect is counterbalanced with the simplicity of the code.

Well, if you really want that inner silver line border, you can do the
one table per row option I suggested above (with its code saving
surprisingly enough!). Or you can do what you have done above but run
the pics through a graphics editor and put a thin silver border and
slight grey padding/mounting-board as part of the image. With just these
pics, it would take very little time.
 
N

Neredbojias

I should have said:

You invite your new neat freak neighbors over for dinner and your
house is a mess.

Ah, I see.
I have a five year old (soon to be six), people come over all the
time, and they all know to tread carefully because of trains, planes
and automobiles happening to be directly in the path of where ever
they want to walk.

Yep, I remember those days. Damn clumsy adults always stepping on my
stuff. I had this pink Cracker Jack rabbit named "Travis Newberry"
some fat lady stepped on in her bare feet and cut her toe. My mother
hollered at me but I laughed my ass off, anyway. (-To myself, of
course.)
 
G

GTalbot

With images, unless you set them to display
as block, they are treated like big letters on a line and like letters
on a line, space is reserved for descenders.

<http://dorayme.netweaver.com.au/alt/inlinePicWithDescenderSpace.html>


Dorayme,

In
<http://dorayme.netweaver.com.au/alt/inlinePicWithDescenderSpace.html>
you say

{
If you want an inline image to sit at the base of the descender space,
you can use the CSS style of 'vertical-align: bottom' on the img. As
just above.
}

but it definitely should be vertical-align: text-bottom, not vertical-
align: bottom

vertical-align: bottom will apparently work as expected when line-
height is normal or 1 but not with bigger or smaller line-height.

regards, Gérard
 
D

dorayme

GTalbot said:
In
<http://dorayme.netweaver.com.au/alt/inlinePicWithDescenderSpace.html>
you say
....
vertical-align: bottom will apparently work as expected when line-
height is normal or 1 but not with bigger or smaller line-height.

Gerard, you have the eye of the hawk! Nice point, thanks. If anyone
wanted to be that accurate with image placement, indeed. I have tidied
it up.

And, btw, added a possibly useful extra bit about a related issue.
 
E

Eustace

It is better because it gets you the look you want, it uses the
crucially relevant shrink-to-width of cells *without* this feature being
nullified by interactions with cell widths in different rows. There are
no other rows! And it is less code if you count the elements, the saving
summing to greater and greater economy the more the rows of pics. Plus a
bit more flexibility in that you have more control over spacing between
rows of pictures via CSS.

The problem with this solution is aesthetic: Instead of the images of
the first and the third column being aligned vertically, their middle
lines falls outwards when there is a landscape image in the middle.
Nevertheless, it was quite intelligent of you to use tables within a
table. Because the inner table shrinks to width and gets you the look
you want, the cell it is in acts merely as grid space, the latter's size
can happily be left to width itself by both content (the inner table)
and the interactions of rows.

I have decided to go against programming tradition, putting on the same
line the 3 tags of a single-cell table:

<table><tr><td>
<img src=...
<td><tr><table>

It does not go against the W3C commands, and I consider it an
appropriate exception to the indentation rule: In this particular case
it simplifies reading the code, and I don't think any programmer will
have any difficulty understanding it. It's a pity, though, that we can't
When I suggested getting rid of the inner table, replacing with a div,
we get simpler code but lose the crucial feature of shrink to fit where
it is needed when multi rows are used. A div will (by default) fill its
container, in this case a table cell. If the cell's width is determined
by outside forces like having to line up with other cells in other rows,
this rather buggers things up because you are depending on the divs'
border to roughly respect the aspect ratio of the images! Hence my
suggestion to be rid of multi row tables.

...


If there are a lot of pictures and someone has a big screen, be *nice*
for them to be able to take advantage of it and not have just three
items per row and this fact would not constrain others with smaller
screens. In fact, mobile phone and other small screen users would surely
appreciate seeing one per row - so they scroll vertically (that is
always a given) - no need for horizontal scrolling. This would happen if
you made some compromises but yes, it would be harder to do given your
fancy border requirements. To stop snagging on browser width reduction
would require careful management and dimensioning. And you would not get
*so easily* the rather nice feature you are obviously wanting with
table, the easy vertical aligning.

...

Well, if you really want that inner silver line border, you can do the
one table per row option I suggested above (with its code saving
surprisingly enough!). Or you can do what you have done above but run
the pics through a graphics editor and put a thin silver border and
slight grey padding/mounting-board as part of the image. With just these
pics, it would take very little time.

Thanks again for your help. The notion of a wrapper class that you
suggested in an earlier thread was very useful to me, and I immediately
put it in use in 3 different webpages in different contexts. It is, of
course, analogous to the idea of scope of a variable in programming
languages, but it had not passed my mind that it could be implemented in
html too.

Eustace
 
J

Jonathan N. Little

Not that I agree with some of your design choices, if you dumped the
tables and used inline block you would not "force" 3 images per row but
have the flexibility to serve your gallery to folks with different size
browser windows. Yes, does not work in older browsers, but &deity;! IE6
& & will have to die soon, and SeaMonkey 2.0 with the newer Gecko is
coming soon. Also the page does degrade and still is usable in older
browsers.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<meta http-equiv="content-language" content="en-us">
<title>template</title>

<style type="text/css">
body {
color: #000; background-color: #ccc; margin: 2em 1em 1em 1em;
}
p {
font: bold italic medium "Times New Roman", Times, serif;
text-align: center;
}
h1 { color: #008; text-align: center; }
div.gallery { text-align: center; }
div.gallery div {
display: inline-block; width: 300px; height: 400px;
}
div.gallery div img {
display: block; margin: 0 auto 1em auto; padding: 10px;
border: 10px outset #555; background: #000;
}
</style>

</head>
<body>

<h1>Polytima Jewelry</h1>

<p>
Welcome to my site. For more information about these hand-made
jewelry call me at 1-347-265-0077.
</p>
<p>
The collection is available at Fragments showroom, 110 Green St.,
Suite 810, New York, NY 10012, phone 212-226-8878.
</p>
<p>
More designs are available at <em>BLUE</em> at 137 Avenue A,
New York, NY 10009.
</p>

<div class="gallery">

<div>
<img src="http://polytima.com/images/NCS730.JPG" alt=""
height="168" width="253">
NCS730
</div>

<div>
<img src="http://polytima.com/images/NCP068.JPG" alt=""
height="270" width="187">
NCP068
</div>

<div>
<img src="http://polytima.com/images/NCS734.JPG" alt=""
height="168" width="253">
NCS734
</div>

<div>
<img src="http://polytima.com/images/NCP726.JPG" alt=""
height="282" width="187">
NCP726
</div>

<div>
<img src="http://polytima.com/images/NCP735.JPG" alt=""
height="168" width="253">
NCP735
</div>

<div>
<img src="http://polytima.com/images/NCP079.JPG" alt=""
height="282" width="187">
NCP079
</div>

<div>
<img src="http://polytima.com/images/BRC144.JPG" alt=""
height="190" width="253">
BRC144
</div>

<div>
<img src="http://polytima.com/images/BRW159.JPG" alt=""
height="190" width="253">
BRW159
</div>

<div>
<img src="http://polytima.com/images/BRW236.JPG" alt=""
height="190" width="253">
BRW236
</div>

<div>
<img src="http://polytima.com/images/NCS080.JPG" alt=""
height="282" width="187">
NCS080
</div>

<div>
<img src="http://polytima.com/images/NCS065.JPG" alt=""
height="282" width="187">
NCS065
</div>

<div>
<img src="http://polytima.com/images/NCL225.JPG" alt=""
height="282" width="187">
NCL225
</div>


<div>
<img src="http://polytima.com/images/NCS151.JPG" alt=""
height="190" width="253">
NCS151
</div>

<div>
<img src="http://polytima.com/images/NCS171.JPG" alt=""
height="282" width="211">
NCS171
</div>

<div>
<img src="http://polytima.com/images/NCS744.JPG" alt=""
height="168" width="253">
NCS744
</div>


<div>
<img src="http://polytima.com/images/NCS197.JPG" alt=""
height="282" width="211">
NCS197
</div>

<div>
<img src="http://polytima.com/images/NCS128.JPG" alt=""
height="282" width="211">
NCS128
</div>

<div>
<img src="http://polytima.com/images/NCS124.JPG" alt=""
height="282" width="211">
NCS124
</div>

<div>
<img src="http://polytima.com/images/BRW718.JPG" alt=""
height="168" width="253">
BRW718
</div>

<div>
<img src="http://polytima.com/images/BRW720.JPG" alt=""
height="282" width="187">
BRW720
</div>

<div>
<img src="http://polytima.com/images/BRW140.JPG" alt=""
height="168" width="253">
BRW140
</div>

<div>
<img src="http://polytima.com/images/BRW030.JPG" alt=""
height="190" width="253">
BRW030
</div>
<div>
<img src="http://polytima.com/images/NCS016.JPG" alt=""
height="168" width="253">
NCS016
</div>
<div>
<img src="http://polytima.com/images/BRW101.JPG" alt=""
height="168" width="253">
BRW101
</div>

<div>
<img src="http://polytima.com/images/BRC060.JPG" alt=""
height="168" width="253">
BRC060
</div>

<div>
<img src="http://polytima.com/images/NCS199.JPG" alt=""
height="168" width="253">
NCS199
</div>

<div>
<img src="http://polytima.com/images/BRC047.JPG" alt=""
height="168" width="253">
BRC047
</div>

</div>

</body>
</html>
 
D

dorayme

"Jonathan N. Little said:
Not that I agree with some of your design choices, if you dumped the
tables and used inline block you would not "force" 3 images per row but
have the flexibility to serve your gallery to folks with different size
browser windows. Yes, does not work in older browsers, but &deity;! IE6
& & will have to die soon, and SeaMonkey 2.0 with the newer Gecko is
coming soon. Also the page does degrade and still is usable in older
browsers.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<meta http-equiv="content-language" content="en-us">
<title>template</title>

<style type="text/css">
body {
color: #000; background-color: #ccc; margin: 2em 1em 1em 1em;
}
p {
font: bold italic medium "Times New Roman", Times, serif;
text-align: center;
}
h1 { color: #008; text-align: center; }
div.gallery { text-align: center; }
div.gallery div {
display: inline-block; width: 300px; height: 400px;
}
div.gallery div img {
display: block; margin: 0 auto 1em auto; padding: 10px;
border: 10px outset #555; background: #000;
}
</style>

</head>
<body>

<h1>Polytima Jewelry</h1>

<p>
Welcome to my site. For more information about these hand-made
jewelry call me at 1-347-265-0077.
</p>
<p>
The collection is available at Fragments showroom, 110 Green St.,
Suite 810, New York, NY 10012, phone 212-226-8878.
</p>
<p>
More designs are available at <em>BLUE</em> at 137 Avenue A,
New York, NY 10009.
</p>

<div class="gallery">
....

Indeed. If OP has uncountable or lots or database delivered pics, this
or a float method is a way to go. If the numbers of pics are not large,
then grouping them as I mentioned before will allay aesthetic lining up
problems.

Why not be practical and tighter and less ornate with:

body {color: #000; background-color: #f1f1ff;}
p {max-width: 55em;}
div.gallery div {display: inline-block;margin: .5em .5em 1em;.5em}
div.gallery div img {display: block; padding: 0px; border: 4px ridge;
color: #666; background: #f1f1ff;}

<h1>Polytima Jewelry</h1>
<p>Welcome to my site. For more information about these hand-made
jewelry call me at 1-347-265-0077. The collection is available at
Fragments showroom, 110 Green St., Suite 810, New York, NY 10012, phone
212-226-8878. And more at <em>BLUE</em> at 137 Avenue A, New York, NY
10009.</p>
 
G

GTalbot

You're right text-bottom is better than bottom here, but it doesn't
guarantee the image will be at the base of the descender space either,
since CSS doesn't specify exactly what the "content area" of an inline
box is. It might be based on the em-box, not on maximum descender (or on
something completely different but "based on the font"). See 10.6.1.

Empirically speaking, Firefox 3.5.3, Safari 4.0.3 and Internet
Explorer 8 will
include the descender space.
Opera 9.x and Opera 10.10 are wrong as they are not including neither
the em-box or the maximum descender.

I'll check with Konqueror 4.3.1: I would be very surprised if
Konqueror 4.3.1 was
not including the descender space. Including the descender space
seems
more intuitive, more natural, more coherent.


CSS3 module: Line Layout
text-height
http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#inline1

{
The 'text-height' property determine the block-progression dimension
of the text content area of an inline box. Possible values:

auto
The block-progression dimension is based either on the em square
determined by the element font-size property value or the cell-height
(ascender + descender) related to the element font-size as chosen by
the user agent.

font-size
The block-progression dimension is based on the em square as
determined by the element font-size.

text-size
The block-progression dimension is based on the cell-height
(ascender + descender) related to the element font-size.
(...)
}

regards, Gérard
 
D

dorayme

GTalbot said:
Empirically speaking, Firefox 3.5.3, Safari 4.0.3 and Internet
Explorer 8 will
include the descender space.
Opera 9.x and Opera 10.10 are wrong as they are not including neither
the em-box or the maximum descender.

mmm... I go back to vertical-align: bottom to some extent then:

<http://dorayme.netweaver.com.au/alt/inlinePicWithDescenderSpace.html>

The browsers do indeed differ in interesting ways. I notice that FF
creates a little space when you use 'vertical-align: text-bottom' rather
than 'vertical-align: bottom" to do a job usually better done by <img
style="display: block" ...> See my URL.
 
N

Neredbojias

Not that I agree with some of your design choices, if you dumped the
tables and used inline block you would not "force" 3 images per row
but have the flexibility to serve your gallery to folks with
different size browser windows. Yes, does not work in older browsers,
but &deity;! IE6 & & will have to die soon, and SeaMonkey 2.0 with
the newer Gecko is coming soon. Also the page does degrade and still
is usable in older browsers.

Furthermore, you could use server or even client scripting to replace
inline-block with floats and appx margining in those browsers and
achieve just about the same results.
 
J

Jonathan N. Little

Neredbojias said:
Furthermore, you could use server or even client scripting to replace
inline-block with floats and appx margining in those browsers and
achieve just about the same results.

I would use float too, but it would not give that *must be center*
aspect that it appears to be a design imperative of many...
 
B

BootNic

Not that I agree with some of your design choices, if you dumped the
tables and used inline block you would not "force" 3 images per row
but have the flexibility to serve your gallery to folks with
different size browser windows. Yes, does not work in older browsers,
but &deity;! IE6 & & will have to die soon, and SeaMonkey 2.0 with
the newer Gecko is coming soon. Also the page does degrade and still
is usable in older browsers.

An inline-block effect can be achieved in IE 6/7 and even in the
current SeaMonkey and older Mozilla browsers. The only question would
be: Do you really want to?

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

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

[snip]



--
BootNic Wed Oct 7, 2009 01:51 am
Our earth is degenerate in these latter days; bribery and corruption
are common; children no longer obey their parents; and the end of
the world is evidently approaching.
*Assyrian clay tablet 2800 B.C.*

â• 278 days remaining

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

iEYEARECAAYFAkrMLHcACgkQmo2774GZ7qnQqACgzUtoH/N4Pt6bX9bYfNrPFYM7
8JkAnizW7b+kMxbqvjZGH1RSgh0DY43H
=he1M
-----END PGP SIGNATURE-----
 
N

Neredbojias

I would use float too, but it would not give that *must be center*
aspect that it appears to be a design imperative of many...

Right! With floats you kinda have to fudge that which is why
inline-block is definitely preferable. Still, I'd use the floats over
tables unless the client was a stickler.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,995
Messages
2,570,233
Members
46,820
Latest member
GilbertoA5

Latest Threads

Top