6 ms·

> it’s still complex to do simple things that everybody wants. People underestimate the complexity of layout. Take vertical centring, for example. The immedi

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

newsbinator 6y ago
I'd like to be able to say: .child-element-selector { centered-inside: .parent-element-selector; } And let the browser figure out what I mean, taking into account border widths and parent element padding, for example.
- dsego 6y ago
  But muh job security.
hombre_fatal 6y ago
Yep, GUIs are always hard. 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 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.
- hugi 6y ago
  I much prefer doing MacOS or iOS layout work rather than working with the absolute clusterfuck that is HTML and CSS.
  - hombre_fatal 6y ago
    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.
stormbrew 6y ago
> 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.
- goto11 6y ago
  > 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.
  - stormbrew 6y ago
    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.
    - goto11 6y ago
      > 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.
unabst 6y ago
> 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.
- goto11 6y ago
  > 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.
  - unabst 6y ago
    > It requires a more complex layout Yes and no. 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".
wruza 6y ago
>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. So let’s make it hard even for simple cases. Meanwhile, el.centerX = other.centerX el.centerY = other.centerY 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).
thaumasiotes 6y ago
> 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.
- olau 6y ago
  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.
- yen223 6y ago
  The height of an element depends on the layout, thanks to overflow
im3w1l 6y ago
I haven't looked into this in any depth but what about modeling it as an equation system? Over/under specified solutions would be an error.
- zodiac 6y ago
  ios layout (autolayout) is like that. I generally prefer it to css, but it's not perfect either.

newsbinator 6y ago

I'd like to be able to say: .child-element-selector { centered-inside: .parent-element-selector; } And let the browser figure out what I mean, taking into account border widths and parent element padding, for example.

dsego 6y ago
But muh job security.

hombre_fatal 6y ago

Yep, GUIs are always hard. 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 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.

hugi 6y ago
I much prefer doing MacOS or iOS layout work rather than working with the absolute clusterfuck that is HTML and CSS.
- hombre_fatal 6y ago
  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.

stormbrew 6y ago

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

goto11 6y ago
> 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.
- stormbrew 6y ago
  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.
  - goto11 6y ago
    > 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.

unabst 6y ago

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

goto11 6y ago
> 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.
- unabst 6y ago
  > It requires a more complex layout Yes and no. 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".

wruza 6y ago

>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. So let’s make it hard even for simple cases. Meanwhile, el.centerX = other.centerX el.centerY = other.centerY 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).

thaumasiotes 6y ago

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

olau 6y ago
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.
yen223 6y ago
The height of an element depends on the layout, thanks to overflow

im3w1l 6y ago

I haven't looked into this in any depth but what about modeling it as an equation system? Over/under specified solutions would be an error.

zodiac 6y ago
ios layout (autolayout) is like that. I generally prefer it to css, but it's not perfect either.