Hello
Suppose I have a div containing headings and paragraphs, and I decide to
add some margin or padding to the left side of the div to create some
whitespace. My question is, in this situation, is there any reason
whatsoever to choose padding over margin or vise versa?
para
JWL wrote:
> Suppose I have a div containing headings and paragraphs, and I decide to
> add some margin or padding to the left side of the div to create some
> whitespace. My question is, in this situation, is there any reason
> whatsoever to choose padding over margin or vise versa?
>
>
para
JWL wrote:
> Hello
>
> Suppose I have a div containing headings and paragraphs, and I decide to
> add some margin or padding to the left side of the div to create some
> whitespace. My question is, in this situation, is there any reason
> whatsoever to choose padding over margin or vise versa?
Depends on *where* you want the space!
see:
http://www.w3.org/TR/CSS21/box.html#box-dimensions
You have to consider the context of the application, you suppled not URL
so who would know?
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
For longer style sheets, I've pulled my hair out sometimes trying to
figure out why a certain element is not reacting to my placement
rules, only to find out that I've set the parent element with a
padding rule which is affecting the child's margin rule (or other
positioning rules).
I would agree with other posters that it's your preference, however,
it may be wise to set your own personal routine and practice of how
you do enforce spacing rulesets so you do not get confused.
My hunch is that the more prudent practice is to set specific
placement or spacing rules on the child element which you wish to
alter. If the spacing rule is intended to apply to all child elements
of a parent container, then I would think the padding rule would be
set on the parent containing element.
Hope that helps,
Jim
JWL wrote:
>
> Suppose I have a div containing headings and paragraphs, and I decide to
> add some margin or padding to the left side of the div to create some
> whitespace. My question is, in this situation, is there any reason
> whatsoever to choose padding over margin or vise versa?
>
It depends.
Margin affects the spacing outside of the border. Padding affects the
spacing inside the border.
--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
On Sun, 27 May 2007 09:56:30 GMT JWL scribed:
> Hello
>
> Suppose I have a div containing headings and paragraphs, and I decide to
> add some margin or padding to the left side of the div to create some
> whitespace. My question is, in this situation, is there any reason
> whatsoever to choose padding over margin or vise versa?
One significant difference is that padding will "propagate" the background
of the div whereas margins will delimit it. Also, top and bottom margins
may merge into adjacent margins, a situation which does not occur with
padding. Thirdly, padding will allow for the placement of absolutely-
positioned elements (within the relative container) "over itself" so to
speak.
I'm sure there are other differences as well.
--
Neredbojias
He who laughs last sounds like an idiot.
Scripsit Neredbojias:
> One significant difference is that padding will "propagate" the
> background of the div whereas margins will delimit it. Also, top and
> bottom margins may merge into adjacent margins, a situation which
> does not occur with padding. Thirdly, padding will allow for the
> placement of absolutely- positioned elements (within the relative
> container) "over itself" so to speak.
>
> I'm sure there are other differences as well.
Vertical margins do not affect non-replaced inline elements; vertical
paddings do (though this does not affect line height).
Some elements have default margin or padding. This may depend on browser.
Thus, if you wish to affect e.g. the indentation of a list, you should
always set both padding and margin for both the list element (ul or ol) and
the list items (li elements). Setting just e.g.
ul { margin-left: 0; }
or
ul { padding-left: 0; }
has radically different effects on different browsers.
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
Just reading margin and padding in lists ...
Is there a way to get the lines (1 and 2) with a
spacing?
Knut Krueger wrote:
> Just reading margin and padding in lists ...
> Is there a way to get the lines (1 and 2) with a
spacing?
>
Jonathan N. Little schrieb:
> Knut Krueger wrote:
>> Just reading margin and padding in lists ...
>> Is there a way to get the lines (1 and 2) with a
spacing?
>>
On 2007-05-28, Knut Krueger
> Jonathan N. Little schrieb:
>> Knut Krueger wrote:
>>> Just reading margin and padding in lists ...
>>> Is there a way to get the lines (1 and 2) with a
spacing?
>>>
>>>
>>> Its working wiht
>>>
>>>
>>>
>>> buts an error in the validating
>>
>> LI { margin: 1em 0; }
>>
> Thanks
> uhh then i have to change all li entries, because I do not want this for
> all lists.
> I have a class in the not in the
You can always do:
ul.foo li { margin: 1em 0; }
which means "apply the margin to s
with class of foo"
Or
ul.foo > li { margin: 1em 0; }
"apply the margin to s with class of foo"
Ben C schrieb:
> On 2007-05-28, Knut Krueger
> You can always do:
>
> ul.foo li { margin: 1em 0; }
>
> which means "apply the margin to s
> with class of foo"
>
> Or
>
> ul.foo > li { margin: 1em 0; }
>
> "apply the margin to s with class of foo"
Much quicker
Thank you.
.... just laughing over foo - its not common in Germany and I was looking
for a function foo the first time I read this in R-Statistic Language-
and I was searching a long time :-)
Knut Krueger wrote:
> Ben C schrieb:
>> On 2007-05-28, Knut Krueger
>
>> You can always do:
>>
>> ul.foo li { margin: 1em 0; }
>>
>> which means "apply the margin to s
>> with class of foo"
>>
>> Or
>>
>> ul.foo > li { margin: 1em 0; }
>>
>> "apply the margin to s with class of foo"
>
> Much quicker
> Thank you.
>
> ... just laughing over foo - its not common in Germany and I was looking
> for a function foo the first time I read this in R-Statistic Language-
> and I was searching a long time :-)
You'll also sometimes see "bar" (like - ul.foo.bar) as a sample code.
The derivative is from the acronym "fubar" which is sometimes read as
"Fouled Up Beyond All Repair." Commonly used in the U.S. Military.
http://en.wikipedia.org/wiki/FUBAR
--
Ed Mullen
http://edmullen.net
http://mozilla.edmullen.net
http://abington.edmullen.net
Ed Mullen wrote:
> Knut Krueger wrote:
>> Ben C schrieb:
>>> On 2007-05-28, Knut Krueger
>>
>>> You can always do:
>>>
>>> ul.foo li { margin: 1em 0; }
>>>
>>> which means "apply the margin to s
>>> with class of foo"
>>>
>>> Or
>>>
>>> ul.foo > li { margin: 1em 0; }
>>>
>>> "apply the margin to s with class of
>>> foo"
>>
>> Much quicker Thank you.
>>
>> ... just laughing over foo - its not common in Germany and I was
>> looking for a function foo the first time I read this in R-Statistic
>> Language- and I was searching a long time :-)
>
> You'll also sometimes see "bar" (like - ul.foo.bar) as a sample code.
Extended, the canonical metasyntactical variables become foo, bar, baz
and quux.
--
Blinky RLU 297263
Killing all posts from Google Groups
The Usenet Improvement Project: http://blinkynet.net/comp/uip5.html
Scripsit Knut Krueger:
> Is there a way to get the lines (1 and 2) with a
spacing?
There is no such thing as
spacing. The
or
means line
break. Browsers often interpret a lone
as a request for empty line, but
don't rely on such (mis)behavior.
Just use margin settings in CSS.
> Its working wiht
>
In article
"Jukka K. Korpela"
> Browsers often interpret a lone
as a request for empty line, but
> don't rely on such (mis)behavior.
On all my Mac browsers I don't get an _empty_ line.
--
dorayme
dorayme schrieb:
> In article
> "Jukka K. Korpela"
>
>> Browsers often interpret a lone
as a request for empty line, but
>> don't rely on such (mis)behavior.
>
> On all my Mac browsers I don't get an _empty_ line.
>
That's a problem - verifying the pages is very difficult.
Firefox f.e is different on Mac and Windows and maybe different on
Linux. Seems that there is a need for at least three systems to test all
possible bugs and variations of the pages ...
Knut
In article
Knut Krueger
> dorayme schrieb:
> > In article
> > "Jukka K. Korpela"
> >
> >> Browsers often interpret a lone
as a request for empty line, but
> >> don't rely on such (mis)behavior.
> >
> > On all my Mac browsers I don't get an _empty_ line.
> >
> That's a problem - verifying the pages is very difficult.
> Firefox f.e is different on Mac and Windows and maybe different on
> Linux. Seems that there is a need for at least three systems to test all
> possible bugs and variations of the pages ...
>
Is FF different on Windows cf to Mac? I have so far been
supposing not, thinking that I would have heard by now surely?
--
dorayme
On 2007-05-29, dorayme
> In article
> Knut Krueger
>
>> dorayme schrieb:
>> > In article
>> > "Jukka K. Korpela"
>> >
>> >> Browsers often interpret a lone
as a request for empty line, but
>> >> don't rely on such (mis)behavior.
>> >
>> > On all my Mac browsers I don't get an _empty_ line.
>> >
>> That's a problem - verifying the pages is very difficult.
>> Firefox f.e is different on Mac and Windows and maybe different on
>> Linux. Seems that there is a need for at least three systems to test all
>> possible bugs and variations of the pages ...
>>
>
> Is FF different on Windows cf to Mac? I have so far been
> supposing not, thinking that I would have heard by now surely?
I doubt it, but what did you mean by a "[non-]_empty_" line? A line
containing nothing but one line-height's worth of space is what a lone
gives me on my Linux version of FF.
e.g.
...
In article
Ben C
> On 2007-05-29, dorayme
> > In article
> > Knut Krueger
> >
> >> dorayme schrieb:
> >> > In article
> >> > "Jukka K. Korpela"
> >> >
> >> >> Browsers often interpret a lone
as a request for empty line, but
> >> >> don't rely on such (mis)behavior.
> >> >
> >> > On all my Mac browsers I don't get an _empty_ line.
> >> >
> >> That's a problem - verifying the pages is very difficult.
> >> Firefox f.e is different on Mac and Windows and maybe different on
> >> Linux. Seems that there is a need for at least three systems to test all
> >> possible bugs and variations of the pages ...
> >>
> >
> > Is FF different on Windows cf to Mac? I have so far been
> > supposing not, thinking that I would have heard by now surely?
>
> I doubt it, but what did you mean by a "[non-]_empty_" line? A line
> containing nothing but one line-height's worth of space is what a lone
>
gives me on my Linux version of FF.
>
> e.g.
>
>
> ...
>
>
>
>
>
I just meant that when one puts in a
after a short bit of
text which continues after the
and can be seen as say three
lines of text in a div that is suitably width limited, the three
lines are all full of text, none are empty of text. There is no
empty line. But, I suppose, come to think about it, JK was
meaning something very specific about a _lone_
, not merely
_one_
. Perhaps I got the context wrong?
While I am here, both FF and Safari pile up empty
s according
to their number. I feintly recall it being said it was not
certain how browsers behaved in this respect. Alas, they seem to
behave as expected thus probably aiding and abetting the poor
practice of using these things for layout.
--
dorayme
On 2007-05-30, dorayme
> In article
> Ben C
>
>> On 2007-05-29, dorayme
[...]
>> > Is FF different on Windows cf to Mac? I have so far been
>> > supposing not, thinking that I would have heard by now surely?
>>
>> I doubt it, but what did you mean by a "[non-]_empty_" line? A line
>> containing nothing but one line-height's worth of space is what a lone
>>
gives me on my Linux version of FF.
>>
>> e.g.
>>
>>
>> ...
>>
>>
>>
>>
>>
>
> I just meant that when one puts in a
after a short bit of
> text which continues after the
and can be seen as say three
> lines of text in a div that is suitably width limited, the three
> lines are all full of text, none are empty of text. There is no
> empty line.
I see, yes that's expected behaviour and I'd be surprised if FF did
anything different on any platform.
> But, I suppose, come to think about it, JK was meaning something very
> specific about a _lone_
, not merely _one_
. Perhaps I got the
> context wrong?
I don't know but I think people were getting the impression there might
be some variance between FF on different platforms in the handling of
. But we have no evidence of any such phenomenon.
> While I am here, both FF and Safari pile up empty
s according
> to their number. I feintly recall it being said it was not
> certain how browsers behaved in this respect.
I remember reading that somewhere but can't now find it.
> Alas, they seem to behave as expected thus probably aiding and
> abetting the poor practice of using these things for layout.
And yes they do usually behave as people deprecatably expect (lots of
empty lines) unfortunately.