Hacker News Reader

> I’m going to respectfully disagree with the “our brains aren’t wired” part: the most important part of the spec is the chapter of the visual formatting model which can be summarised as “each HTML element is a rectangular box” - that’s it. Simple to internalise for anyone new today and everything else builds on top of that.

This is, respectfully, absolutely insulting to people actually working in CSS in real browsers. Okay fine, it's a rectangular box. When and where does it appear? Sometimes it's undefined. What properties does it have once it does? Hoooooly crap this is undefined.

As a just today example: I discovered that two eventually overlapping linear gradients in Safari (checked in iOS) render differently after wake from sleep or dark/light mode switch. One of the gradients doesn't render at all before, and only renders in the portion of its "rectangle" after. Bug? Sure. Common-fucking-place-normal-ass-website-styling-shit? Yep.

Edit to add the real kicker: it has nothing to do with the styles of the thing with the gradients on it! It has nothing to do with accommodating the children of the parent. It's just: one parent is a grid, the other is a flex. Nothing. At. All. Changes the outcome.

Does this have anything to do with CSS? Or is it just another bug in Safari? Or do I misunderstand?

That's kind of a false dichotomy, since once you understand CSS rules on something such that it works somewhere, you spend a lot of time interpreting addendums on caniuse and trying to arrange graceful degradation.

If you only have to make it work on one browser with one version, or if the feature is extremely old, or if you can do it outside a larger system of constraints, then you can just follow the step-by-step guides the article is complaining about.

Yes, it has to do with CSS. I could have mentioned a zillion bugs in Chrome or Firefox (the only remaining major renderers), but the bugs aren’t the point. There’s far more than rectangles at work when you actually need to render things in a browser.

> There’s far more than rectangles at work when you actually need to render things in a browser.

Indeed. You're entirely correct.

But with CSS the basis is that general "everything is a rectangle" model - which makes it easier to adapt to new features when they're introduced - compared to having to basically learn-from-scratch when new layout features are added to other systems.

You are applying your ego and identity to this. The poster above you is correct, it’s just boxes.

And, why wouldn’t it just be boxes? You screens are just small little boxes (pixels), and everything you put on it takes up an area of pixels.

It has nothing to do with my ego or identity. I was a long time FE dev years ago but probably moderately skilled today. But even according to the spec it’s not just boxes. Putting aside browser quirks, there’s frickin SVG. There’s the `path` type. There’s shapes you can flow content around, including arbitrary image alpha layers. There’s radial gradients. There’s conic gradients. There’s border radii (which are non-rectangular enough a recent post on css-tricks.com featured a post on a “font” using only border-radius). There’s a whole cottage industry of CSS-only graphics.

Sure, the base primitives are rectangular and like you said why wouldn’t they be? Everything visual starts with x1/y1/x2/y2 in a sense.

CSS-for-SVG is not the same as CSS-for-SGML/XML/HTML though - it's a special case: SVG uses CSS to provide for cascading properties, but not for the visual-formatting model. But entirely I agree it's confusing and contrary to the normal use of CSS. I feel the working-group should have called it "CSP" for "Cascading SVG Properties" instead of appropriating the CSS moniker because that's led to confusing and broken expectations.

That’s an important distinction, which I appreciate. It’s worth noting that there are a lot of things in CSS-for-SGML/XML/HTML that look like CSS-for-SVG (like the aforementioned `path` type) and are decidedly non-rectangular.

Just boxes. Sure, ok by the same logic, singing is just air, writing is just words, movies are just light and sound. Code is just directions. You can reduce anything to it’s elements and it’s hard to argue, the basic truth of that, but the art is being able to do beautiful things with those elements can vary quite a bit with each medium. And with css, it is quite complex to be able do it well.

Right up until margins start sticking out of boxes and adding or subtracting and weird ways, not to mention what floating elements and pseudo elements do to your boxes.

CSS absolutely does disagree with our brains because it's trying to take a tree of elements with their own properties that interact based on their tree relationship and projecting that into 2D.

> Right up until margins start sticking out of boxes and adding or subtracting and weird ways, not to mention what floating elements and pseudo elements do to your boxes.

None of that contradicts my point that CSS generates a hierarchy of rectangular boxes from SGML/HTML/XML elements. And every system has some form of margin control, and most have some degree of support for negative margins and margin-collapse. I appreciate it's yet another thing to learn, but it doesn't violate the simplicity of the "everything is a rectangle" model that CSS uses: consider other systems that special-case their layout mechanisms (like how WPF/XAML has `<StackPanel>` for layout and `<Border>` for margin control, rather than allowing any element to have its own margins and any element to control the layout of its immediate children): it's hard to say WPF/XAML's system is "better" because rather than having a simple initial model with special-cases laid-on-top, instead you have a model comprised of only special-cases.

> CSS absolutely does disagree with our brains because it's trying to take a tree of elements with their own properties that interact based on their tree relationship and projecting that into 2D.

There isn't really any feasible alternative[1] that doesn't introduce more complexity. All the other tree-based (or hierarchy-based) systems for representing a visual document that I have experience with, such as WPF/XAML/UWP, WinForms, Qt, and others, all rely on some degree of "inheritance" from parent nodes to child nodes (and ancestor to descendant nodes) in a document (e.g. in WinForms a Control's background color defaults to its parent container's background color. Controls inherit their parents' Font, but only during initilization, thus introducing another "gotcha"), I agree that CSS shares a long list of exceptions and special-cases, but CSS's special-cases are built-on a better general-case.

If there's a better way of doing things - please share!

[1] The alternative would be something that freely translates hierarchical documents into some kind of unstructured or semi-structured "rendered document" in a separate render-space - but I don't see how that frees people from having to deal with complexity, on the contrary: it introduces even more complexity (because now the "stylesheet" is concerned with mapping from one space to another, possibly in a bi-directional manner too), whereas CSS doesn't require any significant space-translation[2]

[2] CSS's `grid` and ability to re-order `flex` elemenets, and the `absolute` and `fixed` positioning schemes do introduce new space concerns, but besides that, 95% of structured document content retains its spatial relationships when mapped by CSS's visual formatting model.

The casscading part is what makes CSS devilish, its a bunch of hiddens tate written in a language people dont master (becauses its not really worth it to vs all the other stuff to learn) and this hidden state creates all sorts of headaches. Whats worse is these headaches are so damn visual, you cant ignore it. Visual bugs drop the perceived quality of your brand so it can cost alot to leave that nasty visual bug around.

My approach is to limit cascading as much as possible and try to contain the evil that is css to its respective component.