You've stumbled onto the very first article on this website. Congratulations.
I suppose there are some pleasantries to be exchanged:
'Hello, World'; 'Foo', 'Bar'... 'Baz...'
You get the idea. The longer I've sat and written and rewritten this website's layout, the shorter my intention to introduce it has become. I had a simple website, once. So it often goes. The allure of ever-more decoration lead me down a path best described as 'dark and deceitful'. It's some kind of purgatory escaping time or sensibility -- one part fascination, one part masochism. Salt to taste. Unfortunately, frustration only pushes my teeth further into things I don't understand or need, but find a little interesting anyway. And so, day by day, I became entranced with a strange beast.
The Dragon
When reading the word 'dragon', you may envision an immense creature - imposing, ruthless, brutal; A beast fit best perched atop a castle. CSS is not this dragon. It is the twisting, formless, beguiling creature wrapped through every corner and crevice. As soon as you believe you have found its head, yet more slithering length reveals itself.
Still, I do not despise it. There is something almost beautiful in its complications. It does not impose; it pushes only where it means to. You may specify exactly which properties of which elements to fix; which children of what type will have this color or that. You may create patterns that flex and breathe as the environment changes, and fix only the constraints necessary for a legible order between them. Of course, you might well do the opposite. If you hate yourself. You can position each corner, color, font and anchor by hand, and push down every wall in the way. Unsurprisingly, this is generally an exercise in chaos.
Because of this, a CSS layout is fundamentally a composition of many miniscule pieces. Unlike object-oriented languages, its classes are not strict identities. They contain as much (or little) information as you'd like. They may touch on completely different aspects of an element, complement, or replace one another. It is a fundamentally different paradigm than the general programmer may be adjusted to. Almost functional. As you may have guessed, this adds considerable complication. It requires keeping track of many different functional blocks of properties, and to create a personal model of which components ought to be responsible for which behaviors. And much debugging. And very loose (read: inscrutable) error handling. And a certain degree of Stockholm syndrome. Yet it is also the ultimate source of its power. When the beast truly flies, you may describe only what is necessary to arrange sections of the page: Which direction, how to size each block in what turn, or the spaces to put between them; And you may specify nearly nothing and still have a functional layout. Some may find this lack of restriction distasteful.
I want to disagree...
Its Teeth
And yet, I cannot pretend to love this model of flexibility at all costs. Let's look at some selections from the documentation for a single function from the CSS standard library: radial-gradient.
<radial-gradient-syntax> =
[ [ [ <radial-shape> || <radial-size> ]? [ at <position> ]? ] || <color-interpolation-method> ]? , <color-stop-list>
<color-interpolation-method> =
in [ <rectangular-color-space> | <polar-color-space> <hue-interpolation-method>? | <custom-color-space> ]
<position-one> =
left |
center |
right |
top |
bottom |
x-start |
x-end |
y-start |
y-end |
block-start |
block-end |
inline-start |
inline-end |
<length-percentage>
<position-two> =
[ left | center | right | x-start | x-end ] && [ top | center | bottom | y-start | y-end ] |
[ left | center | right | x-start | x-end | <length-percentage> ] [ top | center | bottom | y-start | y-end | <length-percentage> ] |
[ block-start | center | block-end ] && [ inline-start | center | inline-end ] |
[ start | center | end ]{2} Woof.
It keeps going, by the way. For quite a while.
Consider a single input parameter: position-two. It has, by my count, 30 different acceptable kinds of inputs. What kind of inputs? Well, all of them I guess. Why not. Descriptive strings, raw numbers, percentages, or any of a huge selection of possible units. Or you could just not put it in at all. It will probably work. What should you use? Whatever you like, ideally. Realistically, whatever you can remember (or doesn't piss off the next person). Mercifully, there is no such person here.
Even with my LSP trying its absolute hardest to find available options, it is bound to one of two fates: Either to trip over itself failing to parse an incomplete stub in a massive solution space, or to display documentation so vague you may as well communicate in gestures and grunts. Anyone who has not dedicated years to the craft will find themselves in an infinite cycle of documentation: reading, closing, opening, reading, understanding, forgetting, opening once again... Anything can be done in any one of eleven different ways, if the language exercises a little restraint.
I won't attempt to count the ways it might not.
Somehow, despite all of this, I can't help but be a little enamored with the complete lack of restriction. There is very little you cannot do, provided a little ingenuity. Custom view-pane for content? Sure. 3D rendering context? Why not. Fake 3D right next to it? You betcha. Get very wiggly; touch everything; eschew order for elegance. You have a thousand sizes of hammer to make precision adjustments with, or to duct-tape together in altogether inadvisable ways.
I do quite enjoy the half of this process that does not involve 'finding out'. The teeth of this language are sharp and plentiful, but it's a sisyphean task to understand where exactly they'll bite. CSS promises to fly, to breathe, to do exactly what is necessary and nothing else - but only if you know what that is in advance.
One day, I may just have the beast under my control.
Hopefully not.