Hacker News Reader

I remember spending ages on various ways to implement "the golden layout" or whatever it was called. Edit: Holy Grail. One header on top, then three columns, and then a footer. And the middle of the three columns should scale with screen width and screen height, such that the rightmost column was at the edge, and the footer was at the bottom of the screen if content was less than screen height.

And then a-list-aparts "faux columns" to make the columns seem to have the same height.

Edit: It was the "Holy Grail" it was named https://en.wikipedia.org/wiki/Holy_grail_(web_design) So hard to do that it even has its own Wikipedia page, heh

I have a CSS book from that time, one I kept too long because I felt it was one of the better CSS books in its time and hasn't been replaced as I keep a certain amount of books for decorative purposes and haven't bought new development books in a while.

The final chapter, in a "putting it all together" style spent most of its time om a holy grail layout.

If I was writing a modern CSS book, this topic would be somewhere in the second quarter in a chapter on grid and flexbox.

I miss those days. Such a simpler time.

".But the problem was that when CSS came out there it came with the mantra of thou shalt not use tables for layout, but CSS was only specified enough to wrap text around an image, so designers had to torture inline-blocks and floats to try to achieve even basic layout tasks. This ended up bringing out a lot of edge case incompatibilities and fights with the layout engine."

This does not match my recollections of CSS in the mid 90s.

My recollection is that people in general just laid out a document like you'd lay out a word document, and as such the minimal amount of floating that people did was not that difficult.

I recall a) when table-based layouts became very popular, and b) when they became very unpopular and we had to start doing all kinds of funky things with float to avoid them.

But returning to the birth of CSS if all you want to do is to put an image in a word processor do and have the text wrap around it, float is not too bad. If you want to design a layout system around it, it sucks.

So, like, to understand "why floats" in a historical sense, it's important to understand that the kind of layouts that tables (and yeesh, I can't even remember what they were called... frames maybe) were used to achieve didn't exist when CSS was first being used...

it was more like the generic tools in a basic rich text editor.

I think there's two separate issues. Firstly they really ought to have been able to anticipate the need for more precise layout tooling by late 1996. Sure, the web was a much more flexible looking place, but grids for high profile commercial sites like AOL and Space Jam already existed, and it's not like they didn't have decades of print layouts to learn from.

Secondly, the later 'thou shalt not use tables' edict from the sort of people who actually joined the relevant W3C committees came after a few years of ubiquitous table use due to the limitations of CSS, but more importantly several years before Flexbox and Grid were even draft specs [other unsuccessful drafts existed]. People used tables because CSS wasn't good at the sort of layout they wanted to achieve, and in response W3C members... told them that tables were evil to screenreaders and they should suck it up and use hacks for at least the next decade

Arguably floats weren't well designed anyway (floating an image inside a box was all kinds of trouble except in IE which disregarded the spec's insistence it was supposed to overhang the bottom) but there was already a case for a proper grid and even that's comparatively minor compared with the 13 year gap before the draft spec for the next gen layout syntax.

> It’s like the designers didn’t even think about layout because that problem was already solved with HTML tables. But the problem was that when CSS came out there it came with the mantra of thou shalt not use tables for layout

This is an unfortunate misunderstanding. CSS did initially aim to provide at least same expressive power as presentational HTML allowed at the time. So it provided the display:table layout model so designers didn't have to use HTML tables for layout. Unfortunately Internet Explorer (which was dominant at the time) did not support this property for a very long time.

Floats were never intended as a general purpose layout tool, but ended up like that for designers which wanted to use pure CSS but at the same time had to cater to IE users.

While flexbox and flexgrid are more powerful and flexible, display:table actually support a lot of the layout functionality designers were clamoring for, like easy to implement expanding sidebars and such. The problem was not with the CSS spec but with the lack of support in the dominant browser.

display:table; doesn't actually replace table based layouts though, because it can't do colspan/rowspan, even today. Ran into this when trying to make a table (containing actual tabular data) responsive

Heck, I would have been happy to have had flexbox day one.

I think flexbox covers 'most' folks layout needs fairly easily, and you can learn it fairly easily and get a lot out of even basic flexbox knowledge.

Tables for layout were horrific. We talk about div spam these days but at least they're all just divs and divs follow divs rules. Unlike divs table, tr, td are all different and don't follow the same rules. And the result of table layouts was table inside tr,td in another table and in another table is its own nightmare and gets ultra inflexible and could require whole hog layout changes just to move a widget if the widget was just a bit too big. Tables were horrible.

Just flexbox day one would have been amazing.

I often use grids when flex would do just to take advantage of the grid gap features. Once the more general gap feature lands in most browsers I’ll probably start using flex more again.

Yeah there's reason to use grids, particularly if you're comfortable with them. I like to start with flexbox if I don't know where things are going / I'll need grid and .. surprisingly I rarely have to move on to grid.

