Full Stack Basics for Data Scientists and Other Non-Web Developers, Part 1: HTML and CSS

11 min readSep 16, 2017

This is the first of a two-part tutorial on building basic dynamic and interactive visualizations using all the tools that Data Scientists and others in tech know they “should know” but often don’t have time to learn.

The “Why”

There are two reasons why I’m writing these, and they correspond to the two different audiences for whom these articles are intended.

The first audience is Data Scientists. I’m a Data Scientist, and we often have a hard time explaining what we do. But we do know how to code, and so if we just learn the basic tools of web development and use some visual creativity, we can build basic interactive visualizations that can give consumers of our work a better understanding of what we’re doing; for example, a user could input his data, click “Submit”, and see how our model would classify him (assuming our model has already been trained).

I should acknowledge: there are tools such as Bokeh and Plotly that let you build plots with basic interactive features, such as hovering over points to see more information about them. These tools are great, and Data Scientists should learn them too; but there is only so much you can visualize, even with these tools, and you can’t do things like changing a model output based on a complex combination of user inputs as in the example described able. So despite the existence of these tools, Data Scientists should know how to create fully-featured, complex visualizations that, for example, make incremental, automatic updates every few seconds, as the Sudoku app we’ll walk through does.

But there is a broader reason to learn these tools that applies not just to Data Scientists, but also to all the non-developers — such as designers and product managers — working on product teams in tech everywhere. That reason is: knowing tools and how they work, by itself makes you more able to contribute constructively and creatively to the discussion about what your team should do. You might in theory be able to dream up the next great fully-featured web application without ever touching a line of code — and indeed, this is certainly possible. But learn how to use a hammer, screwdriver, and wrench, learn how nuts and bolts and screws and pipes fit together, and see how these tools can be used to take apart the bottom of a sink or a household appliance, and you’ll immediately get ideas for how other objects could be improved, taken apart and put back together in a better way. I believe that learning these tools, even down to the level of individual lines of code, will let you help your team take apart what they’ve built and put it back together again.

You might say that merely walking through these simple examples, rather having to creatively come up with something yourself, wouldn’t actually help your team. I’d respond that the mere act of creating makes you more creative, even if that creation is not what we think of as “creative”. Playing the scales on the piano over and over is not “creative”, but you are using the tools to create noise, as well as getting the tactile feel of how the tools actually do what they do, what it “feels like” to play fast vs. playing slow, for example. That’s why every piano player starts by learning the scales. Similarly, even going through this “paint by the numbers” example of how to apply these basic tools — HTML, CSS, Javascript, D3.JS, AJAX, and Flask — to build an interactive web application will make you more able to creatively brainstorm ideas of your own, even if you don’t code them yourself.

—

Let’s start with HTML. To illustrate HTML, we’ll go through this simple example from a Udacity course on HTML. The final result that this HTML (and the accompanying CSS) produces is:

As with learning any new coding tool, you must understand both a fair amount of the syntax used, as well as the “big ideas” that the tools encapsulate — and as is also common, I found there were tons of tutorials out there on the syntax, but not many that summarized the most important big ideas of the tools. Here’s my attempt to distill what I learned into a few key concepts:

HTML

Everything on the web is made up of rectangles. If you open a page in Safari or Chrome and type “Command+Shift+C” (on a Mac), you’ll see the rectangles that every page you visit is made up of. Even pieces of text and lines are contained in rectangles. Try doing this on a few different sites.
HTML is divided into a head, which specifies info about the page that is not seen on the screen such as the title of the page, and a body, which contains the content that users actually see on the page.
A page’s HTML defines the structure of its rectangles — specifically, which elements are nested inside of which other elements. The standard practice is to use <div> tags to divide the page up into sections, sub-sections, sub-sub-sections etc. by nesting divs inside each other.

Check out the HTML from the Animal Trading Cards example from above. There is a <div> tag defining the entire card itself, and nested within that is a <div> tag defining just the information about the animal.

Another concept: most modern pages use special <div> tags for standard sections of pages. For example, a navigation bar at the top of the page is often contained within a <nav> tag, and the content along the bottom of the page is often contained in a <footer> tag.

We’ll go here through another simple example from a Udacity course

Check out the HTML for the Portfolio site above. The top of the page is contained in a special <header> tag and the sections of the page are contained in a special <section> tag. As in general, these tag names are just conventions, and have no special significance with HTML.

HTML tags have attributes. There are many attributes specific to certain kinds of tags: for example, the href attribute is specific to the <a> tag. There are two important attributes which can be applied to any kind of tag: id, which must be unique to elements on a page, and class, which can be applied to multiple elements on a page. More on these later.

Those are the important high level HTML concepts. On to CSS.

CSS

CSS allows you to specify the styling and layout of the elements whose structure you’ve defined with HTML. For example, CSS can be used to make all the paragraphs have red text, it can control the spacing between those paragraphs, or it can control the width of the paragraphs on the page.
To apply these styles to only certain elements on the page, importantly, can be applied only to elements with a specific id— for example, animal— using the “#” syntax, as in #animal-card. Similarly, it can apply a style to all elements of a given class — for example, animal-info— using the “.” syntax, as in .animal-info.

CSS affects how elements are laid out on the page in two important ways.

First, it affects how much spacing there is between elements. margin is the amount of spacing between the element and all surrounding elements — the “outermost” layer. Padding affects the distance between the content and its border — the border is what it sounds like, a border around both the content and its padding.

