Hacker News Reader

Comment by lisper | Hacker News Reader

The mere fact that a site like this can exist and not be a joke is proof that CSS is still badly broken. I should be able to center things by writing:

    foo {
      align: center;
      valign: center;
    }

View on HN

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.

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.

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.

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

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

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.

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

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.

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)

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

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:

    foo<br>baz

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.

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

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.

Or maybe GSS - http://gridstylesheets.org/

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

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

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

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

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.

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

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

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

Every 4 years: "lets check if latest css can center dynamic sized things without a bunch of #container_of_container cruft". Just stick with:

And what the hell does "margin: auto" mean? I'd like to hear some print designers using that in normal conversation. "oh and also i'd like these margin's auto'ed".

At this rate the table tag is going live longer than the copyright on mickey mouse.

No, use divs and table-cell display values if you want to have non-tabular data displayed like a table.

Indeed I have non-TABular data and yet I should use TABle-cell? I'll just stick with the actual <table> then. cleaner. But the real problem is "use divs". plural. so already breaking the #container_of_container cruft rule. I'd rather write some javascript with overly nested callbacks and leave the html clean. thanks.

Yeah, it's obnoxious when people get up-in-arms about specifics. But, you have to admit that it's correct. Why use explicit tables when you can use style overrides to get the look you want and your HTML markup is more meaningful to robots?

But then just admit it, you broke the web separation of concerns rule ("HTML is for content, CSS is for layout"). Which is load of nonsense, if you ask me, but people seem to treat it as a kind of religious dogma.

Do you mean the requirement for a container `div`? If so, IMHO, that is the most routinely broken "rule" in web page design that I can think of. It should be obvious that the technologies involved in web pages are not perfect. I'm not claiming otherwise. It's a question of trade-offs. You're going to break the HTML is content convention whether you use a `table` element or a `div` element with "display: table". So why not just go with the one that's more correct? It's up to you either way I guess.

<table> is content, table-cell: is presentation. Semantic tag use matters because some people are blind and their screen reader will start randomly start talking about some structure that makes zero sense in context

I understand and agree with the general argument, but is it actually true that screen readers for the web are that naive? I would expect them to render a page (like with WebKit) and try to figure out the layout of the page, which things are actually visible, etc., or at least use heuristics to figure out what is and isn't content (in the same way that Readability-esque algorithms presumably do).

> Readability-esque algorithms presumably do

They look for the div with the most text/paragraphs in it and assume that's the article. At least, that's what the open source ones I looked at a while back do -- the proprietary ones that force you to go through their own server could use other tricks.

The browser, not the screenreader, does the rendering, figuring out what's visible, etc. The results, an "accessibility tree" which is sort of a subset of the DOM, are then presented through an accessibility API to screenreader software. Screenreader software is pretty naive, there might be some that initially assume a table is being used for presentation, not data, if it lacks good semantic structure (e.g. no <th> header elements). Case by case, it's hard to tell in which way the author is bad at their job, using a table for presentation or poorly marking up a table for data.

The stakes are much lower for Readability-esque algorithms, when they fuck up the user can just go back to the site's native presentation; screenreader users don't have that choice.

Just a practical consideration, but the HTML table tag is actually a lot more restrictive (<table> can only contain <thead> <tbody> or <tr>, so no wrapping span to regroup some table rows) than using <div>s. Can be important depending on third party libs.

(…and <tfoot>, <colgroup>, <caption>)

`display: table` and `display: table-cell` are just layout algos, commonly used for creating a table-like layout.

You'd rather write unncessary Javascript and/or three nested HTML elements (table > tr > td) instead of two divs and some simple CSS? Man, I'd hate to be one of your clients since you don't really understand front-end development.

I also find it crazy how there was a huge campaign to remove use of the table tag for layout. 'It's non semantic! You're mixing layout and content!' people would cry over and over.

.. But then we've ended up with bootstrap and it's grid layout, where we're doing exactly that, and for some reason it's perfectly fine.

and I wonder how the <ul><li> somehow survived unscathed and free from the semantic witch hunt of yore. shouldn't we replace them with:

This comment doesn't make any sense. A list is a thing, just as a table is...

What are you trying to say?

Down vote for "doesn't make sense". It made perfect sense to me.

The phrase you were looking for is " I don't understand what you're saying."

Then perhaps you would like to explain it? The most meaningful interpretation I can see is that the commenter completely misunderstood the nature of the "semantic witch hunt" to which he referred. It seems charitable to assume that something was lost in translation and to ask for clarification rather than to assume that the commenter was just saying something stupid.

