CSS for long division applet
At one time, I avoided learning CSS because it seemed like that was a “woman thing” and in my career, I have noted that if you are in a primarily female field you get paid less money and people give you more shit than in predominantly female fields – thus, construction workers make more than administrative assistants, computer programmers make more than nurses. Of course there are other differences all the way down the line, but it is a strong enough relationship that when it seemed to me that women were doing more CSS and HTML, I tended to shy away from that as “not real programming”.
Well, that was stupid.
CSS is now my friend and has made many things in my life easy. For a simple example, let’s look at the long division applet I was posting about earlier before I went off on a tangent. The point of this is to allow students to practice long division, not to test them.
The CSS here is in two parts. First, there is an external style sheet
<link rel=”stylesheet” type=”text/css” href=”lakestyle.css” />
this defines some classes that are the same throughout the game. Then, I have a small style section in the page that is just those styles specific to this page.
However, to make this more generalizable, I have copied all of the classes used into the style specified below so if anyone likes, they can take the two previous posts on the javascript, this one and the next one on HTML and make their own long division program. I hate when I read something and they have left out parts that are required for it to work. That’s so annoying.
The first part sets the container size. We do this in all of our pages so they look the same on every laptop or desktop regardless of screen size. I also have that orange background image because The Invisible Developer said it should have a background and this site, speckyboy, which often gives away really free graphics, was giving away textures that week.
Yes, I used tables (don’t judge me!). Although I don’t always use them, I am not one of those people who believes in doing backflips with CSS, javascript and HTML to avoid tabes.
The table will have one cell for the one-digit divisor and another for the three-digit dividend. (This matches a common core math standard for fourth-grade “Find whole-number quotients and remainders with up to four-digit dividends and one-digit divisors, using strategies based on place value, the properties of operations, and/or the relationship between multiplication and division”.)
I want the width of each table cell set at 25%. I want the font size to be xx-large so the problem stands out on the page.
The q class defines a border at the bottom an element, in this case, a table cell. That is what gives us the top of the division problem “tableau”. I could have made it an ID but I didn’t because I thought I might add it into the external style sheet eventually and use it in other pages.
The d class is for those cells that will show up sequentially as we solve the division problem. If you read the previous posts on the javascript for this, you’d see that as each digit of the quotient is found, we multiply it by the divisor and put the product under the dividend. It’s usual to show a line under that and subtract. So, the d class is underlined. However, when we start, those cells are empty and it would look kind of dumb having just lines there, so, when we start, the cells are hidden and they are filled in and shown, complete with underline, as we solve each step in the division problem.
The c id is a cell where the divisor is. It has a line on the right side to make the other part of the thingy that goes around a division problem. I also want the divisor right up to the side of the cell so it looks like a regular division problem.
The w class has a white background, so you can see the problem.
The hidden class is for all of the elements we want hidden when the page originally loads. This includes the input form for the second digit in the quotient. We want to force the student to find the first digit, multiply that out and then find the next digit.
And, that’s all there is to the CSS for the long-division examples.
Next post, I’ll finish off with the HTML
<style>
#container {
height: 670px;
width: 1000px;
background-image: url(orangbg.png);
background-repeat: no-repeat;
}
td {
width: 25%;
font-size: xx-large;
}
.q {border-bottom: 7px solid #804040;}
.d{
display: none ;
text-decoration: underline ;
}
#c {
text-align: right;
border-right: 7px solid #804040;
}
.w{ background-color: white;}
.hidden { display: none }
</style>
Here are a few suggestions that might improve your code/performance:
1. Convert background image to JPG Original image is 1.2mb. As jpg compressed at 80%, the image looks exactly the same but weight only 74kb. The page will load almost instantly.
2. Use meaningful names in css as you would in any other language, and/or use comments to separate sections:
/* Borders for the long division */
#selector {}
#…
/* Bottom Navigation */
…
It’s no big deal in page, but if you move it to an external css file later, it will become hard to maintain.
3. Use the proper selector types:
Classes for formatting that will occur repeatedly, ids for specific elements. Your quotient will occur only once in the page so it should be an id.
4. Use height and width for your pictures. This ensures that the pictures are the right size on screen (your left hand is bigger than the right) but it also makes the page load faster.
The layout engine of your browser arranges the various elements on the page based on the html code (which is the first thing it loads). When it comes to an image and the size is not specified, the layout engine has to stop and wait for the image to load to find out its size, before it can proceed with the rest of the page layout. You have probably seen this effect many times: the page starts displaying very fast, then “nothing happens” for several seconds.
Adding the size of the image allows the layout engine to reserve space for the image and continue with the rest of the page’s layout immediately.
Hope this helps.
I appreciate the suggestions, thanks. As I said in the post when I started on this … the way I write things is I knock out something that works and then (as you suggested), I go back through and make it better. I know other people try to get it more perfected as they write. I recently read a chapter by an author who advocated against first drafts and said that you should go over each line until it is perfect and then go to the next one.
REALLY good point about the class/ ID names and you are completely right. If I move those into an external style sheet I’m going to have to change them to something more obvious or a few months from now I’m going to be reading it and wondering what the hell I meant by .d
I also work like that, but I have found that often, a “temporary” hack can end up staying a long time in the code because “something ugly that works” is low priority and by the time I get around to do it, it looks like a mess and I don’t want to touch it because it might explode, and I might get code all over my shoes.
So now I try to meet some minimum standards like proper naming and commenting on the first draft so that if for some reason I have to work on something else before I am done, I can at least come back to it and understand what the heck I was trying to do.
I had a major realization on this when reading the broken window theory.
That said, you seem to be a lot more organized than I am so maybe it isn’t as much a problem for you.
About css names, there is another consideration beyond code maintenance: silent override. If you happen to need a div for “quota” in a couple months and you call it “.q”, it will silently override your quotient formatting and you won’t notice because you have long moved on to something else.
At least with programming languages, the compiler tells you the variable is already declared, but in css it is perfectly legal to declare the same class multiple times so you won’t even get a warning.
I had to laugh when I read your comment because it is SO true. I don’t know of anyone who has not had the experience of working with code that had a temporary fix from 4 years ago. I TRY – try being the operative word in this sentence – to schedule at least one pass back through all of my code in a project for cleaning up things like functions that are named two different things in two places, moving said functions to an external script instead of in the page, etc. etc.
Your points on minimum standards like proper naming are really good. I should do that more.