If this is supposed to work, then by reduction, having more information about height/width is unnecessary for both browser and CSS programmer. Why not just always use those two forms?
What you've posted will only center a `<div>` with a known width (ie, for `margin: auto` to center a child element within its parent, the width of the child must also be specified).
Not sure if you're mistaken in your comment or there's a bug in the site. When I select all unknown dimensions and a block-level element, it gives me a flexbox output (the right answer, IMO).
Every time I need to center a div, I have to google how to do it. I really hope this site ranks above the fold... because i'm going to forget the URL, and in a few months i'm going to google the same stackoverflow answer I search for each time.
There's a way to centre variable width block elements that doesn't depend on flexbox, which is:
.centred {
/* Make the element only as wide as it needs to be. */
display: inline-block;
/* Let us apply positioning. */
position: relative;
/* Move the left of the element to the middle of the container. */
left: 50%;
/* Translate backwards half the width of the block, thus centring it. */
transform: translateX(-50%);
}
I use a similar trick all the time, especially for vertically centering elements. Also, mine usually includes the various vendor prefixes for the browsers.
That reminds of Zed Shaw's angry CSS rant in https://youtu.be/_CEBG_s92P8?t=525 It's on the obnoxious side, and has a lot of foul language, but it's interesting.
I'm in the midst of a (long, long overdue) redesign on the principle site I maintain, and just discovered flexbox. It's kind of jaw-dropping how much simpler it makes everything. Flexbox plus box-sizing: border-box allowed me to solve in about fifteen minutes layout problems that had previously taken me a few days and poking and Googling and cursing.
I have checked your work out, I like it. Go further.....there's a real opportunity for someone to build deep and wide Flexbox development tools, which just don't exist right now.
I'm completely on board with ignoring IE at this point. Even Microsoft is through with it. With its declining market share and quickly expiring install base (Vista kicks the bucket next year, 7 in 2020) the benefit of mangling my codebase to support the dying browser just isn't worth the cost to me anymore.
Tables are meant for displaying tabular data, they are not meant to be an invisible frame or grid for page layouts but this is what they were often used for.
Tables fell out of favour because many people used nested table structures which were messy and inaccessible to people with screen readers. (Note that non-nested tables are not inaccesible to screen readers.)
I actually think a table-inspired layout approach for CSS would have been simpler to understand and to implement than the clumsy, messy CSS methods we currently have. Even Flexbox has an over-engineered (or over-complex) feel for some of its rules. Oh well, the benefit of hindsight...
The hilarious part is the memo "don't use tables" was so completely absorbed it became rare to see a table even being used for tabular data. A whole slew of CSS to achieve a table-like effect was fairly common to see.
When specifically was CSS explicitly and officially said to be for layout?
As I remember, it began as styling, and people started using it for layout, and that became the best practice, though not official. I don't recall the announcement that its design was for layout, but I wasn't keeping up on the news at that point.
And since CSS is officially said to be supporting layout, why aren't they thinking of all web use cases?
If CSS is not for layout of complex applications, what should one use in that case?
<div style="margin-left:auto;margin-right:auto;"> (DIV) <div style="text-align:center;">Text Content</div> (TEXT)
If this is supposed to work, then by reduction, having more information about height/width is unnecessary for both browser and CSS programmer. Why not just always use those two forms?