Second, it affects how elements are laid out — for example, it affects whether rectangles are contained on a “new line” below the rest of the content, whether the rest of the content wraps around elements, or a combination. These roughly correspond to elements having the layout properties of either block, inline, or inline-block, respectively. A visual that illustrates the differences between these three different layouts more concretely is below:

Block vs. Inline vs. Inline-block illustration

A very tricky thing when building a “nested” layout from scratch in CSS is getting the “child” elements to go their correct position within their “parent” elements. “Floats” are a way to accomplish this. This great blog post contains more than you need to know about floats, but the image below gets the main idea across with the example of images “floating” within an article of text:

Illustration of “floating” left and right

Portfolio website

Let’s see how these concepts come together to make a portfolio site using HTML and CSS. Here’s a link to the GitHub repo.

First, let’s go through the HTML file and notice its structure:

At the top of the HTML is the head containing metadata about the page.
The next part of the HTML — within the body, so it will be shown to the user — is the header . This will contain the top part of the webpage.
Then there’s a main part, which is divided into sections.

The class of the “work” section was work. This section contains the three projects. These projects are organized in an unordered list, and each list item contains several elements.

Note that there is no inline styling of elements; nowhere do you see style: ___ with something after the colon in the HTML. All the styling is done in the CSS, as it should be.

Let’s go over the CSS — in this case, it is much more extensive than the HTML:

Header

First, we make the header of the page span the whole page, have a min-height of 70 pixels (so whatever is inside of it will have room to be displayed) and give it the appropriate borders.

We size the header logo and make it “float left”.

We float the name, on the other hand, to the right, as well as making it large and uppercase.

We put the job title just below this name by using “float right” and “clearing” the float above it. We also make it uppercase and just slightly larger than average.

Main image

We’ll first give it some space at the top and bottom.

Then, we’ll make the main image fill the entire width of the page and center it on the page.

Work section

This is the section with the most involved CSS.

First, we center the entire section using margin: auto.
For the title, we float it left, give it some margin along the bottom, and increase the font size.
For the projects themselves, we use a noteworthy and relatively new CSS trick used when we want lists of items to wrap around when the screen size becomes too small. We give it the display property flex and define what happens upon wrapping by giving it the flex-wrap property wrap. This ensures that when the screen is resized the boxes change their sizes appropriately; read more here.
For each individual work project, we give it a margin and give it a flex-grow value of “1” to prevent the boxes from growing upon the page being resized. Also for each item, we’ll center align the text within it and give it a little margin to the right.
For each image, we set the width to 100% to have it fill the work projects item, and have its height fill proportionally based on the item’s width.
Finally, we align the project title in the center of its parent and do the same for the project URL, setting a width for the latter so that it doesn’t get too squished and wrap around when we resize the page.

Final result

To see the final result of all of this, clone the repo, navigate to the folder containing the code, and open index.html in the browser of your choice. (you can see what it looks like in the screenshot above).

It isn’t the most beautiful site, but it does beautifully illustrate many of the basic elements of HTML and CSS. Try resizing the page and you’ll see that the size of the images changes, where appropriate, and the work items wrap around on the bottom of the page when the window gets too narrow as you’d expect.

Sudoku

Let’s put these elements together to create a Sudoku grid. The code is on my GitHub here.

The HTML the board needs is in the index.html file in the templates folder. The HTML is quite simple, as the Sudoku board has a natural nested structure to it. The entire board is wrapped in a grid. Each of the nine blocks within this grid is of a grid-block class and each of the actual squares containing individual numbers is a cell. Each cell has a id attribute with the id of that cell.

We’ll now turn to the CSS for the grid, which is contained in the style.css file in the static/stylesheets folder.

First, I‘ll style the grid. We’ll give it a block layout, use “margin: auto” to center it on the page, and give it a border:

/*The big grid.*/
.grid {  
  width: 475px; /*156 * 3 + 8 (for borders)*/  
  height: 475px;     /*Center the whole thing horizontally*/  
  display: block;  
  margin: auto;  
  border: 2px solid blue;
}

Then, I define thegrid-block class within the grid. There will be nine of these blocks, and each will contain nine numbers. We’ll float these to the left, and make their layout inline-block so they “wrap around lines”, meaning if I have three of them in the overall grid, the fourth will just wrap around to the next line. So in reality, there are just nine blocks within one larger block in one “line”, but the blocks “wrap around to the next line”, being constrained ultimately by the width of the parent block.

/*A 3x3 block containing the cells for each value.*/
.grid-block 
{   
/*Maintain row width while wrapping next row around*/  
  display: inline-block;  
  float: left;  
  width: 156px;  
  height: 156px;  
  border: 1px solid white;
}

Finally, cells fit within these grid-blocks in a similar way, floating left, having their own border, and being each of them constrained by the size of their “parent” grid-block.

.cell 
{  
/*Size cells*/  
  width: 50px;  
  height: 50px;  
  border: 1px solid white;   /*Gets cells to move to left of row.*/  
  float: left; 
  transition: all 1.0s ease;
}

A trick is used to give each alternating grid block a different background color. I make the “even numbered” grid blocks have one background color and the “odd numbered” grid blocks have another background color.

/*Alternate colors blue and gray*/
.grid-block:nth-child(odd) {  
background-color: powderblue;
} .grid-block:nth-child(even) {  
background-color: Gainsboro;
}

And that’s the Sudoku! Here’s the final result (with numbers filled in):