4 ms·

> Hacker News as viewed by the Mac. Surprisingly readable given that MacWeb doesn’t support CSS. Say what you will about table based layouts, but they sure are

by tobr 12y ago

> Hacker News as viewed by the Mac. Surprisingly readable given that MacWeb doesn’t support CSS. Say what you will about table based layouts, but they sure are backwards compatible.

lisper 12y ago
http://www.flownet.com/ron/css-rant.html http://www.flownet.com/ron/css-rant.html Still valid after all these years.
- TazeTSchnitzel 12y ago
  Well, we finally have flexbox now!
  - lisper 12y ago
    It's far from clear to me that flexbox actually solves the problem. For example, consider the following: <table style='height: 100%; width: 100%'> <tr><td align=center valign=center> <h1>Hello world</h1> The following button should be centered:<br> <button>Button</button> </td></tr> </table> Can you reproduce that with flexbox? In a way that works across all browsers? Without writing huge amounts of code? [NOTE: This example has a bug in it. See the subsequent comments]
    - icebraining 12y ago
      Doesn't simply replacing the table/tr/td with a div with "margin: auto; text-align: center" work? Seems to yield the same result, at least in Firefox.
      - lisper 12y ago
        Margin: auto doesn't center vertically. Also, it only centers the element that it applies to, not the contents of that element. My example was supposed to illustrate this, but it actually has a bug. I thought buttons didn't get centered by text-align, but they do. Here's an updated example: <table style='height: 100%; width: 100%'> <tr><td align=center valign=center> <h1>Hello world</h1> The following green square should be centered:<br> <div style='width: 30px; height: 30px; background: green'></div> </td></tr> </table> margin:auto also requires you to manually set the width of the div you're trying to center in order to work.
        nkuttler 12y ago
        That's easy to do without tables. See display: table; and display: inside-block for the div. text-align: center, yadda.
        lisper 12y ago
        Display: table is cheating, and essentially conceding that you should have been using tables all along. And there is no such thing as display: inside-block. (You probably meant inline-block.) The devil is in the details. I believe if you try it you will find it is nowhere near as easy as you imagine.
        JoshTriplett 12y ago
        > Display: table is cheating, and essentially conceding that you should have been using tables all along. Not at all. "display: table" (and the related "display: table-cell" and similar) mean that you've written something which is not semantically a table, but which should use the browser rendering conventions of a table. That's a perfectly reasonable distinction. Otherwise, would you suggest that every use of "font-family: sans-serif" is cheating and essentially conceding that you should have been using a <font> tag all along?
        lisper 12y ago
        > Otherwise, would you suggest that every use of "font-family: sans-serif" is cheating Yes, if your intent is to use font-family as an example in an argument for using CSS. > and essentially conceding that you should have been using a <font> tag all along? No, I'm saying that a font tag and a font-family style are equivalent. One is as good as the other. You should read this: http://blog.rongarret.info/2009/02/on-semantics-of-html.html http://blog.rongarret.info/2009/02/on-semantics-of-html.html
        JoshTriplett 12y ago
        Even if you argue that HTML tags don't have semantic meanings (which I'd strongly disagree with, pointing to numerous tools that derive useful semantic information from such tags), there's quite a lot of value in defining your markup in terms of semantics and then separately defining what you want those semantics to look like. With good semantic markup, you can easily retheme your site to look completely different, make it scale to a mobile UI, or make it accessible to users of screen readers. So, there's a major difference between using font-family and a <font> tag, and a major difference between using display: table* and <table>/<tr>/<td> tags. And for the same reason, you shouldn't use class="sidebar" if what you mean is class="navigation" (or for that matter <nav>). Let alone class="big-red-button" when what you mean is class="delete". To use an example from that article: sure, <p> is not as semantically significant as <section> or <h1>, but it's a lot more semantic than, say, <br/><br/>, which I've seen used between paragraphs. "This is a paragraph" is more semantically useful than "this has an indent on the left and 1.4x line spacing"; "this is a heading" is more semantically useful than "this is 24pt and bold".
    - TazeTSchnitzel 12y ago
      Yes.