Granted I'm mostly working on business apps, not a lot of complexity there layout wise, flexbox works great for that, and it's not a heavy lift for someone to learn it.

I too am looking forward to that. 99% of the time `&>:not(:last-child) { margin-right: 4px; }` does the trick, but that 1% (usually wrapping) normally leads to compromises.

It's not really 1 vs the other IMO. I use flexbox within grid quite often, for example. They're two different tools with some overlap...

Grid is absurdly more powerful for full-page layout than flexbox (which is amazing for individual columns or rows). Especially once we start getting subgrid. The common comparison is 1 dimensional (flex) vs 2 dimensional (grid) layout.

wish I could use grid yet, I'm still supporting ie11 and safari 9 (i know ie has a janky grid prototype, I would maybe even put up with that if safari worked as well)

Counterpoint: I think that if we'd solidified flexbox or grids too early, before people started making full-fledged single-page apps with toolbars and sidebars and panels oh my... we might have easily missed crucial use cases, and the "anti-table war" turning into the "anti-flexbox war" might have shattered the ecosystem. And the inevitable "display: flexierbox" to fix the shortcomings would be a recipe for disaster. With such high bars for backwards compatibility, it's good that we moved slowly.

That's not a valid counter point.

Tk (https://en.wikipedia.org/wiki/Tk_(software) ) first appeared in 1991. It predates the web. It had efficient and powerful layout managers from the start: http://zetcode.com/gui/tcltktutorial/layout/

The web basically offered... nothing. It just ignored everything else going on.

Not denying there was plenty of innovation in the layout manager space. But it's very possible that the standards committees for browsers weren't looking to those for inspiration at the time, especially before Gmail showed what was possible. Of course they might have done everything right, but just noting that hindsight is 20/20.

These kinds of layouts were incredibly common on the web by late 90s already. I remember wondering back then why all the desktop UI frameworks (it wasn't just Tcl!) have such flexible and powerful layouts, but HTML/CSS does not, even though it would obviously help solve a very common need.

I remember the reason behind skipping table for layouts was to help browsers render the page progressively.

Tables - instead - needed the whole chunk to be rendered. i believe this reason is still valid!

not even inline blocks, that shit didn't work in ie6, i was fucking ecstatic once i could use inline-blocks

Table-based layouts are basically really practical for layouts. It could really have been extended to make it more styleable and also to allow for stackable columns and more responsive layouts instead of whole sale replacing them with CSS and DIVs.

Also, it would have been nice if HTML supported the concept of data fields WITHOUT explicitly needing javascript.

HTML could also have allowed for an easier way of specifying different layout types without going into CSS wizardry to support responsive layouts.

For instance, something like the one below where data fields are specified in a separate block, reusable components in another and then finally the actual layouts.

#Data blocks here

<data>

   <d name="selectedCity">1</d>

   <d name="cities">
         [(1, "Barcelona"), (2, "Madrid")]
   </d>

   <d name="languages">
         [("es", "Spanish"), ("en", "English")]
   </d>

   <d name="nav">
         [("Home", "/index.html"), ("Profile", "/profile")]
   </d>

   <d name="posts">
         [{title: "Title comes here", content: "Content comes here"},{title: "Title comes here", content: "Content comes here"}]
   </d>

</data>

# Reusable components here

   <component name="header">

     <select id="languages" value="es">#options($languages[0], $languages[1], "es")<select>  <!-- Built in handling of options list for select boxes-->

      <select id="citySelector" value="$selectedCity">#options($cities[0], $cities[1], $selectedCity)<select>
     
    <div id="navigation"><nav>#links($nav[1], $nav[0])</nav>
       <!-- Built in handling of Lists of links etc -->

     </div>

   </component>

   <component name="blog">

       #foreach ($posts : $post)

         <h1>$post.title</h1>

         <p>$post.content</p>

       #endforeach

   </component>

   <component name="footer">

      <span>Copyright  Company.com</span>

   </component>

</components>

    <layout res="(1280, 800)" default>
     
       <!-- use whatever styles of markup needed without worrying about how it impacts another layout - use divs, tables or whatever--> 

        <block component="header" id="header1"/>
        <block component="blog" class="blog"/>
        <block component="footer"/>
     </layout>
    <layout res="(1920, 1080)">  
      <div...>   
        <!-- Style for this specific layout --> 

        <block component="header" id="header1"/>
        <block component="blog" class="blog-fhd"/>
        <block component="footer"/>
      ...</div>
    </layout>
    <layout res="(1080, 1280)">
       <table>
        <!-- Style for this specific layout. Use tables if needed. Use whatever html markup as needed --> 

        <block component="header" id="header1"/>
        <block component="blog" class="blog-fhd-rotated"/>
        <block component="footer"/>

       </table>
  </layout>

   ...

</layouts>