Hacker News new | ask | show | jobs
by einr 3428 days ago
That's a problem to be sure, but sometimes I wonder if this is much better:

  <div class="container">
    <div class="maincontent">
      <div class="col-md-4">
        <div class="row">
          <div class="col-md-8">
            <div class="row">
              <div class="header">
                <div class="text-center">
                  <div class="brand-text">
4 comments

It's not. There were a few arguments against "table layout", some of which apply to hn as well IMNHO. Added tags without semantic value (just as your div-soup above also illustrates). Layout speed (in reality not much of an issue now - and also an issue with deeply nested tags with complex layout).

Both are fixed in modern html5 which moves (back) towards simple, semantic, document layout (html-body-article-heading-etc).

With flex-box layout it's also quite easy to have the article/main content come first (possibly preceded by a header) - followed by sidebars and footer -- all as their own "top-level" boxes/containers.

In a classic table layout, there's an extra top level element in addition to "body" - the surrounding table.

And finally table layout is generally verbose and messy for other types of content than tabular data.

I look forward to trying modern flexbox and grid layouts. I have not had the privilege (?) to work with either yet; our customers are not necessarily on the bleeding edge of browser releases so I have to stay a little behind the curve. Hence, a lot of div soup and ridiculous indentation levels.

Honestly, for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs and checkboxes everywhere) a Bootstrap-style div layout gets at least as verbose and messy as a table layout would. I especially hate having to always do HTML comments with class/id names after every </div> so I know what closes what when I'm near the bottom of the file. At least with tables you get </td></tr></table> instead of </div></div></div>.

But of course a div layout is at least partially semantic and mobile/small screen friendly.

In a classic table layout, there's an extra top level element in addition to "body" - the surrounding table.

In practice, any bog-standard div layout today has a <div class="container"> at top level which contains nothing but other divs and sets size and positioning for the whole page. This is roughly equal to a <table>, no?

> for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs and checkboxes everywhere)

Right. There's different contexts between an application an a (hyper)text document.

What's good semantic markup for one, will generally be bad for the other.

It's admirable (and desirable) to strive for adaptive layout and accessibility in applications - but they need a different type of framework than documents made for browsers. The browsers straddle this divide rather uncomfortably - being in part hypertext document browsers, and in part virtual machines for running general applications.

Approaches like web components[1] might help us move toward a standardised reality for "applications that happen to run in the browser", while css and html are still (more and more anachronistically) (hypertext) document markup and layout tools.

If you want to make a Web page/site (like alistapart.com) that's great. Swim with the current and draw inspiration from stuff like css zen garden[2]. With flex box, you can burn[4] most of the old complicated grid layout stuff, and comparatively easily make great sites.

That doesn't really help if you're a "front-end developer" making "apps" though. Even the few that make an effort to color within the lines are still fighting the browsers and the standard, trying to fit a code-on-demand app into a REST shoe[3].

[1] https://www.webcomponents.org/

[2] http://www.mezzoblue.com/zengarden/alldesigns/

[3] https://news.ycombinator.com/item?id=13500635 (I've said it before - the true tragedy isn't that too few read Fielding's thesis and never understood REST - It's that so many ignore that he covered a lot of other architectures that are more suitable for many applications than REST is)

[4] https://philipwalton.github.io/solved-by-flexbox/demos/grids...

The "container" is common, but typically not needed.

Sometimes it's a redundant stand-in for "body > .content" or similar (eg: divs dropped directly in body) - and is prevalent because developers don't understand and care about css selectors (or there's that one person on the team that doesn't -- don't get me wrong -- I realize the real world is full of real co-workers, and making a change isn't always easy).

And partially it can be an artifact of abusing floats for "grid layout". Most typically though, the "container div" just ends up being a completely redundant extra "body" element.

oh yes! </div> is my nightmare. at least with table u can more easily spot the error when rendered.

> of course a div layout is at least partially semantic

That's contestable, <div> nowadays is absolutely unpredictable, <table>s are more semantic