JoshTriplett 12y ago
CSS-based layouts, done right, still leave the underlying HTML heavily semantic. And even with a few extra un-semantic divs and spans around, you can just ignore those. The two biggest problems would be with sites that don't bother to put content in a sensible semantic order (putting huge amounts of sidebar/navigation content before the main content) and sites that generate everything with JavaScript with no fallbacks.
- UnoriginalGuy 12y ago
  > CSS-based layouts, done right, still leave the underlying HTML heavily semantic. Could you give an example? I've done "tables" in CSS, and most of the time you're using DIV to manage most of the positioning, which is non-semantic. If there was a CSS table replacement which defaulted back to something which looked like a table in HTML, I'd be impressed.
  - JoshTriplett 12y ago
    If what you're building is actually a table, use table markup; that's the semantically correct markup. Just don't use it for something like a sidebar or footer, or otherwise for positioning. If you're building a navigation area, a callout, or some similar semantically significant sidebar, take a look at https://html.spec.whatwg.org/multipage/dom.html#sectioning-content https://html.spec.whatwg.org/multipage/dom.html#sectioning-c... for the nav and aside elements. But even if you use a div, as long as the semantic content makes sense without the div, you're fine. For instance, put one div with your article content starting with an appropriate heading tag, and another div for your navigation. Without the CSS, it still makes sense to have a section for content and a section for navigation. Also, there is actually CSS markup to make something look like a table, if that's what you want; see http://caniuse.com/#feat=css-table http://caniuse.com/#feat=css-table for instance.
- tobr 12y ago
  I agree with everything you're saying, but I'm not sure what this is a response to? The site layout looks acceptable on this 30 years old computer precisely because it does not care about semantics.
lazaroclapp 12y ago
It also looks fairly decent in links2. Unfortunately the indentation of nested comments is missing, which makes comment threads a lot harder to parse.
Decade 12y ago
But the table was why MacWeb took minutes to render a single page on the Mac Plus. That browser was horrible. I preferred MacLynx.

by tobr 12y ago

> Hacker News as viewed by the Mac. Surprisingly readable given that MacWeb doesn’t support CSS. Say what you will about table based layouts, but they sure are backwards compatible.

lisper 12y ago

http://www.flownet.com/ron/css-rant.html http://www.flownet.com/ron/css-rant.html Still valid after all these years.