Very true, and such charity doesn't help the discussion. Insisting on the polite path, "I don't understand" instead of "your comment makes no sense" wrongly assumes that all comments written on forums are carefully considered and fact-checked before posting. It's taking the long way to resolution of that point, and you might never get resolution if bogged down in overly-polite discourse for fear of being "negative".

The phrase the poster was looking for was that "the example provided was hyperbole." Your comment is far too confrontational.

If you go down that path, there are no semantic elements left at all.

The "semantic witch hunt" against using tables for page layout exists not because the table tag is a semantic tag, but rather because pages are not tables. Likewise, ul and li tags are semantic, and I think most people would advise against using them for something other than unordered lists and list items.

Of course, the issue would probably come up rarely, since the browser stylesheets for those tags don't do anything particularly useful for anything other than lists and list items.

The objection to tables for layout was never on the basis of grid layouts being bad, it was on the basis of separation of concerns.

The primary problem with layout tables was that they involved tightly coupled inlining of your layout rules.

I have not found a project yet that I could divorce the layout from the content without the use of javascript. i gave css many attempts at this. mainly from the desire to make the content easy to manage for others. or just for aesthetics. but css was (is) too clunky to make that separation. yet people still argue that not limiting yourself to what css can provide you, thereby giving up on the purity of content vs layout separation debate, is somehow blind use of web standards. i've since assumed css's goal was lofty from the start.

I'd agree it's not completely divorced, but it's much, much better than it used to be. If you've worked in environments where the only access you have is CSS (for instance, locked down CMSes, or editing subreddits), you'll find that many solutions are possible without manipulating HTML. CSS can be very powerful; especially with the advanced selectors of CSS3.

I think I'd rather just manipulate HTML with Javascript. At least then I only have one problem, which is HTML with inline styles. No separate CSS file to maintain or CSS rule precedence to worry about.

You forgot the performance problem....

And anyone who wants to browse with JavaScript disabled…

People who disable features of their browser on purpose will always be getting a degraded experience. No way around that.

People have JS disabled without their intent. Corporate security standards, broken JS in CDN served libraries, mobile proxy browsers, the list goes on…

With the rate CSS is accumulating kludges and the fact that, when together with HTML5, it has already crossed the Turing-completeness threshold, I wonder how long it will take before companies start requiring browsers to disable subsets of CSS...

I stopped worrying about those users years ago. Don't even bother with <noscript> anymore. It's 2015 and all browsers support JS these days. If you disable browser features then you really shouldn't be surprised when functionality breaks. The same would happen if you disabled CSS or images.

Funny you should invoke turning off CSS and images -- a lot of people have actually worked pretty hard to make standards that would work for cases where visitors had them disabled, or want low bandwidth options, or had their own custom style sheets, or weren't using a visual user agent (or even, for that matter, directing the user agent manually).

A failure of function availability from turning off images or CSS is a failure of developers, not a failure of the platform or user agent. You can find sites even in 2015 that either straight up work or degrade gracefully when being browsed by Lynx (a browser that I don't think has seen even a dot-release update since 1999) because they were put together by thoughtful professionals who understand the platform.

If you're trying to deliver an application that absolutely requires client side computation or specific browser APIs, you can have a pass for choosing the have your site not work without JS.

If your site really is just a series of documents (either static or dynamically computed), though, there really isn't much of an excuse.

>a lot of people have actually worked pretty hard to make standards that would work for cases where visitors had them disabled, or want low bandwidth options

In cases like this, wouldn't it make more sense to have that information available in an API? Once you've removed all styling and interaction, it seems like something that would work better as simply sending raw data, and letting the client decide what to do with it.

Schema.org is a good example of how this would work with the modern web. Markup relevant data (eg. product ratings, movie times) and let the clients render it as desired. You can still provide CSS/JS for modern browsers.

Seems a lot more elegant to me than designing pages to gracefully fallback when JS/CSS is missing, as that would seriously restrict design.

When you say "simply send raw data, and let the client decide what to do with it," you're more or less describing the original vision behind delivering markup before we got obsessed with instructions of one stripe or another to control visual presentation.

The crucial question is probably what's considered "raw" -- or perhaps to talk more in terms of web-related philosophy, which media type you'd expect most user agents to be able to handle by default... and despite the (reasonable) popularity of JSON, the answer is pretty much HTML with some kind of microformat information embedded via attributes.

In other words, the schema.org approach is arguably pretty much what you're supposed to do in order to design pages to gracefully fall back. I'm not sure why you might think those two concepts are at odds. :)

