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

CSS2 specification: What is BODY > P { line-height: 1.3 } ?

P: n/a
Hi

I am a newbie struggling a little with css.It is hard to get it right
in all browsers, so i decided to read the CSS2 specification on the w3
site.
What is the following from the CSS2 specification:

"Quote starts":

5.6 Child selectors
A child selector matches when an element is the child [p. 30] of some
element. A
child selector is made up of two or more selectors separated by ">".
Example(s):
The following rule sets the style of all P elements that are children
of BODY:
BODY > P { line-height: 1.3 } /* OP note: What is this line?*/
Example(s):
The following example combines descendant selectors and child
selectors:
DIV OL>LI P
It matches a P element that is a descendant of an LI; the LI element
must be
the child of an OL element; the OL element must be a descendant of a
DIV.
Notice that the optional whitespace around the ">" combinator has been
left out.
For information on selecting the first child of an element, please see
the
section on the :first-child [p. 62] pseudo-class below.

"Quote ends":

That line with the ">" sign gets me.I have tried several things in my
notepad editor to test it but it doesn't work for me.
In the above example, all P within the BODY should have the style
applied to them, so i did the following in my editor and ran it with
I.E 6.0, N.N. 7.1 and Mozilla 1.4:

<HTML>
<HEAD>
<TITLE>Test</TITLE>
<STYLE TYPE="text/css">
BODY > P {color: red}
</STYLE>
</HEAD>
<BODY>
<P>My name is Patrick</P>
</BODY>
<P>My name is Kristina</P>
</HTML>

Both sentences within <P> tags turn out red in Mozilla and N.N. and
remain black in I.E.
Now i understand that i am probably not supposed to place a P tag
outside of a BODY tag but since the CSS2 specification chooses that
example i had no choice.
From what i understand of the BODY > P {color: red} style, in my
example the sentence "My name is Patrick" should be red because that P
is within the BODY tag and "My name is Kristina" should remain black
because its P is outside the BODY tag.I don't get it?

Thanks to the pros for helping a struggling (But determined) CSS
student.

Patrick
Jul 20 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
The > selector selects only immediate children, not children of children
or further nesting.

body > p {...}

matches

....
<body>
<p>this</p>
<div>
<p>but not this</p>
</div>
</body>
....

It doesn't work at all on Internet Explorer for Windows.

--
Some say the Wired doesn't have political borders like the real world,
but there are far too many nonsense-spouting anarchists or idiots who
think that pranks are a revolution.

Jul 20 '05 #2

P: n/a
va******@netzero.net (Patrick) wrote in
news:a3**************************@posting.google.c om:
<HTML>
<HEAD>
<TITLE>Test</TITLE>
<STYLE TYPE="text/css">
BODY > P {color: red}
</STYLE>
</HEAD>
<BODY>
<P>My name is Patrick</P>
</BODY>
<P>My name is Kristina</P>
</HTML>

Both sentences within <P> tags turn out red in Mozilla and N.N. and
remain black in I.E.
They remain black in IE because IE doesn't support child selectors.
Now i understand that i am probably not supposed to place a P tag
outside of a BODY tag but since the CSS2 specification chooses that
example i had no choice.
From what i understand of the BODY > P {color: red} style, in my
example the sentence "My name is Patrick" should be red because that P
is within the BODY tag and "My name is Kristina" should remain black
because its P is outside the BODY tag.I don't get it?


What you're not getting is the difference between a *child* element and a
*descendant* element. All P elements, by the rules of HTML, have to be
*descendants* of BODY (i.e. they can't appear before <BODY> or after
<BODY>), but they don't have to be *children* of it. Consider:

<body>
<p>This paragraph is a child of the body element.</p>
<ul>
<li>
<p>This paragraph, being the first one inside a list, is not a child
of the body element, even though it's a descendant of it.
It's a child of the li element that it's enclosed in.
</p>
</li>
</ul>
</body>

If you were to write

li > p {background: blue;}
body > p {background: red;}