TazeTSchnitzel 12y ago
Well, we finally have flexbox now!
- lisper 12y ago
  It's far from clear to me that flexbox actually solves the problem. For example, consider the following: <table style='height: 100%; width: 100%'> <tr><td align=center valign=center> <h1>Hello world</h1> The following button should be centered:<br> <button>Button</button> </td></tr> </table> Can you reproduce that with flexbox? In a way that works across all browsers? Without writing huge amounts of code? [NOTE: This example has a bug in it. See the subsequent comments]
  - icebraining 12y ago
    Doesn't simply replacing the table/tr/td with a div with "margin: auto; text-align: center" work? Seems to yield the same result, at least in Firefox.
    - lisper 12y ago
      Margin: auto doesn't center vertically. Also, it only centers the element that it applies to, not the contents of that element. My example was supposed to illustrate this, but it actually has a bug. I thought buttons didn't get centered by text-align, but they do. Here's an updated example: <table style='height: 100%; width: 100%'> <tr><td align=center valign=center> <h1>Hello world</h1> The following green square should be centered:<br> <div style='width: 30px; height: 30px; background: green'></div> </td></tr> </table> margin:auto also requires you to manually set the width of the div you're trying to center in order to work.
      - nkuttler 12y ago
        That's easy to do without tables. See display: table; and display: inside-block for the div. text-align: center, yadda.
        lisper 12y ago
        Display: table is cheating, and essentially conceding that you should have been using tables all along. And there is no such thing as display: inside-block. (You probably meant inline-block.) The devil is in the details. I believe if you try it you will find it is nowhere near as easy as you imagine.
        JoshTriplett 12y ago
        > Display: table is cheating, and essentially conceding that you should have been using tables all along. Not at all. "display: table" (and the related "display: table-cell" and similar) mean that you've written something which is not semantically a table, but which should use the browser rendering conventions of a table. That's a perfectly reasonable distinction. Otherwise, would you suggest that every use of "font-family: sans-serif" is cheating and essentially conceding that you should have been using a <font> tag all along?
        lisper 12y ago
        > Otherwise, would you suggest that every use of "font-family: sans-serif" is cheating Yes, if your intent is to use font-family as an example in an argument for using CSS. > and essentially conceding that you should have been using a <font> tag all along? No, I'm saying that a font tag and a font-family style are equivalent. One is as good as the other. You should read this: http://blog.rongarret.info/2009/02/on-semantics-of-html.html http://blog.rongarret.info/2009/02/on-semantics-of-html.html
        JoshTriplett 12y ago
        Even if you argue that HTML tags don't have semantic meanings (which I'd strongly disagree with, pointing to numerous tools that derive useful semantic information from such tags), there's quite a lot of value in defining your markup in terms of semantics and then separately defining what you want those semantics to look like. With good semantic markup, you can easily retheme your site to look completely different, make it scale to a mobile UI, or make it accessible to users of screen readers. So, there's a major difference between using font-family and a <font> tag, and a major difference between using display: table* and <table>/<tr>/<td> tags. And for the same reason, you shouldn't use class="sidebar" if what you mean is class="navigation" (or for that matter <nav>). Let alone class="big-red-button" when what you mean is class="delete". To use an example from that article: sure, <p> is not as semantically significant as <section> or <h1>, but it's a lot more semantic than, say, <br/><br/>, which I've seen used between paragraphs. "This is a paragraph" is more semantically useful than "this has an indent on the left and 1.4x line spacing"; "this is a heading" is more semantically useful than "this is 24pt and bold".
  - TazeTSchnitzel 12y ago
    Yes.

JoshTriplett 12y ago

CSS-based layouts, done right, still leave the underlying HTML heavily semantic. And even with a few extra un-semantic divs and spans around, you can just ignore those. The two biggest problems would be with sites that don't bother to put content in a sensible semantic order (putting huge amounts of sidebar/navigation content before the main content) and sites that generate everything with JavaScript with no fallbacks.

UnoriginalGuy 12y ago
> CSS-based layouts, done right, still leave the underlying HTML heavily semantic. Could you give an example? I've done "tables" in CSS, and most of the time you're using DIV to manage most of the positioning, which is non-semantic. If there was a CSS table replacement which defaulted back to something which looked like a table in HTML, I'd be impressed.
- JoshTriplett 12y ago
  If what you're building is actually a table, use table markup; that's the semantically correct markup. Just don't use it for something like a sidebar or footer, or otherwise for positioning. If you're building a navigation area, a callout, or some similar semantically significant sidebar, take a look at https://html.spec.whatwg.org/multipage/dom.html#sectioning-content https://html.spec.whatwg.org/multipage/dom.html#sectioning-c... for the nav and aside elements. But even if you use a div, as long as the semantic content makes sense without the div, you're fine. For instance, put one div with your article content starting with an appropriate heading tag, and another div for your navigation. Without the CSS, it still makes sense to have a section for content and a section for navigation. Also, there is actually CSS markup to make something look like a table, if that's what you want; see http://caniuse.com/#feat=css-table http://caniuse.com/#feat=css-table for instance.
tobr 12y ago
I agree with everything you're saying, but I'm not sure what this is a response to? The site layout looks acceptable on this 30 years old computer precisely because it does not care about semantics.

lazaroclapp 12y ago

It also looks fairly decent in links2. Unfortunately the indentation of nested comments is missing, which makes comment threads a lot harder to parse.

Decade 12y ago

But the table was why MacWeb took minutes to render a single page on the Mac Plus. That browser was horrible. I preferred MacLynx.