Cellpadding et al
Barely Audible
this true?
--
TTFN
Jim
There is no such thing as an atheist in a foxhole.
-- Murphy's Military Laws, #25
Ben C
> There doesn't seem to be a way to put cellpadding into the css file - Is
> this true?
You just use padding on td, it's the same.
Evertjan.
comp.infosystems.www.authoring.stylesheets:
> There doesn't seem to be a way to put cellpadding into the css file - Is
> this true?
TD {padding:2px;}
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jukka K. Korpela
Not quite. The cellpadding attribute in HTML sets padding on th elements,
too (but oddly enough not on caption elements).
CSS is of course much more flexible, as you can e.g. set vertical padding as
different from horizontal padding. The HTML attribute always affects padding
in all directions the same way.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Adrienne Boswell
<exjxw.ha...@interxnl.net> writing in
news:Xns9C36B8F3...@194.109.133.242:
> Barely Audible wrote on 26 jun 2009 in
> comp.infosystems.www.authoring.stylesheets:
>
>> There doesn't seem to be a way to put cellpadding into the css file -
>> Is this true?
>
> TD {padding:2px;}
>
I think that a unit of em or percentage would be better because it would be
relative to the font, assuming that the font size was expressed in ems or
percentages.
--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
Ben C
> Gazing into my crystal ball I observed "Evertjan."
><exjxw.ha...@interxnl.net> writing in
> news:Xns9C36B8F3...@194.109.133.242:
>
>> Barely Audible wrote on 26 jun 2009 in
>> comp.infosystems.www.authoring.stylesheets:
>>
>>> There doesn't seem to be a way to put cellpadding into the css file -
>>> Is this true?
>>
>> TD {padding:2px;}
>>
>
> I think that a unit of em or percentage would be better because it would be
> relative to the font, assuming that the font size was expressed in ems or
> percentages.
You don't always want things like borders and padding to scale with the
font. People who bump the font up to read the text aren't reading the
borders and padding, and making them grow just means even less room for
the text.
Adrienne Boswell
writing in news:slrnh4d0l5....@bowser.marioworld:
I agree with you about borders, but I think I would want padding to
shrink/grow as well.
I put up a test page:
[http://www.cavalcade-of-coding.info/usenet/pixelem.html]
I was surprised that IE8 _still_ does not resize font sizes in pixels.
I would have thought that would be something they would have fixed (who
knows, maybe Microsoft doesn't think that _needs_ to be fixed).
Jukka K. Korpela
> Gazing into my crystal ball I observed Ben C <spam...@spam.eggs>
> writing in news:slrnh4d0l5....@bowser.marioworld:
[...]
>> You don't always want things like borders and padding to scale with
>> the font. People who bump the font up to read the text aren't reading
>> the borders and padding, and making them grow just means even less
>> room for the text.
>
> I agree with you about borders,
I don't. If font size is increased, keeping border width the same, you will
sooner or later end up with something rather ridiculous: boxed text with box
border that looks thin and fragile.
> but I think I would want padding to
> shrink/grow as well.
For similar reasons, yes. This becomes more obvious if you consider text
with ascenders, descenders, and diacritic marks. While a padding of 1px or
2px might be sufficient when text is in small size, it's disproportionate
for large text sizes. Even if, say, the acute accent of "�" does not touch
the top border when there is a 1px top padding, it very much looks like it
does when the font size is very large.
Demo page: http://www.cs.tut.fi/~jkorpela/test/pxem.html
> I was surprised that IE8 _still_ does not resize font sizes in pixels.
> I would have thought that would be something they would have fixed
> (who knows, maybe Microsoft doesn't think that _needs_ to be fixed).
If it isn't broken, don't fix it.
When font size is specified in pixels, it shall be implemented in pixels.
The CSS specifications are clear on this. It's OK to let users override
author stylesheets in different ways, but taking a font size declaration in
an author stylesheet and "interpreting" it as meaning something completely
different is just wrong.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
dorayme
"Jukka K. Korpela" <jkor...@cs.tut.fi> wrote:
> Adrienne Boswell wrote:
>
> > Gazing into my crystal ball I observed Ben C <spam...@spam.eggs>
> > writing in news:slrnh4d0l5....@bowser.marioworld:
> [...]
> >> You don't always want things like borders and padding to scale with
> >> the font. People who bump the font up to read the text aren't reading
> >> the borders and padding, and making them grow just means even less
> >> room for the text.
> >
> > I agree with you about borders,
>
> I don't. If font size is increased, keeping border width the same, you will
> sooner or later end up with something rather ridiculous: boxed text with box
> border that looks thin and fragile.
Yes, certainly later and ideally, the aesthetics will suffer unless
borders scale a little. In practical terms, though, I think Ben is
mainly right. Mainly? Where screen space is scarce - when is it not? -
it is practical to not let the borders grow as much as aesthetics would
dictate.
--
dorayme
Jukka K. Korpela
> Yes, certainly later and ideally, the aesthetics will suffer unless
> borders scale a little.
I don't see how they could scale a little. You can set them in metric units
(or in units defined in terms of metric units: in or pt), or in pixels, or
as relative to the font size (em or %). In the last case, they fully scale
according to the font size, naturally rounded to pixels ultimately. In the
other cases, they do not depend at all on the font size.
> In practical terms, though, I think Ben is
> mainly right. Mainly? Where screen space is scarce - when is it not? -
> it is practical to not let the borders grow as much as aesthetics
> would dictate.
That's not practical at all.
If you set border width or padding to, say, 0.07em instead of 1px, then it
will be 1px is most browsing situations, 2px for fairly large fonts, and
larger than that in special situations only - such as for a visually
impaired user who needs a font size like 40pt, and then the few pixels
"loss" really doesn't matter. It is then much more important how much of the
textual content fits in the browser window.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Adrienne Boswell
<jkor...@cs.tut.fi> writing in
news:GwE1m.17970$vi5....@uutiset.elisa.fi:
> Adrienne Boswell wrote:
>
>> Gazing into my crystal ball I observed Ben C <spam...@spam.eggs>
>> writing in news:slrnh4d0l5....@bowser.marioworld:
> [...]
>>> You don't always want things like borders and padding to scale with
>>> the font. People who bump the font up to read the text aren't
>>> reading the borders and padding, and making them grow just means
>>> even less room for the text.
>>
>> I agree with you about borders,
>
> I don't. If font size is increased, keeping border width the same, you
> will sooner or later end up with something rather ridiculous: boxed
> text with box border that looks thin and fragile.
>
>> but I think I would want padding to
>> shrink/grow as well.
>
> For similar reasons, yes. This becomes more obvious if you consider
> text with ascenders, descenders, and diacritic marks. While a padding
> of 1px or 2px might be sufficient when text is in small size, it's
> disproportionate for large text sizes. Even if, say, the acute accent
> of "�" does not touch the top border when there is a 1px top padding,
> it very much looks like it does when the font size is very large.
>
> Demo page: http://www.cs.tut.fi/~jkorpela/test/pxem.html
Agreed. Although there isn't much difference for borders:
[http://www.cavalcade-of-coding.info/usenet/pixelem.html] (updated with
images)
>
>> I was surprised that IE8 _still_ does not resize font sizes in
>> pixels. I would have thought that would be something they would have
>> fixed (who knows, maybe Microsoft doesn't think that _needs_ to be
>> fixed).
>
> If it isn't broken, don't fix it.
>
> When font size is specified in pixels, it shall be implemented in
> pixels. The CSS specifications are clear on this. It's OK to let users
> override author stylesheets in different ways, but taking a font size
> declaration in an author stylesheet and "interpreting" it as meaning
> something completely different is just wrong.
>
Agreed, however, IE8 still does not let the user up the font size when
it's expressed in pixels. I'm talking about View->Font-Size not View->
Zoom, which increases everything.
I could see a situation where one could see an image clearly, but not
the text. No need to increase _everything_, just the font.
Opera zooms everything.
Chrome zooms text, but not images.
Firefox zooms text only, if that's selected (I like that).
Safari 3 zooms only text, Safari 4 zooms both/either.
K-Meleon zooms either and/or both.
Jukka K. Korpela
> [...] IE8 still does not let the user up the font size when
> it's expressed in pixels. I'm talking about View->Font-Size not
> View-> Zoom, which increases everything.
What I meant is that browsers should _not_ do such things. It means that
they take the page's CSS code and scale the values in it. Even if done on
user command, it is grossly illogical. If a style sheet says font-size: 9px,
it is technically correct to use that font size _or_ to let a user
completely override that declaration, by whatever font size setting the user
wants. But it is illogical to apply a font size that is some pixels larger
than the declared size or some percentage larger.
Firefox, for one, is rather clueless in letting the user do Ctrl++ or Ctrl+-
to increase or decrease font sizes without saying what that means and
without giving the user any finer control. (Minimum font size is a better
idea.)
> I could see a situation where one could see an image clearly, but not
> the text. No need to increase _everything_, just the font.
That's of course rather common. But as a cure, setting a minimum font size,
or simply ignoring all font size settings in page style sheet, is a better
approach. After all, the user can be expected to decide on a minimum font
size, so why bother playing with attempts at enlargening font size from the
author-specified size, on a per-page basis, possibly without realizing that
different elements have different font size settings?
Using a font size other than the one declared in author style sheet is
always risky, as it may cause distorted layout or e.g. poor line height (if
the author has declared line height in pixels, for example). But I don't
think these risks are any smaller if the change is made by using the
author-specified size plus or minus some size or as multiplied by some
factor.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Barely Audible
grows in leaps & bounds... much better than reading some jargonised manual!
--
TTFN
Jim
The tough part about being an officer is that the troops don't
know what they want, but they know for certain what they
DON'T want.
-- Murphy's Military Laws, #47