Hacker News Reader

Comment by jonahx | Hacker News Reader

One of the wonderful ironies of CSS is that after years of puritanical preaching about the evils of non-semantic table elements, the best-practice recommendation for centering a div of unknown dimensions, assuming you want any kind of legacy support, is[0]:

    <div style="display:table;">
      <div style="display:table-cell;vertical-align:middle;">
        <div style="margin-left:auto;margin-right:auto;"></div>
      </div>
    </div>

[0] http://howtocenterincss.com/#contentType=div&horizontal=cent...

View on HN

One could make the argument that having table layout behavior decoupled from a specific tag is a perfectly desirable state of affairs. One of the issues with using tables for layouts is the massive clutter of row and cell tags that make the markup extremely difficult to read. Being able to assign those behaviors when and where you need them is the best of both worlds.

The irony is that what we are doing, semantically, is "centering." Yet to express that concept we are forced to refer to the entirely unrelated concepts of tables and cells, only because of the historical accident that table elements were the only way you could do many types of centering because CSS lacked basic facilities for layout.

Also, naming issues aside, we are forced to pollute our markup with pointless, unsemantic container divs simply to achieve a basic style on the contained div.

I doubt you understand what the word "semantically" means. I don't see how polluting markup with <table> (and tables were often nested), <tr> and <td> is any better, not to mention that often already existing markup was sufficient and no extra was needed. Also, div's by definition have no semantic meaning, and that's a good thing—those who bothered to care know that tables for layout had their share of accessibility issues. Alas, now when most race to stuff as much anuglar bootstraps ino their SPA nobody cares about semantics and accessibility any more.

I think he's right. The syntax says "display this stuff as a table and a table cell", but what in fact we mean is "center this thing". The fact that both "style as a table" and "center" attain to the visual aspect doesn't change the fact there is a semantic difference between the two.

Also, if divs have no semantic meaning in the context of the document's structure, it means they serve some other purpose: and that purpose is visual styling (not directly but through a css applied to them). How is this not a violation of the separation between document structure and presentation?

There can be reasons for grouping a set of elements in the DOM with a parent div besides styling. But sure, it's a "violation" but web standards do not say "you must only use elements that are essential to the semantic structure of the document." I'd say the guideline is "start with semantic elements, add others as needed for styling, programmatic access, componentization, etc."

It is in principle a violation of the separation between structure and presentation, but it is not a violation of the semantics of HTML which is a bigger issue. Since div's are semantically neutral in HTML, a multitude of "presentational divs" will not confuse screen readers and so on, as the use of <table>-elements will.

That said, separation between structure and presentation is desirable, and the necessity to use multiple divs to achieve a layout effect means CSS 2 is not as powerful as we could want. The grid model in CSS 3 is much more powerful, and allows things like separating the presentation order from the structural order.

Cute, but in discussing the web, its the semantics of the HTML to be concerned with, not CSS properties or values. There are tons of examples of CSS where a naive reading would not suggest the desired outcome. Maybe that should be improved but generally it's better to have the mess there than in the HTML (or JavaScript).

Yes, it's better to have fewer divs that serve no purpose but to create the desired visual effect. As someone else suggested, in your example you probably don't need <div style="display:table;"> so it only requires adding one container div.

> Cute, but in discussing the web, its the semantics of the HTML to be concerned with, not CSS properties or values.

Why wouldn't the principle be applied everywhere? Expressing your intent -- writing semantically -- is a general principle of clean code, and of clear communication in general.

It's fine if you want to argue it's more important in html than in css, but that doesn't grant a pass to the creators and proponents of pure CSS who peddle the ideal of semantics with religious zeal and then fail to apply the principle to their own language, or even to realize that they've failed to do so because, I suspect, many of them don't actually grasp the true goal of the principle -- clarity and usability.

If they did, CSS wouldn't be the unusable mess of quirks that it is.

You are comparing apples to oranges. Semantic HTML is important because it is a publicly defined semantics and various consumers and user agents are programmed against this semantics. Semantics in class-names, the choice of inline styles vs style sheet etc. are purely for maintainability, e.g. you don't reduce accessibility for anybody if don't use semantic class names, at worst you make it more difficult for yourself, but that might depend on your workflow etc.

There is nothing in your response which is an argument against what I wrote. I grant everything you said is true -- it does not minimize my argument at all.

Who are these zealots you reference that demand semantic HTML and have some influence over CSS specs?

What I more often see is people advocating for using semantic HTML, because it exists, and separating concerns (content & presentation). If there was a choice to use CSS properties and values that better conveyed the presentation intent (what you might call its semantic value), they would advocate for that as well.

