CSS for Tables

Tables still have a place--for tabular data. Duh. Such as the Companies table in FDB. But I had to remember the CSS around tables.

First, the basic structure:

table
  thead
    tr
      th
  tbody
    tr
      td

Table

border-collapse: { separate (default) | collapse }
border-spacing: { #both | #horiz #vert } - default is 1px
empty-cells: { show (default) | hide }
table-layout: { auto (default) | fixed } - fixed is like !important for widths

For a responsive table, put it inside a container (e.g., div) with overflow-x: auto;

Width, height, border can be applied to table, th and td--not tr, thead or tbody.

Cells

th and td tags. CSS doesn't seem to like naked th and td. Prefer table td or table th selectors.

text-align: { left | center | top }
vertical-align: { top | bottom | middle }
padding
(margin doesn't do anything; use border-spacing)
border-bottom: - for just horizontal lines between rows

Rows

For a mouse-over to select whole rows at a time:


tr:hover { background-color: yellow; }

For alternating row colors:


tr:nth-child(even): { background-color: #f2e0f2; }

Comments

GraphQL is the many-to-many solution

Exactly! Regular readers of this blog (me) will appreciate my stumbling attempts to pre-define a REST interface that supports many-to-many interfaces. GET a class, for example, and the return includes an array of the students in that class. In this context, we don't want a full Student record, just the Student's name and Id, for example. With a REST interface, the server writer has to guess how to abbreviate the Student record. GraphQL fixes that. The front end requests just the data it wants. If we want a list of the students in a class and the assigned roommates for that student...we can do that! A lot of my prototype REST service is hardwired--not single tables, so much, but the many-to-many stuff certainly. There was a certain amount of work implementing the simple router ("/table/recordno"). GraphQL means throwing a lot of that away, but I can see immediately that GraphQL's approach is what I want. My schema tables (implementing INSERT and UPDATE) look ...

Vue.js

I had the example from a YouTube Tutorial on Vue working, but I'm having a little trouble creating an empty project for my own development. Part of the issue is that Vue is compiled. What you're running is minified (or not) JavaScript that includes a ton of stuff along with your app. So you can write a little, compile it, look at it in a browser (using the WAMP server) and repeat those steps to death, or you can use their system development which automatically compiles and auto-runs when it notices a source code change. vue ui brings up an app (at /localhost:8000) that manages this process, in theory, but I've forgotten the mechanics of it. In the example, we had a tree: public `--src `--App.vue `--views | `--Home.vue | `--About.vue `--components `--Todos.vue `--TodoItem.vue ...

Relational Updates

The pattern I've been focused on for some time is the classic 'students in classes' or 'passengers on flights' problem. The database has a table of students and a table of classes and an association table which joins them. That's basic stuff. The problem is how do you update a student to edit her list of classes, or update a class to edit its list of students? The relational integrity is not a problem--if you delete a class from the student, that student no longer appears in the class' list of students. The problem is your simple form gets very complicated. Instead of a form that displays the columns of a single row in a table, now we have three tables involved. Of course it's solvable, but we want it to be intuitive for the end user. Old time software punted the problem--you could edit the association table, or a class, or a student, but you couldn't add classes to a student. What we want is a list of classes on the student record. Each class ...

On Programming

Search This Blog