> 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).
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.