Rules are not easy

Sometimes in software design we get this idea, “We’ll make this a rule engine. Then the business can write the rules, and they’ll be able to change them without changing the code. That’ll make it more flexible.”

🤣

The rules are code; they change the behavior of the system. Rules interact in ways that are hard to anticipate. It’s harder to write rules than to write code.

It seems like we make business decisions in terms of rules, because we talk about them that way.

People make uncomplicated decisions by rule. We make complicated decisions by aesthetic (from expertise), and these are difficult or impossible to express in rules.

Real-life rules often contradict each other. A human with a feeling for the situation can prioritize among them.

For instance, “How do you position a picture in a column of text?” Back in the day, people laid out the newspaper pages, and they positioned them using some rules and also their eyes. How does a browser do it? Careful people have created nine precise rules for positioning float elements. Excerpt:

4. A floating box’s outer top may not be higher than the top of its containing block. When the float occurs between two collapsing margins, the float is positioned as if it had an otherwise empty anonymous block parent taking part in the flow. The position of such a parent is defined by the rules in the section on margin collapsing.

you don’t need to actually read this

If you think “Rules are declarative, they’re easier to reason about than imperative code” then go format a complicated web site with CSS. Make changes in the hundreds of lines of CSS, and see if you can predict the results. Now see if you can predict the results of changing someone else’s CSS.

Writing rules is hard. Designing a syntax and semantics that let people write rules to cover all the cases in the world, even harder. Do you really want to embark on that? Is it really more effective than changing some code when the business wants change?

As humans, we make aesthetic judgements for complicated decisions. This is one of our superpowers. Putting those judgements into rules is never easy; don’t pretend it is. And no, you don’t need to implement a rule engine.

Thanks to @nokusu for teaching me about floats and margins and other layout fun.

Why is CSS a thing?

All I want is a web page. I want this one thing on the left and this other thing on the right — why is this so hard?? Can I just make a table in HTML like I used to do in the nineties? Why do I have to worry about stylesheets? and, why are they so hard?

As a backend developer, I’m used to giving the computer instructions. Like “put this on the left and this on the right.” But that is not how web development works. For good reason!

As the author of a web page, I do not have enough information to decide how that page should be laid out. I don’t know who is using it, on what device, in what program, on what screen, in what window, with what font sizes.

You know who does know that stuff? The user agent. That’s a technical term for an application that presents documents to people. The browser is a user agent. The user agent could also create printed documents, or it could speak the document to a person whose eyes are unavailable.

The user agent runs on a particular device. Computer, phone, TV, whatever. It knows the limitations of the hardware. It can be configured by the user. The user agent can conform to various CSS specifications.

CSS is not a programming language. It is a syntax for rules, rules which give the browser (that user agent) clues about how to display the document. The browser combines that information with what it knows about the world to come up with a format to display (or speak) the document.

It turns out that rule-based programming is hard. It sounds like it should be easier than imperative code, but it is not.

So no, you don’t get to decide that this thing goes on the left and that thing goes on the right. The browser gets that choice.

But here’s something I learned yesterday: put each thing in a div, and give those divs display: inline-block. then the browser has the option of putting them next to each other, if that fits with those constraints that only it knows.

CSS Positioning: a summary

I’ve been frustrated every time I try to grasp CSS for years. “I just want this on the left and this to be over here!” etc. Now I realize that CSS doesn’t work that way for very good reasons. In most programming, we give instructions for what we want to happen. But in CSS, it’s more like we are describing a situation — relationships — and then letting the browser figure it out. That’s because the browser has to handle many different circumstances. Resolutions, interfaces, font sizes. I describe how the parts go together, it figures out how to put them on the screen.

When I get upset about the properties for one part being dependent on the properties of its parent containers and siblings, it’s OK Jess: remember that CSS is about interrelationships, so this is normal.

Having got that, I’m now able to learn about how to put things on the screen without yelling in frustration and confusion.

So far, I’ve looked up the position property and learned that it doesn’t do much. There are other ones like display that seem more important. But meanwhile here’s my executive summary:

The position property determines two things: whether the element participates in document flow, and what the properties top bottom left right do. These are the useful ones:

position: static – the default. Stay in document flow; top bottom left right do nothing.

position: relative – nudge. Stay in document flow.  top bottom left right nudge the element in that direction from where it would have been. This also has some effect on child element positioning, at least in the case of ::before pseudo-elements (weird CSS tricks).

position: absolute – override. Remove the element from document flow. top bottom left right tell it where exactly where to be within the document (or within the next absolutely-positioned element up the tree).

position: fixed – override and hold weirdly still. Remove the element from document flow
tell it exactly where to be within the viewport. That means within the browser window (or the iframe if it’s in one). When the page scrolls, this element stays in the same place. People use this for menus.

Please lmk if you have corrections.