Reading articles like this, my basic impression is that, after CSS has been around for twenty years or more, it’s still complex to do simple things that everybody wants.
Is this why the web is less successful than it might be?
> it’s still complex to do simple things that everybody wants.
People underestimate the complexity of layout. Take vertical centring, for example. The immediate assumption is that it’s easy; you just find the mid-way point between the top and bottom. But the top and bottom of what? The web is a document-based system, with text flowing from top to bottom. The centre in this context is not the centre of the window, but the centre of the document.
Okay, so let’s find the mid-way point between the top and the bottom of the document. The top is easy, it’s zero. So where’s the bottom? Well to find that, you need to know how tall the document is. How do we do that? Well, the height of the document is defined by the height of all of its contents. So let’s render its contents and find the height. But wait – the thing we are trying to render in the centre is part of the contents, so we’ve got ourselves into an infinite loop.
There are various solutions to this – hard-code the height of the document (to what?); take the thing being centred out of consideration when rendering the rest of the document (and now it can’t affect / be affected by the rest of the contents), etc. But which solution is best depends upon the context – and this is how you end up with complexity. It’s easy to say “just put it in the centre”, but it’s not as easy to figure out what that means exactly or which solution is best for doing so.
> Is this why the web is less successful than it might be?
The web is one of the most successful technologies in the history of human civilisation. It seems quite odd to talk about it as if it were a flop because you have to think for a moment before centring something.
I don't know what it is about the web, maybe because it's so accessible, that makes people assume its GUI abstraction should be easy. Or that because web GUI is hard then the web's abstractions are basically a failed experiment. Or, HN's favorite, that we're somehow trying to build things with these completely anodyne GUI tools that they're somehow not meant for.
But it's hard because GUIs are always hard. And the things that make HTML/CSS hard are the threads that run through all other GUI abstractions and make them hard.
Notice how Android and iOS developers are never piling into HN circlejerks raving about how Google and Apple have really solved GUIs.
Here are six different ways to center a square in a box in UIKit with constraints: https://stackoverflow.com/a/26181982/511200 I've been an iOS developer for over five years and I still consult this regularly when checking constraint spaghetti to make sure it's not missing any bits of the magic incantations.
And HTML nor CSS weren't developed with layout in mind. The original idea was to mark up (the M in HTML) meaning and semantics and leave the rendering and display to the client entirely.
If you consider that systems that were designed entirely around layout (Like QT layout https://doc.qt.io/qt-5/layout.html), are complex and hard, you can imagine what happens when you try to do layout with a system that was never intended to handle this, must be backwards compatible, is a standard (not a lib or framework) and can be freely interpreted by renderers by definition.
I vastly prefer web client development where there are much better abstractions and I have rather arbitrary freedom.
I think web GUI tools are simply better and I think my StackOverflow is one example why. The web also has a full spectrum responsive solution.
Even Apple is transitioning from 90s KVO tech to SwiftUI, a buggy experiment that looks like any of the reactive/observable weekend frameworks that the web has been experimenting with for 10 years.
One thing I notice is how little cross-experience there is. The iOS developers I work with have barely built a web client, and web developers have barely built a mobile client. I bet 95% of our opinions including my own are driven by familiarity, and we just like to roleplay that it's some deeper technical calculation.
That said, even if the iOS dev experience was 10x as good as it is today, I still wouldn't pick it for personal projects because polishing an application that only iOS users can use is a nonstarter. That downside got old so fast.
Let me guess, you did not do any iOS development?
To claim that web has better abstractions is insanity.
Even before autolayout to say that was a stretch.
And I say this because I do have that cross-experience: working with web since 1998 (1996 non-professionally) and with iOS since 2010 (professionally since 2012).
> The web is a document-based system, with text flowing from top to bottom.
This was always the central mistake in the design of CSS. It was solving a problem people just didn't really have. I mean, yes, it did both simplify and improve the situation for this sort of document flow kind of thing but we were all using tables for a reason:
Because what people needed was a mechanism to describe structured layout. Inside that, document flow is important, but we spent 20+ years just getting back to the structural power of tables and it's fucking ridiculous.
And it did it all in a way that required the exact constraint solving complexity you're lamenting. But it didn't really have to be that way.
CSS was a disaster and has almost certainly wasted incredible amounts of time and money that could have been better spent if a better solution had come along in time.
> we spent 20+ years just getting back to the structural power of tables
Already CSS 2.0 (which is indeed 20 years old) had the power of tables through the "display:table" property. Flexbox and grid gives you additional power.
You could also just keep using <table> tags. Either way, they interact strangely with other aspects of CSS and you have to structure your "document" in a very particular (very likely non-semantic) way in order to use it for layout.
Having an escape hatch to break the box model completely so you can do useful things with it is not actually giving you any structural power, it's just admitting the weakness in the model.
Fundamentally, what was always needed -- and what flexbox and grid finally started bringing -- was the recognition that structural layout and semantic structure are rarely the same thing, and that you need to be able to describe them separately, usually in separate hierarchies.
Still, they do it in a fairly convoluted way that only really feels simple by comparison to what came before.
> Having an escape hatch to break the box model completely so you can do useful things with it is not actually giving you any structural power, it's just admitting the weakness in the model.
I don't really get what you are saying here. Are you saying display:table or display:grid breaks the box model? Because I don't agree with that interpretation. But maybe I misunderstand.
display:table and display:grid are not really the same class of thing? One lets you make things act more like pre-css html, the other is a completely new addition to the box model.
"breaks the box model" might be too strong, I'll admit. But table-styled elements don't act quite like other things in the box model even so. It's confusing and messy and anyways you have to contort your document to fit things together in a way that works with it most of the time.
On the other hand I'm saying display:grid is good, but took way too long to get here.
I don't see what is confusing or messy about display:table. Of course if you use it for a purpose it is not suited for, it gets messy. But so it is with everything.
No. This often repeated and it is always wrong. I just won't bother anymore to tell why it is wrong, there is no point talking to people who will not listen.
> not as easy to figure out what that means exactly
I wholeheartedly disagree. When you see the title "centering in CSS" you know exactly what it means. It's the same old problem everyone has been solving repeatedly for 20 years. It's not about edge cases. It's not about exceptions to rules self imposed by your specific needs. It's just centering inside a box. And the author of the article knows this, and solves it again for us for the nth time with updated techniques.
The issue isn't how complicated a layout is or needs to be. If you were to look at how horizontal center is implemented under the hood, it's going to be complicated, yet that complexity is abstracted away.
It boils down to the simple fact that intuitively when we've had <center> forever, why couldn't there have been a <vcenter> from the beginning? Not even broken, it never existed. It's as if we're being told, "horizontal centering we'll handle, but vertical centering is for you to figure out". Err, why? And figure out based on the tags and attributes provided. Like, they implemented the puzzle but not the solution.
Similarly, why can't "vertical-align: center" just work more often? The fact that a div needs to be a table-cell or a grid, or having the option of using <td> that still works should all be redundant. There is nothing ambiguous about wanting to vertically center.
We're always reverse engineering from a need. Complex needs justify complex code. Simple needs should be simple declarations.
> why couldn't there have been a <vcenter> from the beginning?
Because HTML is incrementally rendered. The content of <center> can be rendered line by line as data arrives, but a <vcenter> would need the full content to be loaded before it could be rendered, since you need to know the dimensions of the content before you can center it vertically in a container.
Vertical centering cannot be supported in the ordinary top-down incremental flow rendering. It requires a more complex layout model like table, flex or grid.
When you have an img tag in an html document, and that image takes a while to load and has no pre-set width and height, guess what: the document renders fine and everything else adjusts when the image is finally loaded and its size is known. There's really no reason at all that a <vcenter>ed element couldn't be vertically centered at all times within its containing box, even as its containing box changes size, except a stubborn and dogmatic unwillingness to accept that web pages aren't magazine layouts.
It would be more accurate to say that HTML is progressively rendered. As information comes in, boxes move and change size and eventually settle in their positions.
> everything else adjusts when the image is finally loaded and its size is known
Yes, this is called reflow. At the time <center> was introduced, browsers did not support dynamic reflow (except by re-rendering the whole document from the top). For example tables had to be fully loaded before they would be rendered, and the same would be the case for a hypothetical <vcenter> element.
<center> on the other hand can be progressively rendered without requiring reflow.
My point is just that vertical centering requires a more complex layout model than horizontal centering.
And my point is regardless of how complex something is, unless it's impossible, you can just give the thing a name and hide the complexity under the hood.
Why are we still talking about how to vertical align elements in 2020? That's the question. Having to discuss history as an excuse to why anything is, is a symptom of the problem.
I don't think anyone is suggesting that vcenter or something like it should have existed at that time. The point is that it could have certainly been introduced by the time css came around and started handling more than basic text styling. It's been over two decades since that condition held.
The "more complex layout model" has been here a long time.
> I don't think anyone is suggesting that vcenter or something like it should have existed at that time.
Uh, this subthread started with exactly that question:
> It boils down to the simple fact that intuitively when we've had <center> forever, why couldn't there have been a <vcenter> from the beginning? Not even broken, it never existed. It's as if we're being told, "horizontal centering we'll handle, but vertical centering is for you to figure out". Err, why? And figure out based on the tags and attributes provided. Like, they implemented the puzzle but not the solution.
I mean, sure, I guess you could take it as literally as "in tim berners lee's original browser version" but frankly, CSS and the ability to reflow the document is so old at this point that getting anal about it not being literally there since the beginning of the web is just silly.
Have perhaps a little bit of charity and assume that what was meant there was "since it was possible".
I mean, all the comments I got were not about my main points at all.
"No you should do this because of that" is not a valid argument when both "this" and "that" only exist because you created them. If vcenter was part of the original spec, we would have it because the browser publishers would have made sure they fulfilled the specs. We have yet to have it. We are being told valign is a complex feature, and we just accept it.
But you should always model your specs based on use case, because that's who you're serving. Anything less than that is ego and dogma driven development.
And to me, the most disappointing and damning evidence was that w3c does not even author their own web site. They are not users.
Being from MIT, I could only imagine how fun a student driven implementation effort could be, and they'd do it for free. I was not alone in 1999 building web pages in an Athena cluster.
Not sure why writing on HN is so often a negative experience. Not sure why I keep doing it.
Have you considered proposing your idea to the CSS working group? The w3c are just the editors, CSS is developed in the open and anyone can propose extensions.
Yes, because vertical centering can be implemented manually using these available elements as you said.
But no, because all it takes is one of these solutions and naming it "vcenter" under the hood and not having to interact with any of it. And that's exactly what we do using classes or using a css framework that provides for better abstraction than vanilla css. And as the original article demonstrates, there usually is one best practice that checks all the boxes.
It's not that vertical aligning is buggy or that it doesn't work or that it's not possible. There was never a tag for it as if the need wasn't acknowledged, even with the browsers fully capable of doing it as demonstrated by every webmaster that did it since css1.
And to add, complexity is never a reason when you're capable of abstraction. The main issue with CSS and HTML is there is no "let". You're always forced to deal with the specific tags directly. Instead, javascript is provided as a tool for abstraction. So again, it's all possible. We just have to do it ourselves as opposed to there just being a "let".
> why couldn't there have been a <vcenter> from the beginning?
So if you want to support a layout that adapts to the size of a viewport you'd do what? Go through DOM with JS on each size change and rewrite DOM from <vcenter> to <somethingelse> and back?
Vertical centering would work just as horizontal centering works in 99% of the cases as expected. The syntax could be symmetric. We override and adjust as needed. Instead, we have nothing to override or adjust. We're forced to pick a layout system just for a specific feature, and add 5 lines of code that now interferes with everything else.
The argument isn't that it's hard. It's that it could be so much easier. But also, that there just might be a fundamental issue with the philosophy of what could have been just html has evolved into the monstrosity that is css/html/javascript+framework+backend_render... with "the inability for vertical alignment to declared simply" as evidence.
> Well, the height of the document is defined by the height of all of its contents. So let’s render its contents and find the height. But wait – the thing we are trying to render in the centre is part of the contents, so we’ve got ourselves into an infinite loop.
What? Where did the loop come into it? The height of the document is defined by the height of its contents. The thing we're putting in the document is part of the contents. So what? You can render it and measure its height without needing to lay out the document. There is no self-reference or circular reference anywhere in the "problem" you've described. The height of the element is an input into the centering problem, but it's not also an output of the centering problem. The positioning of the element is an output of the centering problem, but it's not an input into it.
I'm not an expert on layouters, but I'm pretty sure that in the general case the height of an element does in fact depend on how it is layouted including what elements it is layouted with.
I also believe that's why some traditional UI toolkits have started adopting constraint solvers.
CSS can be frustrating and it was certainly for many years missing basic stuff, punting that to developers to solve by hand - but I agree with grandparent that these problems are not as trivial as they appear.
And it just works without “loops” that simpleton methods like container stacking do have. Did you know that linear algebra has methods to quickly solve that Excel circular reference? What should we do, maybe stop using Excel for layouts?
>The web is one of the most successful technologies in the history of human civilisation.
Amazon is the most succesful e-store in the history. Microsoft is the most succesful desktop in the history. Etc, etc, etc. Being most succesful is a result of many traits, and it doesn’t mean it is maximally succesful, technologically and programmable-y superior or even correct. It was just succesful enough to not break under its weight and split into two or more streams of development. (In smartphones it actually did, and we all know how faster and cleaner phone apps look and feel vs web apps).
I used to think CSS was complex and everything was a hack. Then I sat down and actually read about the box model rules, how things like margin and padding affect elements, and how amazingly useful flexbox was.
I've worked with web developers that still don't understand the usefulness of collapsing margins. Developers that think padding is an alternative to a margin and not understanding they are different things altogether. If your solution to spacing something is to wrap it in a new element and add padding then you're thinking backwards. You just add margin to the element you want to space.
I firmly believe the idea that CSS (today at least) is complicated is just people not trying to learn what modern CSS is like. Learn your basics like the box model, block elements, inline elements, etc. Then learn about flex and grid. That right there is like 90% of the knowledge you need to make anything in CSS today.
The way I learned was being given Sketch or Photoshop documents with all the sizes and margins/paddings and told "now make that a website". I really wish there was a learning tool that just had website/website element mockups with sizes and your job is to replicate it as close as possible in HTML/CSS.
> I used to think CSS was complex and everything was a hack
I do web development only occasionally, so I'm not familiar with current best practices and rely on trying to mine the docs for what I'm trying to do and googling for it. I've always very strongly had the impression that while CSS was good at styling, it was hopeless at layout.
That changed with the introduction of flex and grid. Suddenly I'm able to use the layout I want without any real problems. CSS is now usable for both styling and layout.
> I've always very strongly had the impression that while CSS was good at styling, it was hopeless at layout.
> That changed with the introduction of flex and grid.
Half true. Flex and grid are a significant improvement, but "hopeless" was just about always inaccurate. The vast majority of issues people had with layouts pre-flex were because they didn't understand the box model and how block/inline/inline-block/float interacted with each other.
...Unfortunately, not understanding the box model is still a problem, but flex/grid can get people further without needing to understand it.
Devs want composable blocks and design is all about context & harmony, so padding/margin depend on the context, eg I want a flex gap and not margins on elements. Without flex you had to do hacks, like negative margins on the parent row. CSS also doesn't have constraints or relative measurements. For example flex containers without a width can't have equally sized children https://codepen.io/brettdonald/pen/oRpORG). And this is a common theme, you can't elegantly style things based on existing dimensions, number of elements, etc which then you need to work around with media queries or hacks. Also, flex & grid have the same problem as async in JS, when you start building your layout with it, it's turtles all the way down, everything becomes flexbox or grid.
That's what I think people complain about, instead of having tools that solve the few dozen common scenarios, CSS gives us thousands of rules that need to be carefully assembled and still not solve the standard layouts.
There's a debate on the purpose of it. They problem is we took our interlinked document space and built thin client applications on it.
Our crosslinked thoughtworld for intermingling intellects in practice is mostly an entertainment and shopping platform.
Really they probably should have split off when it was young ... Replacing HTML with something for the original lofty goals and leave the html/css/js triumvirate for the mainstream use we all see now.
Then there becomes no pretext that there's any intellectual, educational, or documentarian use for the web because there'd be something else, let's call it the Yeb for those purposes. It'd get two way linking, ontological markup, a WAIS like querying system (where the document author explicitly sets the search up separately from the document), etc.
But that never happened and the web has way too much inertia to successfully fork it at such a fundamental level without a monumental multi-year effort so here we are with one set of standards trying to serve all masters at once by layering stuff on top of each other, building a bigger russian nesting doll to stuff our existing web into (could you imagine if say jstor or citeseer required a "yeb browser" because it served content that was fundamentally incompatible with the web standards. Could have taken off in 1995 but not now)
The only engineering results those conditions ever produce is complexity since it inherently, by design, lacks the focus to remove it.
Alternatively, people are trying to do things with webpages that they really weren't meant for, i.e. CSS is based around document-oriented pages so anything outside of its formatting model becomes more difficult. From CSS 2.1 section 10.3.3:
"If both 'margin-left' and 'margin-right' are 'auto', their used values are equal. This horizontally centers the element with respect to the edges of the containing block."
i.e. horizontal centering is easy because that's a natural thing to want to do in a document, but vertical centering seems to make less sense and is thus correspondingly more difficult.
The web is meant for anything you can build with its tools.
That its tools lagged behind what people were building with them is just a reminder that a platform's caretakers have little to do with the creators on the platform.
This goes for everything. I built a forum from scratch that miraculously exploded into a community and culture and drama. 15 years later I look at it and realize it happened in spite of me, not because of me. It doesn't even feel like any of it's mine. I'm a groundskeeper.
I might have built the scaffolding, but who am I to say what it's for once thousands of people have made that decision for themselves?
"No, no, no. The web is for boring documents of <p> and <img>! What are you people building?! The most complicated application I envisioned when I invented HTTP was Encyclopedia Britannica online, and the limits of my imagination must be yours!"
Oh thank you! I very much agree. But I still, as a dev I often feel the urge to keep things simple and wish that I didn’t have to make so many tradeoffs between structure and layout.
It’s many little things, workarounds that pile up given a sufficiently complex/bespoke page. And each of them feel a little bit wrong. Especially when I have to „fix“ things via JS, which fortunately almost never happens anymore.
> i.e. horizontal centering is easy because that's a natural thing to want to do in a document, but vertical centering seems to make less sense and is thus correspondingly more difficult.
It’s because text wraps horizontally and flows from top to bottom. The width is constrained by the window but the height is defined by the contents of the document. This means that if you are trying to vertically centre something in the document, you need to know the size of the document before you can render its contents, but you need to render its contents to know the size of the document.
There’s various ways around this but they all have different trade-offs, hence multiple solutions to the problem of vertical centring in CSS.
It is simple to vertically center things in PDF's, since you have a fixed dimension canvas and text doesn't change dimensions due to user preferences or device configuration.
So if you want layout to be simple, use PDF. Of course most users hate to read PDF's online, because they have to zoom and scroll around and so on. So the real question if you want the pain on the producer side or push it to the consumer side.
Producing layout which render reasonably well on completely different devices and screen dimensions is inherently non-trivial.
> Is this why the web is less successful than it might be?
No. The success of the web has nothing to do with CSS. By all standards the web has over-achieved and will continue to do so for the foreseeable future of humanity. CSS is an order of magnitude better these days. Browsers are playing nicer together except Safari. Chrome uses more resources than a triple A game title but sets the standard.
Think of how much extra software engineers get paid because of how difficult it is to do simple things. If it were easy, you wouldn’t need a whole team for a crud web app. If everything didn’t break from updates constantly, you wouldn’t need SaaS in order to feel like a piece of software might still work in 2-5 years. It’s a weird thought, I think I got it from a Jonathan Blow stream
The problem is consistency and lack of direction. There are now sane ways to do almost anything in CSS. But they are not exclusive - they live side-by-side with older, less-sane solutions, many of which don't play nice together. Someone ought to write a "CSS: The Good Parts" book about a modern, sane subset of CSS that plays nice together, covers everything you need, and that the industry could unite around.
I often wonder what is the total time and money wasted the last twenty years because "vertical-align: middle" on a div don't do what anyone think it would and should.
Imagine if CSS had that and nesting and variables from the start :)
Is this why the web is less successful than it might be?