then the first paragraph would be in red but the second would be in blue.
If, on the other hand, you used descendant selectors ("li p" and "body p")
rather than child selectors, both paragraphs would come out red because the
second rule would override the first.
Jul 20 '05 #3

P: n/a
va******@netzero.net (Patrick) wrote:
What is the following from the CSS2 specification:

"Quote starts":

5.6 Child selectors .... BODY > P { line-height: 1.3 } /* OP note: What is this line?*/
"Line height" is the vertical distance
from the bottom of THIS word
to the bottom of THIS word.
It is a multiple, greater than 1 unless you're clowning around, of the
font-size.

Child selector is poorly worded in the spec - it means "immediate
child" - see Owen's nearby post.

In the above example, all P within the BODY should have the style
applied to them, so i did the following in my editor and ran it with
I.E 6.0, N.N. 7.1 and Mozilla 1.4:

<HTML>
<HEAD>
<TITLE>Test</TITLE>
<STYLE TYPE="text/css">
BODY > P {color: red}
</STYLE>
</HEAD>
<BODY>
<P>My name is Patrick</P>
</BODY>
<P>My name is Kristina</P>
</HTML>

Both sentences within <P> tags turn out red in Mozilla and N.N. and
remain black in I.E.
Now i understand that i am probably not supposed to place a P tag
outside of a BODY tag but since the CSS2 specification chooses that
example i had no choice.
From what i understand of the BODY > P {color: red} style, in my
example the sentence "My name is Patrick" should be red because that P
is within the BODY tag and "My name is Kristina" should remain black
because its P is outside the BODY tag.I don't get it?


That's a long standing Mozilla bug, failing to recognize the </body>
tag, and IE is simply ignoring the ruleset completely because it
doesn't implement child selectors.
Jul 20 '05 #4

P: n/a
To Owen Jacobson:

You wrote:"The > selector selects only immediate children, not
children of children or further nesting."

Thanks so much Owen.One line and a half from you and i got it now.

To Eric Bohlman:

You wrote:"They remain black in IE because IE doesn't support child
selectors."

I will make a note of that.

You wrote:"What you're not getting is the difference between a *child*
element and a *descendant* element."

You are right Eric, well you were right really, because thanks to you
and the other posters i got it now.I am glad i posted because it would
have bothered me for days.Thanks so much!

To Karl Smith:

You wrote:"Child selector is poorly worded in the spec - it means
"immediate
child" - see Owen's nearby post."

I did and got the difference between child element and descendant
element.Thanks Karl for your help.

Thanks to the three of you, i got it and can move on.

Regards

Patrick
Jul 20 '05 #5

P: n/a
Karl Smith wrote:
That's a long standing Mozilla bug, failing to recognize the </body>
tag, and IE is simply ignoring the ruleset completely because it
doesn't implement child selectors.


A proper implementation of </body> would refuse to display anything
following the closing tag?
Jul 20 '05 #6

P: n/a
"Firas D." <fd********@firasd.org> wrote:
Karl Smith wrote:
That's a long standing Mozilla bug, failing to recognize the </body>
tag, and IE is simply ignoring the ruleset completely because it
doesn't implement child selectors.


A proper implementation of </body> would refuse to display anything
following the closing tag?


No, I think the OP's expectation was correct. His P after BODY should
be displayed, but it certainly shouldn't match a selector like "body >
p".

Why browsers continue to format after an </html> tag is easier to
understand, that's an obvious error. An XML parser will halt with some
message along the lines of, "Junk after document - only whitespace
allowed," and an error correcting HTML parser infers the location of
</html> at the very end of the doc as soon as it passes <html>,
ignoring any "extra" </html>.

But it shouldn't error-correct by ignoring the closing </body> tag
where the author wrote it, and automatically inserting one where
Mozilla thinks it usually goes. If the doc is tag soup and the browser
has to interpolate extra elements to compensate, fair enough. But if
the doc is a proper tree of elements, the "error correction" is just
plain interference.

The earliest HTML documents had the structure: title, body, address.
Address got moved to inside body later on. I wonder what Mozilla would
make of one of those fossils if one could be found?

--
Karl Smith.
Jul 20 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.