Trying to practice making tables but my CSS doesn't show

Community Off Topic
#1

https://www.codecademy.com/rmataya/codebits/lPQRSE

I’m trying to practice and made a table project, but none of the CSS is showing up. I’ve tried adding a border and changing the alignment, but it still shows up like the plain HTML. I don’t know what I’m doing wrong. I even tried internal CSS but no dice.

the index.html linking it:

<head>
<title>Table Practice</table>
<link href="style.css" rel="stylesheet">
</head>

the style.css:

table, th, td {
    border: 1px solid black
}
th, td {
    text-align: center
}
#2

The syntax error is causing the next line to be ignored. No styles can applied whether external or embedded.

<title>Table Practice</title>

I tweaked your CSS…

table {
    width: 50%;
    border-collapse: collapse;
}
table, th, td {
    border: 1px solid black;
}
th, td {
    text-align: center;
}

You should know that labels down the left side may be (and probably should, for the sake of semantics) declared as TH, not TD.

    <tr>
      <th>Alena</th>
      <td>4</td>
      <td>3</td>
      <td>1</td>
    </tr>

An empty element without an ID attribute should have at least one character,

<th></th>

and since it is not semantically a heading element, it should be a TD.

<td>&nbsp;</td>

That will give the element some dimensions and will not be spit out as a validation error.

table_practice

Aside

Concerning the Table Heading (<th>) element, it has a special attribute called scope which defines the range it applies to, whether column or row.

    <thead>
    <tr>
      <td>&nbsp;</td>
      <th scope="col">Attack</th>
      <th scope="col">Defense</th>
      <th scope="col">Magic</th>
    </tr>
    </thead>

and,

    <tr>
      <th scope="row">Alena</th>
      <td>4</td>
      <td>3</td>
      <td>1</td>
    </tr>

Further aside

Content of the left side column should not be center aligned. Left alignment is easier to read and has a more consistent look and feel.

We can tweak the CSS a little more to achieve this:

table {
    width: 50%;
    border-collapse: collapse;
}
table, th, td {
    border: 1px solid black;
}
th, td {
    text-align: center;
}
th[scope=row] {
    padding-left: 0.5em;
    text-align: left;
}

Resulting table…

table_practice_scopes

Note the use of attribute selector in the last selector rule?

3 Likes
#3

Oh wow, can’t believe I missed my table/title mistake. Thank you so much! Quick question: so whenever you have an empty element, you should always add:

&nbsp;

is there any other scenario where you would use that?

1 Like
#4

In a page with a script behind it that we expect to supply content to an empty cell, we can leave the element empty. It’s only when no content is going to be inserted that we should populate the element with a non-breaking-space entity. Mind this is old school, from back in the day when cells would not inflate when there is no content present.

Generally speaking, we will rarely if ever leave empty elements in our document so this trick more or less applies to table cells.

<p>&nbsp;</p>

<li>&nbsp;</li>

<div>&nbsp;</div>

None of the above are very likely to surface in any document as they have no semantic value and hint at spacing which is better handled in the CSS.

Edit

Just tested to see if cells inflate when empty and it would appear that HTML has matured enough to overcome that past issue. This means that technically we no longer need to manually inflate empty cells.

Validation is sitll a concern, though, so best practice would still be to not leave table cells completely void of content. The entity is not going to hurt anything, and will prevent the validator from flagging the empty cell.

2 Likes
#5

I noticed you switched the order of the selector rules from what is posted above. Any reason for this?

The way you have ordered the rules makes it appear that table {} needs more specificity, which is not the case. The way I wrote it, the table only rule is generic and will not face any conflicts anywhere in the cascade. It makes better sense to leave it at the top.

Not only that, in the correct order, the width value is given to the browser before any border properties. The order you have means they will need to be held in abeyance until the box size can be calculated. It makes sense to have the size appear before anything else.

Another thing… semi-colons. Sure it is okay to leave it off of the last property in the rule set, but this is a bad habit to form and can create maintenance problems down the road. Make it a hard and fast rule to end all property declarations with a semi-colon. The only exception to this would be when (heaven forbid) we use the style attribute. Of course this creates its own maintenance issues.

1 Like
#6

There wasn’t any particular reason for doing that, but I revised it! I wasn’t aware the order had any impact on it, but it makes sense to have general rules at the top and narrow it down from there. Speaking of the style attribute, would you recommend external CSS over internal CSS whenever possible? I recently learned about internal and inline CSS and was wondering about the benefits of them versus external CSS.

#7

When it is a <style> element in the <head> it is embedded and when it is a style attribute it is inline.

Both are questionable, but the inline one the most. It is a maintenance nightmare waiting to happen. Avoid inline styles like the plague. Embedded styles are useful in one-off situations but eventually a site will revise itself to use no styles that are not external.

There is a little wiggle room, obviously, but in a production site the new stuff needs to be resolved into the production scheme or it adds to the pile of unknowns. External is best.

When a page is nicely isolated in its own folder, I often create a thispage.css file that lets me muck around with the current styles and make this page a little different. Theme and purpose are concerns at this point, but we are not messing with the main site styles, yet can merge in new styles just by adding one more file to the load sequence. thispage.css will load last.

1 Like
#8

Ahh okay, I understand. That’s super good to know, especially since that inline/embedded tutorial left out those helpful pointers. Thank you so much!!

1 Like
#9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.