I think you have the causality backwards though. Tables were used for layout before CSS existed. When CSS was created, it was designed to mimic exactly what was possible to do in HTML, in order to ease the transition to CSS. This is why CSS has a blink-attribute, and why the float and vertical-align properties based exactly on the layout model of Netscapes presentation html (which was defacto standard at the time). Hence the display:table-* properties which mimics the layout of html tables as designed by Netscape.

> I think you have the causality backwards though. Tables were used for layout before CSS existed. When CSS was created, it was designed to mimic exactly what was possible to do in HTML

That's exactly what I said. I think the difference is in our interpretation of that causality: you see it as an intentional concession in the name of backwards compatibility; I see it as a failure of imagination.

Or maybe the ability to imagine the fate of CSS if it wasn't backwards compatible with the HTML layout model :) That said, I look forward to when CSS3 flexbox becomes widely supported. Still I'm happy that we at least don't need presentational HTML anymore.

> Or maybe the ability to imagine the fate of CSS if it wasn't backwards compatible with the HTML layout model :)

You seem to be misinterpreting my arguments -- I'll assume not deliberately. They could have easily provided the same facilities for backwards compatibility of table behavior while also providing clearly-named and usable methods for doing things as basic as centering.

Is your position that CSS is a thoughtfully, well-designed system for presentation, and that the complaints of 95% of professionals web developers are the result of their own misunderstanding of it? Can you imagine taking such a position on user complaints as the CTO of a private software company?

CSS does provide both - the table model from CSS2 provides parity with HTML tables, the flexbox model in CSS3 provides an easy way to center blocks and other nice flexible layout features.

I do believe most complaints about CSS is really complaints about missing and buggy implementations in browsers. For example for years I have seen people complain that CSS is not as powerful and simple as html tables, when the issue really was that Internet Explorer didn't support the display:table properties from CSS2, which meant you either had to use hacks with floats (which was never designed for this) or use html tables. This gave CSS a bad rep, when it really was IE that was to blame.

Honestly I can't say that modern html with its clutter of div and span tags is really any more readable than old style table-based layout.

Agreed. There is a time and a place for everything. If table markup is used nowhere else in a DOM, it is completely justified for easily vertically centering div content (across platforms) no matter what the container properties are.

I don't think anybody considers inline styles best practice. It is however a very easy way to demonstrate a specific layout fragment. Any front-end developer will understand how to extract the styles to a style-sheet.

In any case, there is no irony here. The display:table-* properties is defined precisely to mimic the layout model of HTML tables (hence the name), in order to allow you to achieve the same layout with pure CSS, so you don't have to misuse <table>-elements.

It seems some people have misunderstood the recommendation against using <table>-element for layout, and thinks there is something wrong with table-based layouts. But table-based layouts are fine, and sometimes the only was to achieve a desired effect. The problem is only misuse of <table>-elements for something which is not semantically a table.

I think the use of inline styles was simply to make the example more compact and readable than something like:

  <style>
  .table-example { display: table; }
  .table-example div { display:table-cell;
    vertical-align:middle; }
  .table-example div div { margin-left:auto;
    margin-right:auto; }
  </style>

  <div class="table-example">
      <div>
        <div></div>
      </div>
  </div>

Actually, inline styles are a fad now in React.[1] I've been trying them in my latest project, and am loving it; really solves some of my old pain points with CSS. Haven't been doing it long enough to figure out the new problems it causes, though.

Of course such a project won't work with most non-React web projects. Idiomatic React projects tend to have a large number of small components with extensive re-use. (~5 lines of HTML not counting closing tags per component is my metric)

1: http://projects.formidablelabs.com/radium/

> <div style="display:table;">

In a perfect world, we don't need wrap layers of div of divs for styling, why don't we invent a more semantic tag called "table". Oh wait...

But that wouldn't be semantic in that use case either.

Just because CSS hasn't proven to be all it was supposed to be, does t mean the criticism of the old way was incorrect.

Because it is not a table, it displays in a tabular fashion (for certain user agents).

I always failed to understand what is hard about the _being_ something vs _being displayed_ as something. I have met so many smart people just failing to grasp this simple dichotomy.

For the sake of public education, here is an example from the article. H1 is for (document) titles, and is so used by auto outliners and Google and Pocket. Document titles are document titles regardless of the way your page is displayed (user agent or current style fashion). If you want to display bigger just use "font-size".

I know, right? I even had a designer implement a table of prices for a page with divs, because "tables are evil". I guess he had only heard of the first half of the admonition "never use tables for layout".

If anything is worse than tables for layout it is inline CSS for styling.

It is, however, much shorter and still demonstrates the solution. It's trivial to pull the styles out of that markup.

So actually, I think you can often skip the wrapper div with _display_ table as an orphaned table cell generated a row and table around it for layout purposes.

Reply on news.ycombinator.com