Sometimes i wish HTML was like python hehe

It's not, clearly. Modern "grid-based layout" frameworks are just the next generation of table-driven web layouts, and they're frequently shoehorned into webpages in ways that hearken back to the olden days before CSS was invented.

<div class="container"> is one of my least favorite things to see in HTML, in particular. No shit it's a container; all HTML tags are containers. HTML5 introduced all these wonderful semantic elements precisely so that we don't have to pollute HyperText documents with thousands of divs.

Also, that "text-center" class drives me to drink :)

Also, that "text-center" class drives me to drink :)

It's a standard component of Bootstrap ;)

http://getbootstrap.com/css/#type-alignment

That's a problem for sure but last week I looked into creating a family tree with the basics of HTML and CSS and the following nested lists seems to be the best solution according to forums. Now, try to add into these nested lists some siblings(the people kind) and some new branches as you discover people in census reports from 100 years ago. Now add in a newborn. Is this the best we can do? (apologies, but I haven't the time to tab this correctly, link to Codepen at the end):

    <div class="tree">
      <ul>
        <li>
          <a href="#">Parent</a>
            <ul>
              <li>
                <a href="#">Child</a>
                  <ul>
                    <li>
                      <a href="#">Grand Child</a>
                        </li>
                          </ul>
                            </li>
                              <li>
                                <a href="#">Child</a>
                                  <ul>
                                    <li><a href="#">Grand Child</a></li>
                                      <li>
                                        <a href="#">Grand Child</a>
                                        <ul>
                                          <li>
                                            <a href="#">Great Grand Child</a>
                                          </li>
                                          <li>
                                            <a href="#">Great Grand Child</a>
                                          </li>
                                          <li>
                                            <a href="#">Great Grand Child</a>
                                          </li>
                                        </ul>
                                      </li>
                                      <li><a href="#">Grand Child</a></li>
                                    </ul>
                                  </li>
          </ul>
        </li>
      </ul>
    </div>

Lifted from here: https://codepen.io/chuongdang/pen/lcnsC
Lifted from there, but with broken indentation :) In fact with correct indentation, you see that this goes down 4 levels (instead of the seeming 14 the current rendering seems to indicate). That's significantly better, and once you get used to the structures of lists it's actually relatively straightforward to understand a list like that. Moreover, it's trivial for a computer to understand a list like that as nested lists of lists.

Side note: the top-level div isn't really necessary; you can just apply the `tree` class directly to the `ul` with a small tweak or two to the CSS.

Absolutely, but try researching a family tree and then implementing it using that model and see how quickly you get lost in the nested list structure. The, as I said in another comment, try adding a child born after you started the lists, ie, before the first UL. Then add a divorce and a new spouse and see how easy that is to logically display the relationship.

To illustrate how HTML so ill suited to this structure, I had another look at the problem and found Treant, because yes, the easiest to do this on the Web and maintain it is to write an entire API.

http://fperucic.github.io/treant-js/

How could this be done better though? Unless using a DSL it seems to me that this problem is quite complex to begin with.
It is, but it also illustrates the problem of drawing a simple diagram for the web. It was in response to user mattmanser's illustration of diabolical nested tables and user einar's nested divs. HTML is problematic for anything complex. I suppose the best way to represent the data is to not use HTML at all, but instead use an image (SVG? for scalabilty) or a big PDF that opens a new tab?

I googled for a solution that I could add to and maintain myself and this was what The Internet threw up as the best solution, but it is far from good.

I would say that best for drawing diagrams in html pages would be to use a DSL like plantuml or dot and some javascript library to transform it into a SVG image.
> How could this be done better though?

      <ul>
        <li>
          <a href="#">Parent</a>
          <ul></ul>
        </li>
      </ul>
You can mitigate this about 50% by switching from pure Bootstrap to something like Bootstrap-Sass and inheriting selected rules on something semantic like <article>.

(But then you'll hit a wall as you try to deal with the containers and subcontainers.)