Have you seen some of the amazing things that can be done even in css 2.1?

Honestly sure you need js for most interactions and animations still, but layout? I wouldn't merge any pr that uses js for layout. Including fully responsive layouts.

I think CSS Zen Garden still exists...

And this is absolutely the only place where "separation of content and layout" works. In real world, layout often is a part of content - but instead of accepting that, a lot of developers like to proclaim that their code is soo semantic, and the metric ton of grid layout divs in their "content" is not tables in disguise, but definitely has some important semantic meaning...

Seriously, I don't know what's more broken - CSS itself or the web developer community, with the amount of self-deception, cargo-culting and stockholm syndrome cases present there.

It worked perfectly fine for me from ~2004 and forward. I guess the bigger problem is that web tech is considered somehow not important so lots of developers did not really bother to unserstand CSS. I think around 2005 we had a golden times of the web. It went downhill since, sadly. Prolifereation of one-page web apps, stupid desire "to win mobile", mindless spawning of all kinds of frameworks turned out into complete mess :(

Funnily, 2005 was the time when people were misunderstanding JavaScript. I still have nightmares from all those animated snowflakes and rainbows following my mouse cursor, or date calculators embedded on every other page for no reason except to show off...

Unfortunately, CSS doesn't really fix that problem.

If you're writing it properly (i.e. not inline), it actually does. Even more so now with SASS & variables.

Check out http://camendesign.com/ The last time I looked it had no ids nor classes.

That's pretty nice, actually.

This owes at least in part to the fact that tables are not optimized for page layout. And that was especially true 10 years ago. Popular browsers couldn't render partial tables, and you had even more performance problems nesting them.

Grid based layouts are obviously useful but the table tag isn't the right tool.

The problem with tables for layout is that the layout algorithm is incredibly complex. People seem to think it's simple, because it kinda does the "right thing" in many cases, but it's actually ill-defined, varies between browsers, and has only a work-in-progress spec [1]. Width calculation is defined in terms of linear interpolation between the closest of four "candidate guesses" which bound the available width. And that's the simple case, when no colspans are involved; check the WIP spec for details on the recurring sequence that is involved when there are column spans…

Regardless of how you feel about CSS 2.1, it's indisputably better than the table-based layout we had before. Speaking as someone who has implemented both table-based layout and CSS 2.1, it's really unfortunate to see people want to return to the bad old world.

[1]: http://dbaron.org/css/intrinsic/

A basic rule of universe is that complexity remains, you can merely shift it around. The table layout algorithm might be incredibly complex, but I'd rather have a browser writer have the headaches than me.

> The table layout algorithm might be incredibly complex, but I'd rather have a browser writer have the headaches than me.

Completely disagree. The Unix philosophy is right when it comes to layout: you want to be simple, fast, and predictable.

This attitude is also why we are in a situation where the Web is slow compared to native platforms. Simple things tend to be fast things. Complex things tend to be slow things.

And the things you do to properly align stuff in CSS are anything but simple. You took the complexity from the place where it could be well-defined and heavily optimized and have it to the hands of every developer to do it in their own, broken way.

I fail to see how centering something in flexbox is complex. It's literally one property once you've switched to the new mode. And absolute centering is really simple once you understand how containing blocks work.

Your implications that table layout can be "well defined" or "heavily optimized" are both false. The problem is that table layout is ill-defined: it's really a pile of hacks upon hacks that were invented at Netscape a long time ago and still not standardized or consistent between browsers. And, speaking as someone who optimizes layout engines for a living, complexity is the #1 enemy of "heavy optimization". Spec complexity is the #1 reason why layout is so slow, because it makes layout engines large, complex, and brittle.

The attitude is the result of a thing that just keeps annoying people. It's certainly not a cause of a slow web.

Given that the problem is not simple, I'm happy to have fast and predictable.

> A basic rule of universe is that complexity remains, you can merely shift it around.

Not really. CSS grid systems (like in Bootstrap) require some ugly and non-semantic markup, but they're not very complex.

Also, [0], since “All problems in computer science can be solved by another level of indirection, ...”.

[0]: https://www.ostraining.com/blog/coding/bootstrap-right-way/

StackOverflowError

No, what he really meant by complexity is information content - will always remain - you can compress it (akin to writing complex code) or uncompress it (akin to writing more code), but whatever you wanted to express you'll still have to express. This principle you can also find in all domain specific languages and in all frameworks that started out as easy and lightweight and become groteskly inflexible and ugly monstrosities after a while when the rest is being added to make them complete in all respects.

They don't require non-semantic markup -- as I said in a comment that was downvoted for some reason. There's a whole set of best practices that people aren't mentioning in this thread.

If you write your styles in the same preprocessor as the Bootstrap package you chose (Less by default, but optionally Sass), you can mix Bootstraps grid classes into your own semantically meaningful classes, and drop all the col-xs stuff from your markup. Your markup elements can have class names that are purely semenatic. Almost every modern grid system offers preprocessor mixins that can be used in this way.

There are methodologies like BEM that are great for providing a semantically meaningful layer of classes in your markup.

It's true that the complexity remains and is shifted. The important part is that it's no longer interlaced with the complexity that describes the fine-scale structure of the page.

There have been some huge deficiencies in CSS over the years. It is frustrating to have to use complex sets of counterintuitive rules to achieve seemingly simple effects. But there are techniques for helping to manage it in modern web development.

A basic rule of universe is that complexity remains, you can merely shift it around.

You can always increase complexity. For instance, by doing all math in Roman Numerals. Thus, in at least some cases you can decrease it. So your statement doesn't hold.

I think you were referring to something like inherent complexity, but then you would have to somehow prove that all this complexity is inherent.

> because it kinda does the "right thing" in many cases, but it's actually ill-defined, varies between browsers, and has only a work-in-progress spec

Which is completely not like using CSS at all, right?

Like I said, I've implemented both. CSS 2.1 was much easier than tables. Almost everything I implemented in CSS 2.1 made sense (with some notable exceptions, such as the hypothetical box, margin collapse, and border collapse). Tables were nonstop backwards compatibility hacks.

I agree and it really bothers me that all the markups in modern web pages are littered with COL, span, md, lg, xg, 1/2 2/3, with gibberish nestings. Semantic web went out the window, in favor of responsive web.

The whole web is fad-driven, so I'm glad at some point, pendulum will swing back.

Meanwhile, I'm just happy parallax fad is dying out.

Allowing an arbitrary website to work on a phone isn't really a fad, though. In a few years time, there's not going be a huge sigh of relief as everyone gets back the fixed-width websites they've been crying out for.

"Allowing an arbitrary website to work on a phone isn't really a fad, though." Agreed, but current implementation is mostly terrible, with 6 break points, 1-2MB downloads, everything = single page app, etc. So the concept of write-once, run everywhere is not a fad, but the implementation is very fad-driven.

Ah, that's fair enough; I was thinking at a more conceptual (or even just CSS rather than JS) level.

Thank you for saying that. The last 15 years have seen tremendous heat and noise exhausted in fantastical debates the end result of which brings no obvious improvement. If we were honest, we would say something humble, such as "Sir Tim Berners-Lee is a great genius, and we are all grateful for what he gave us in 1989, however, since that time, we have learned many things, and the technologies proposed then did not give us what we actually need. HTML strains to fulfill two discordant goals, one is to give us structured documents, and the other is to give us a GUI for TCP/IP. But we now realize these two goals would be better served by two separate technologies, and HTML should be retired."

> But we now realize these two goals would be better served by two separate technologies, and HTML should be retired."

This. And the confusion around those two goals is what drives a lot of useless arguments with people who have Stockholm syndrome towards HTML and CSS. Those arguments can often be summarized like this:

- Hey, we're complicating things too much, how about just focusing on rendering a text communicating a message?

- No no no, the web is not just about documents, it's so much more now! It's about applications.

- Ok then, so let's drop the nonsense about separation of concerns, that you can have layouts separate from content.

- No no no, HTML is for describing documents, and CSS is for describing its layout!

Just starting to realize how out of touch HN readers are with CSS. This mindset does not belong in a conversation about CSS in 2015.

You can use semantically meaningful class names and use the mixins from the Bootstrap source. Even though it's probably common practice and great for you know, bootstrapping, I don't think it's good for maintainability to leave the column classes in the markup. In a large, modular, front-end heavy project, proper separation of content, presentation, and other cross-cutting concerns really pays.

Open up any webpage and count how many divs with no other purpose but to serve as CSS anchors there are. We traded in non-sematic tables for non-sematic divs.

Except that div have no semantics by definition.

The <div> element has no semantic meaning, screen-readers don't read them and they have no intrinsic behaviour unless associated with an aria tag.

Why couldn't we just have made non-semantic tables? In addition to the semantic tables, I mean.

Divs with display:table/table-row/table-cell _are_ non-semantic tables.

except divs lack colspan

There's (almost) always a way round a problem. In the case of colspan, try this:

http://jsfiddle.net/5cUW7/8/

I came across this issue recently and was surprised after all these years there still isn't colspan support. Ended up having to create additional containers when I should be able to style it using CSS.

Which would actually be somewhat helpful, come to think of it...

adding role="presentation" to a <table> element will tell screenreaders to treat the element and its required children as non-semantic. I still say using a table for layout (of non-tabular data) is should be a last resort but it's easy for me to say since making a layout is rarely my job.

Browsers should e.g. allow tables to be sorted by clicking column headers. They can't, because tables aren't always tables.

How about an opt-in attribute to enable ordering then?

Kinda. I used to agree with you for the longest time, but I can relatively easily make a CSS bootstrap page responsive, because I can override the bootstrap CSS, but there is no way to override the behaviour of <table>.

Tables nested in tables nested in tables was a fate worse than divs. Even in the simplest case (one box) a table stinks: <table><tr><td></td></tr></table>. I personally found that trying to debug which table a <td> belonged to was hell on earth.

Comparisons to print designers misses the biggest point about web design, that is that we have no way to guarantee a width, a position or even choice of font. Print designers know an A4 page is always 210x297mm, web designers have no idea what to expect.

But if you are still using the table tag for anything but tabular data, you're living in the 1900s and arent cut out as a modern day web designer /snark

Yes, you are right. As long as people are using HTML mail, tables for layout are the only way to go.

I have a gift for you! : /s

You just made the best case for Markdown email that I've seen.

Author email in straight text? Markdown is what you're writing already.

Author it in WYSYWIG/GUI clients? You only care about presentation.

Ok, now make it repsonsive, e.g. one column should be below the other on the narrow screen.

By the same dint, web designers don't talk about paper weights and finishes. It's crackers, almost as if the two sets of designers are using different technologies.

> And what the hell does "margin: auto" mean?

It means "calculate the margins automatically according to available space". Nothing complicated about that.

Print is quite different from web. The most noticeable difference is that paper cannot be resized, nor does it adapt it's content when you rotate it.

Your example does not align vertically, so I am not sure what you are trying to prove. This CSS will put something in the center of your screen quite easily

    position: absolute; top: 50%; left: 50%;

Is that so hard? Having poor CSS skills is not the same as CSS being broken.

Unfortunately, that's telling your div to start halfway. Following your suggestion leaves me with an element with its top left corner in the exact center of the containing div.

I'm not a fan of CSS due to issues like this. It falls in the same line as issues where, for example, paddings and margins (and borders) are added to the size of your div rather than subtracted. There's a solution for that that makes sense nowadays but by the time that came about, I'd already stopped liking CSS.

The mere fact that the site exists means nothing. Any problems around centering have been completely solved by flex box. If you're targeting obsolete browsers, you're going to have to expect to do some legacy hacks.

Heh, generally any time there is a site with a name that is a search query it is an SEO hack. I was surprised it wasn't plastered in ads :-)

That said, centering (and typography) in CSS and elsewhere is that you mix passionate people with a really hard problem and you don't get answers, you get a lot of debate. I used to read the alistapart mailing list and it was intense at times. Suffice it to say that when the content of part A and part B are different by 1 screen pixel, and you're centering, do you assume +1 pixel or -1 pixel? (You don't get 1/2 pixel resolution) a typically large debate

A tool is not broken if people insist on using it in ways it was not designed to be used.

The fact that you say there is no easy vertical center, of which I disagree, doesn't make it broken. It means it's missing a feature you wish existed.

> it's missing a feature you wish existed.

indeed, an extremely basic and fundamental feature than any site that implements popups could use.

And yet, popups seem to work just fine without this missing "basic and fundamental" feature. There are numerous ways to handle the problem that is legitimate and valid.

It really isn't.

There's this misconception that CSS is a display language; it's actually designed as a typesetting language that must degrade nicely.

At least you can do horizontal alignment by throwing in the towel and using <div align='center'>.

Vertical alignment is the real killer.

It's actually a consequence of the CSS box model, which makes a lot of other things simpler, and means that figuring out how to position things isn't turing complete or something.

I think the secret is that maybe 10% of CSS writers actually have read more than the bare minimum to getting their layouts to work ( I am not among them, mind you).

Pretty simplistic/naive.

Reply on news.ycombinator.com