Stop body p from influencing table p?

Hi - when I insert a <p> in a comparison <table>, then the font displays in smaller size and I can see in firebug that body p is influencing it, but I don’t know how to stop it.

It’s here:

Pls scroll down to the table. I added a <p> in its first para “Black <p> with a gray & white control panel” to show the difference.

I tried table {font-size:100%} and table p {font-size:100%} but that doesn’t work. And I closed the p in the para preceding the table.

thanks! - Val

Sorry Paul - I didn’t see it was you who gave me the inherit advice :slight_smile:

Hi noonnope - thank you! font:100% works. Except if I leave out the <p> then it doesn’t… (and I have so many tables where there’s no p)

see first table on this page, where there’s no p:

If you scroll down to 2nd table where p’s are, you’ll see they’re now displaying correctly.

Do you or Paul have any idea why IE6 is displaying that huge white space above the txtbox on that page? I’ve checked carefully and all div’s are closed.

thank you! - Val

p (an element name) is more specific than .ari (a class name)

it’s another font definition applied, and it has to do with the cascading.

the font applied to the table, which is inherited by Black:

.ari {
font: normal normal normal 0.8em/1.5 Arial, sans-serif;

is “overwritten” (says you) for <p>with a gray & white control panel</p> by

p, li {
color: black;
font: normal normal normal 0.88em/1.6 ‘Lucida Sans Unicode’, Verdana, sans-serif;
padding: 0px 0px 10px;

so you have to correct both font face and font size. and line height.

you could add:

.ari p {font:inherit}


.ari p {font:100%/1.5 Arial,sans-serif}

one mistake you could do is to do something like this:

.ari, .ari p {
font: normal normal normal 0.8em/1.5 Arial, sans-serif;

which will make the font size for p inside .ari to be calculated like this: p is 0.88em, .ari is 0.8em so .ari p is 0.88em*0.8em = 0.704em.

have you tried it/test it? it’s best you do before posting. usually, a simple look at the style cascade using dev tools UAs offer does more to understanding an issue than all the dry theory in the world.

Off Topic:

i usually use appropriate code highlighting: css, html, js, but in this case the mods added are better depicted using font colours.

That shouldn’t happen - .ari has a higher specificity than p so where you have text that is both inside a <p> and inside a <… class=“ari”>, it will use the ari class style rather than the paragraph style if there’s a clash.

[ot]Please could you use

 tags to put round code, rather than [quote]s, it makes it easier for other people when trying to quote your message. Ta![/ot]

i guess you are confusing some about inheritance and specificity. yes, if ari was a value for the class attribute of a <p> element, .ari would have a higher specificity than p.

here’s an example to play with both inheritance and specificity:

<html lang="en" dir="ltr"><head>
<style type="text/css">
  body { size:100&#37;; }
  p { color: blue; font-size: 0.8em; }
  .red { color:red; font-size:0.6em; }
  .orange { color:orange; font-size:2em; }


  <p>Paragraph. Blue text.</p>
  <p class="red">Paragraph. Blue text. Red class.</p>

  <div class="orange">
    Text node.
    <p>Paragraph. Blue text. Orange container.</p>
    <p class="red">Paragraph. Blue text. Red class. Orange Container. </p>

Off Topic:

ok. will do.

To quote your tagline, “Wait, what?”

The page you’ve linked to says:

[LIST=1][]If one declaration is from a style attribute, rather than a rule with a selector (an inline style), it has the highest specificity. If none of the declarations are inline, proceed to step two.
]Count the ID selectors. The declaration with the highest count has the highest specificity. If two or more have the same number of ID selectors, or they all have zero ID selectors, proceed to step three.
[]Count the class selectors (for example, .test), attribute selectors (for example, [ type=“submit”]), and pseudo-classes (for example, :hover). The declaration with the highest total has the highest specificity. If two or more have the same total, or they all have totals of zero, proceed to step four.
]Count the element type selectors (for example div) and pseudo-elements (for example, :first-letter). The declaration with the highest total has the highest specificity.
A single class selector has a higher specificity than a single element selector. I might be missing something blindingly obvious, but a class pretty much has to outrank an element, or the “.ari” format would be useless, because the element selector would override it, eg with <p class=“ari”>, anything you put in p {…} would override anything in .ari {…} - and that definitely doesn’t happen.

Of course, it would be a whole lot easier to de-bug if the site wasn’t such an eighteenth century mangle of inline formatting, unsemantic hooks and what looks like boilerplate template rubbish…


.ari p {font:100&#37;/1.5 Arial,sans-serif}

it’s not suppose to replace the .ari, it’s supoose to be an addition.
so, you’ll have both.

.ari {
font: normal normal normal 0.8em/1.5 Arial, sans-serif;
.ari p {
font:100%/1.5 Arial,sans-serif

about your markup: you declare html but you also use self-closing tags of xhtml. and you do have some severe errors: check this.

Hi noonnope - thanks million! This displays perfectly in all <table>s:

.ari p, .ari li {font:inherit}

best, Val

Just a reminder that IE6 and 7 don’t understand the value inherit at all so if IE6 and 7 support is needed you would need to define it explicitly :slight_smile:

I tried that - defining the <p> not the table - and it doesn’t work. I wish I could just ignore IE6/7 but I’ve pandered to them on the entire site so it’d be nice to get them to display the font correctly in <table>s.

yes Paul, and no Val: see below :slight_smile:

have you tried the other option i gave you?

.ari p {font:100&#37;/1.5 Arial,sans-serif}

You’re right, I got confused :blush:

My apologies.


I agree that sometimes the automatic formatting can be a hindrance rather than a help … but if you use CODE rather than HTML/HIGHLIGHT then you can put whatever colours you like in there.[/ot]

Hi noonnope -

>if IE6 and 7 support is needed you would need to define it explicitly

oh dear, you’re right. It doesn’t display correctly. By explicitly do you mean I have to define each para? So instead of:

<table class=“ari”>

it has to be:

<p class=“ari”>

thanks, Val

and it shows in the picture i posted.

Golly gosh and darn it, you’re right.
I’m so used to the problem being specificity that I completely forgot about declared styles outweighing inherited styles.
I’m an idiot.

In your stylesheet, body p {...} affects all <p> elements inside <body>, whether they are contained in other elements like tables, or not.

But in your stylesheet you’ve got no mention of “body p”, so I don’t understand what Firebug is telling you. I’m also not sure what the problem actually is - what is misbehaving, and what do you want it to do?

(Closing the preceding <p> is good practice, but won’t actually have any effect. If you have a <p> open then any block-level tag will be treated as though it has a </p> in front of it)

Hi - I’m sorry, that still doesn’t work on that one table.

I realized I’m only keeping the data comparison <table>s. All my other tables (e.g. I had images in tables) I’m converting to div’s. This means 10pt Arial now applies to ALL tables. So I tried this:

table {font:0.8em/1.5 Arial,sans-serif}
table td, table p, table li {font:100%/1.5 Arial,sans-serif}

and it’s working fine on every page in IE6 except the first table at:

The same structure is on other pages - td with no p - and it’s displaying correctly in IE6, e.g.:

It doesn’t make sense that it displays correctly in all docs, except in one table in one doc (and correctly in another table in that same doc!). Same for the white space at the top of that specs-exc.php. I checked that error page but nothing explains why only this page has white space above the txtbox. The errors mentioned are on every other page but they’re all displaying correctly.

Thanks for pointing out self-closing tags are not allowed in html. I didn’t know that. They’re there for the future when the pages get moved into wordpress :slight_smile: So far it’s not caused a problem in any major browser.

thank you! - Val