Hacker News new | comments | show | ask | jobs | submit login

You're in luck.

    foo {
        display: flex; /* opt into the new box model */ 
        justify-content: center; /* "align" */
        align-items: center; /* "valign" */
Vendor prefixes may or may not ruin your day (for now), but the spec is there and is exactly what you want. CSS is no longer "badly broken" if that's your metric.

Sweet. I figure only 15 more years until we get two column layouts working, and then we'll finally be able to publish like it's 1979.

CSS multicolumn layout is four years old. It's implemented in all the major browser engines, and many popular sites like Wikipedia use it. http://www.w3.org/TR/css3-multicol/

Only partially. You usually have to use browser prefixes to get it to function. http://caniuse.com/#feat=multicolumn

Add Autoprefoxer in your build process and never type them again.

That is not CSS anymore, it's "CSS + autoprefixer". Which, I agree, is great, but it's worth mentioning. Vanilla CSS requires the prefixes, "CSS + autoprefixer" doesn't, but it requires other things like an extra build step (and a build process, at all). Worse, it could be mutually exclusive with other tools.

When you advocate an add-on to an existing solution, you're changing the solution. It's like people who recommend typescript in reply to JS's lack of types, or Coffeescript to its ugly syntax: you can't have both, they change the original thing. Or vimperator with firefox, or vim-mode emacs, or... it's all not the same thing anymore. You push the carpet down in one place, it comes up in another.

CSS still requires the vendor prefixes. If autoprefixer is the perfect solution to that, let's stop people everywhere from using vanilla CSS and switch them over to "CSS + autoprefixer". Turns out it's not that easy, which gives the original "but it requires prefixes" argument more meat.

Or use Bourbon mixins (http://bourbon.io/docs/) if you use SASS.

SASS mixins are great, but Autoprefixer is better for prefixes: it looks the same as writing actual CSS (just with no prefixes) and has no cognitive overhead during editing. Compare the Bourbon mixin:

    @include background(linear-gradient(red, green) left repeat);
to autoprefixer:

    background: linear-gradient(red, green) left repeat;

AAAAaaand we're back to 7 solutions to a simple problem

How so? Autoprefixer allows you to just write spec CSS and let it worry about prefixes.

That's not a solution; that's a workaround.

Like I said, "working". I don't want two columns stretching ten feet long. I want two columns on this page, two on the next, two on the one after that...

That is indeed how multicol works when combined with pagination [1].

[1]: http://dev.w3.org/csswg/css-multicol-1/#pagination-and-overf...

I'm pretty sure flexbox can solve two column layouts very well, just not with one continuous piece of text.

It would seem there is less than 92% support for flexbox yet.

Better go back to print, then.

So fall back to display: table for the garbage browsers. This is not difficult stuff.

Hm, had you said 1978, I would have gotten the reference (Spoiler: TeX, though maybe not really 2-column at the time?). Did you have something specific in mind when writing 1979?

"Did you have something specific in mind when writing 1979?"

Probably the Prince song "1999" (party like it's 1999...) combined with the general era in which this stuff was figured out in non-web digital contexts.

1984 with the introduction of the Macintosh, would be a better year to have picked, as it could be considered the beginning of the desktop publishing revolution.

Unfortunately, though flexbox is nice and a welcome addition, it's not the panacea people make it out to be having used it a fair bit in the past - the details of how it plays with the rest of the layout and the various options are complicated (see http://www.w3.org/TR/css-flexbox-1/ if you don't believe me), and sometimes the interactions are confusing.

I still think there's scope for a language that compiles to CSS but allows totally intuitive positioning, provides error messages if you make a mistake and generally isn't as infuriating as CSS is. The amount of times I've done something which seemed like it really ought to do what I want and the layout doesn't change is unbelievable. Even assuming vertical alignment is totally solved by flexbox it's still an agonisingly painful thing to work with.

Maybe this can clear some things up: https://css-tricks.com/snippets/css/a-guide-to-flexbox/

I've been doing flexbox heavily for nearly the past year, and that post is my go-to reference, because I still can't remember all the properties and values. Highly recommended.

It's legitimate for people to point out that these fixes are not universally available, because many people still need to support old versions of IE.

That said, I think it's important for people to understand that many of the problems that people have canonically associated with the web's incompetence have been "solved" in standards for a number of years. There's a real difference between problems that remain unsolved in all browsers and problems that do not remain in the current versions of all browsers.

That difference may seem moot until the features are universally rolled out, but understanding that a solution to centering content rolled out in all major browsers (including Internet Explorer) three years ago may help us get past a sense of learned helplessness about the web.

Yes, improving the platform takes time, but by making browser vendors aware of the problems we face as web developers, things do get better.

The problem is that it doesn't matter only to IE, but to every version of a specific browser.

Nowadays people are not only using desktop computers. Many of the computer form factors used nowadays almost never update, yet one needs to support them.

EDIT: Typo version => browser.

This is a big step in the right direction, but I'm afraid it's still broken. Centering things in this way breaks the <BR> tag. It works inside text but now fails between elements. For example:

renders correctly as

foo bar

but <span>foo</span><br><span>bar</span> renders as foobar.

And AFAICT it doesn't work at all in Safari even with vendor prefixes.

The <br> tag is defined as a tag that inserts a newline with generated content using pre-formatted whitespace. It only works between blocks because of anonymous block element generation. I'm glad that the flexbox spec didn't require some sort of anonymous block element generation; it's really complex as it is and adding anonymous blocks to flexbox would have been hideously complicated.

It's just too bad you have to add comments to understand what "justify-content: center" means. I mean, I guess it was too much trouble just to give it the semantically correct names.

Seems semantic to me. What would you suggest instead?

align: center; valign: center;

But what are you aligning? It seems to me that having "justify-content" is more semantic than "align".

Flexbox is nice and makes some things easier, but its still (IMHO) a half assed solution compared to something like QML's anchors.

In QML I can center like this:

    anchors.centerIn: parent
(replace parent with id of item you want to center in if not the parent item). You can also do just vertical or horizontal centering, or you can fill another item or you can anchor eg the left of your item the the right of another item and the right of your item someplace else and it resizes/repositions your item as required.

Flexbox still often requires lots of nesting to achieve what should be (and is in QML) relatively simple layouts. I've also hit a few things that I couldn't do at all with Flexbox (although that could just be lack of CSS/flexbox skill on my part - but to that I say that CSS gets very hard quite fast, while complex layouts in QML are pretty easy).

That is why CSS Grids are coming: http://dev.w3.org/csswg/css-grid/

Like flexbox, this looks like a definite improvement over what we have now, but it looks quite complicated with less than ideal syntax. I imagine that's mostly to do with playing well with existing CSS (syntax and semantics) but its rather unfortunate. I looked at a bunch of the examples and found them quite difficult to figure out, but when I started with QML, I saw one snippet of sample code and immediately was able to create complex layouts myself.

Don't get me wrong, I'm glad CSS is getting better and will look forward to the day when I can use this (but lets be realistic, it'll be a while yet before enough browsers support this to be usable), but I can't help but feel that its cruft built on top of cruft and that it won't ever be as slick and simple as something like QML.

Are they really coming? I only see it in IE.

I would love a flexible anchoring system like QML for CSS.

Flexbox has made our life much better. But we still run into a bunch of implementation bugs, meaning that it will take a few more years for the promise to become reality: https://github.com/philipwalton/flexbugs

i use this waty to solve my center problem,truly it works,but it lead other problems,like this:<div>test test <span>test test</span>test test <span>test test</span></div> the flex will ruin the layout of the div,so how can i solve this problem?thank you

Spans are stripped out by Outlook 2010 in HTML mail. This is not edge case, as you may think. Most corporates are still on Outlook 2010 (and IE 6, especially large banks in the UK).

Outlook 2007+ use MS Word as email layout engine, instead of Trident (Internet Explorer). MS Word "web view" is based on Frontpage (which itself forked of trident) and produces broken HTML 4 output.

The HTML email world is stuck with HTML 4.1, inline CSS and many corner cases (worse than the IE6 era!).

> The HTML email world is stuck with HTML 4.1, inline CSS and many corner cases (worse than the IE6 era!).

It might be for the better, actually. HTML5 and CSS3 are Turing-complete[0] so I can imagine that the moment they would be allowed, some clever marketing company would figure out new and impressive ways to use the new features to scam people. Er. I meant, "provide value-added content".

[0] - with user closing the loop, see http://beza1e1.tuxen.de/articles/accidentally_turing_complet... for links to an example.

Even if the user didn't have to click on each box, that's not even close to turing complete in the problematic sense. It requires a new line of html for every cycle. O(n).

You can do worse with less.

It doesn't belong on that page.

(Hint: basic arithmetic is turing complete if you give it the same affordances)

First, thank you for the information. It is still very much an edge-case, though. Most HTML ist published on the web, not in emails and most emails are plain text. A few have very simple formatting in HTML. Very few actually have a complex layout, and how many of those could possibly benefit for vertical alignment? And that tiny fraction, if viewed in Outlook 2010 will display - well - not centered.

Sorry for my late reply. HTML email is separate media and separate (very large) business. Cost per lead acquired by using HTML mail is high. So is its market value. So any tool that makes life of HTML mail designer easier will be very much appreciated. Look at litmus.com business.

And if you use something like Compass, the prefix stuff is taken care of for you http://compass-style.org/reference/compass/css3/flexbox/

Funny, because you say he's in luck and yet, that isn't at all what he wrote. At all.

The only differences are that you have to opt into the new box model (required, because "justify-content" and "align-items" are incompatible with the old box model) and the names are different (which is a good thing, because one of the important features of flexbox is that you can switch from vertical to horizontal layout very easily).

I think I'd still CSS is badly broken, until this is available everywhere.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact