What’re you eating? Part 9

When I last wrote, I had 3 courses of action ahead of me:

  1. Implement an external CSS to stop every page/tag having individual style solutions

  2. Implement JavaScript to improve a couple of features & because I know, deep down, that I’ll have to do it at some point

  3. Ignore it and keep moving forward with half-solutions because results are more important than method

Well, if there’s one thing high school maths taught me, it’s that my justification for 3 might be a bit off - so let’s see how we go with the rest.

Cascading Style Sheet (CSS)

For anyone not across this: a quick explainer is that you can assign classes/IDs to HTML elements and then give style attributes that way, rather than writing it out every time. I had a lot of lines like <table border="1"> & <td align="left" valign="middle"> that were repeated many times down each page. Instead I can define a class and assign it to each tag I think should be formatted in the same way and then outline the formatting once. It serves several purposes to make it worth the time to change (yes, I know I should have been doing it from the start):

  1. Reduces the chance of a mistake across a page

  2. Makes implementation of changes trivial

  3. Makes the code look neater on the page

Let’s <div>e in (little HTML joke there for you) and get to work on implementation.

I started by creating ‘style.css’ and then linking my pages to it by inserting the following into the page header:

<link rel="stylesheet" href="styles.css">

From here I was able to start setting up the CSS. I don’t want to muddy the waters by dumping the entire thing on the screen because:

  1. It’s bespoke to what I like and everyone will have a different way they want it to look

  2. It’s essentially the same as the existing code examples I’ve put up

but I’ll call out a few things that I did that I think are noteworthy.

Firstly, I differentiated between the navigation, data entry, and pantry list tables with separate classes. I did this because I planned some slight differences, and even though they’re meant to be mostly the same, I’d prefer to keep them slightly separate in some aspects. This left me with this collection:

table.formTable {} - for the data entry table
td.formTitle {}    - for the left-hand column (titles)
td.formContent {}  - for the right-hand column (content)

table.navTable {} - for the navigation table where there's only row

table.contentTable {} - for the pantry contents table
tr.contentRow {}      - for the rows/cells because I wanted some different formatting options
td.contentCell {}

Now instead of HTML that looks like this (plus a bunch of style options defined at the top of each page):

<table class="table1">
  <tr>
    <td align="right" valign="middle">
      Product:
    </td>
    <td align="left" valign="middle">
      <input type="text" class= "textbox" name="product">
    </td>
  </tr>

I now have these:

 <table class="formTable">
  <tr>
    <td class="formTitle">
      Product:
    </td>
    <td class="formContent">
      <input type="text" class="textbox" name="product">
    </td>
  </tr>
table.formTable {
    border-width: 0px;
    background-color: #ffffff;
    width:25%; 
    margin-left:auto; 
    margin-right:auto;
    font-family: Verdana, sans-serif;
}
td.formTitle {
    text-align: center;
    vertical-align: middle;
}
td.formContent {
    text-align: left;
    vertical-align: middle;
}

It looks like more (partially because I left out some of the style options for the original format) but now that it’s written, I have all the benefits I listed above and it actually saves me time/effort overall. I actually left the background colour as ‘aquamarine’ because it’s started to grow on me, but I also included 2 more points of interest:

th.sortHeader {
    cursor: pointer;
}
a:visited {
    color: #000000; /*black*/
    text-decoration: none
}

The sortHeader function is in preparation for something I want to do later but while it’s not used yet, I wanted to highlight something cool I found you can do with the cursor. The a:visited line is actually a pseudo-class which lets you define the style of elements in certain states. I don’t like the look of the purple ‘clicked link’ look so I can just overwrite it with an ‘always black’ command even once the link’s been visited.

Everything’s roses yeah? It all worked and we’re happy and can move past it? Unfortunately not - we had a small problem on pantry_list.php.

Why on Earth were the ID numbers now being displayed up there???

If you’ll recall from my last post, the table was looking fine and formatted correctly so I have no idea what happened. I spent hours troubleshooting. I agonised over my style choices, I rearranged elements & I furiously (more so as time went on) searched online for a solution to my problem. The problem being that the same conclusion kept circling - without the stylesheet the table looked fine, but there was nothing ‘wrong’ with the stylesheet. The project stalled.

Cut to several days later spent taking my frustration out on a tub of ice cream, I revisited the problem and really tried to understand what was being displayed to me. I finally noticed this when I went to “inspect” the page:

<h2>Pantry Items</h2>
8910111213
<table class="contentTable" rules="cols">
  <tr class="contentRow><td class=" contentcell'=""></tr>
  ....

Me: “Why isn’t the td tag nested insi……oh bloody hell” - I’d forgotten a quotation mark. Hours of soul/online searching and it came down to a “contentRow> vs “contentRow”>. I was right though, there wasn’t anything wrong with the stylesheet - just how I implemented it. Now with the contentRow class reference fixed: does it work?

It does! Now I get to tackle JavaScript….woo.

Previous
Previous

What’re you eating? Part 10

Next
Next

What’re you eating? Part 8