4 ms·

HN still uses <table> .. and it works great.

louhike 10y ago
It depends which device you use to look at it. It tends to adapt poorly on large screens or smartphones (at least the ones I use). And this is the primary reason to not use table AFAIK.
- TekMol 10y ago
  For me, HN works better then 99% of all sites. On all of my devices. Desktop, tablet, phone. It always does exactly what I want it to do: Fill the whole window with content. So I can always resize the window to the exact size that is most comfortable for me. And it's blazingly fast.
  - wmil 10y ago
    A few years ago HN's nested tables led to random font sizes on mobile. So there have definitely been problems in the past. But HN is also in a very unique position. It has 170 lines of CSS and thousands of talented web developers have inspected it for mobile problems. Every easy fix has been made. Most websites can't do that.
    - carlob 10y ago
      > A few years ago HN's nested tables led to random font sizes on mobile. So there have definitely been problems in the past. That was actually a bug in Chrome, that was trying to be overly smart and changing font sizes aggressively.
  - deleted 10y ago
    [deleted]
andybak 10y ago
I've been idly thinking about starting a list of 'cargo cult development ideas' - more specifically things that make sense or made sense in a specific domain but got passed around and became detached from their original intent. There's a related idea that interests me - ideas that were useful mainly for killing something else. These two things overlap somewhat. 1. "Don't use tables for layout" - helped kill the most horrific era of web-design which was largely based on slicing large photoshop images into parts and reconstructing them in html tables. Responsive design would never have been possible if this practice hadn't have been vanquished. The actual arguments for not using tables for layout were much more nuanced and in some places - just wrong. In particular the arguments based on tags having semantic value were laughable when you consider that in most cases we just replaced table/tr/td with div/div/div. 2. REST. Most APIs are still only an approximation of 'true' REST - or just kind of cheating and sticking in some RPC-style endpoints when the going gets tough. The promise of machine to machine API usage without developer intervention is yet to be realised. However - REST stopped SOAP from taking over the world and for that we must be eternally thankful. 3. "Separate content and presentation (HTML/CSS)". Similar to (1) - this was based around a core truth about separation of concerns and maintainability. However it became a mantra rather than just one specific way you could attempt to reduce coupling and create less brittle markup. But it was easy to explain and easy to argue for and it stopped a lot of bad practices. I had a few more but I can't recall them right now. Maybe the message is "simple to explain but partially inaccurate ideas are easier to transmit than nuanced and complex ones"
- lucideer 10y ago
  Slightly OT nitpick: > In particular the arguments based on tags having semantic value were laughable when you consider that in most cases we just replaced table/tr/td with div/div/div. This comes up a lot and it niggles at me every time. div/div/div was a large semantic improvement over table/tr/td, not because it specifically describes the content you've put in divs better (it doesn't, obviously), but because it stops being explicit "dishonest" about the semantics of that content. Defaulting to div/div/div over table/tr/td makes semantic specificity opt-in and explicit instead of opt-out and implicitly wrong for generic non-table content. It means devs who want to use specific tags for greater semantic specificity can do so, while most devs are using generics (divs) because they don't want/need the specific semantics. The previous alternative was that the majority were following a pattern that made intentionally semantic table content indistinguishable from generic[0] content. Otherwise, good post. I'd like to see that list started and growing. [0] By "generic" content I just mean any content where there isn't a strong desire/need on the dev side to describe it very specifically.
  - k__ 10y ago
    What I don't understand, we have a whole bunch of semantic HTML elements for years now (<main>, <section>, <header>, etc.) and no need for <div class="main"> anymore, but they don't get used very often.
    - bshimmin 10y ago
      There are two reasons: 1) There's no real world benefit to using these elements, in any easily demonstrable way (maybe there's some sort of tiny accessibility or SEO advantage, but it's fractional in comparison with, say, just using H1/H2/H3 correctly), which mostly leaves them as an exercise in academic purity. 2) The definitions are really woolly and require far too much thought, especially given the previous reason. Why bother debating whether something is a SECTION or an ARTICLE or a MAIN when you can just use a DIV, with whatever probably overly specific `class` you were going to use anyway, and it will still work in exactly the same way?
    - patates 10y ago
freshyill 10y ago
I imagine you'd have a different opinion if you needed to use a screen reader.
martin_drapeau 10y ago
On a new app I'm developing I am using display: table and display: table-cell. These work great. I'm curious as to why this solution is not more widely used or discussed.
- parenthephobia 10y ago
  1. On many browsers, if you don't use `display: table-row` between those, it'll mess up your content. 2. CSS only almost exposes the HTML table layout system. e.g. There are no column groups, or column or row spans. There's no way to indicate a table header in CSS that would make a browser repeat it when printing a table over multiple pages. 3. People who learn by rote that table is evil without really learning why are likely to assume that using CSS to make something behave (almost) like a table is also evil.

It depends which device you use to look at it. It tends to adapt poorly on large screens or smartphones (at least the ones I use). And this is the primary reason to not use table AFAIK.

TekMol 10y ago
For me, HN works better then 99% of all sites. On all of my devices. Desktop, tablet, phone. It always does exactly what I want it to do: Fill the whole window with content. So I can always resize the window to the exact size that is most comfortable for me. And it's blazingly fast.
- wmil 10y ago
  A few years ago HN's nested tables led to random font sizes on mobile. So there have definitely been problems in the past. But HN is also in a very unique position. It has 170 lines of CSS and thousands of talented web developers have inspected it for mobile problems. Every easy fix has been made. Most websites can't do that.
  - carlob 10y ago
    > A few years ago HN's nested tables led to random font sizes on mobile. So there have definitely been problems in the past. That was actually a bug in Chrome, that was trying to be overly smart and changing font sizes aggressively.
- deleted 10y ago
  [deleted]

andybak 10y ago

I've been idly thinking about starting a list of 'cargo cult development ideas' - more specifically things that make sense or made sense in a specific domain but got passed around and became detached from their original intent. There's a related idea that interests me - ideas that were useful mainly for killing something else. These two things overlap somewhat. 1. "Don't use tables for layout" - helped kill the most horrific era of web-design which was largely based on slicing large photoshop images into parts and reconstructing them in html tables. Responsive design would never have been possible if this practice hadn't have been vanquished. The actual arguments for not using tables for layout were much more nuanced and in some places - just wrong. In particular the arguments based on tags having semantic value were laughable when you consider that in most cases we just replaced table/tr/td with div/div/div. 2. REST. Most APIs are still only an approximation of 'true' REST - or just kind of cheating and sticking in some RPC-style endpoints when the going gets tough. The promise of machine to machine API usage without developer intervention is yet to be realised. However - REST stopped SOAP from taking over the world and for that we must be eternally thankful. 3. "Separate content and presentation (HTML/CSS)". Similar to (1) - this was based around a core truth about separation of concerns and maintainability. However it became a mantra rather than just one specific way you could attempt to reduce coupling and create less brittle markup. But it was easy to explain and easy to argue for and it stopped a lot of bad practices. I had a few more but I can't recall them right now. Maybe the message is "simple to explain but partially inaccurate ideas are easier to transmit than nuanced and complex ones"

lucideer 10y ago
Slightly OT nitpick: > In particular the arguments based on tags having semantic value were laughable when you consider that in most cases we just replaced table/tr/td with div/div/div. This comes up a lot and it niggles at me every time. div/div/div was a large semantic improvement over table/tr/td, not because it specifically describes the content you've put in divs better (it doesn't, obviously), but because it stops being explicit "dishonest" about the semantics of that content. Defaulting to div/div/div over table/tr/td makes semantic specificity opt-in and explicit instead of opt-out and implicitly wrong for generic non-table content. It means devs who want to use specific tags for greater semantic specificity can do so, while most devs are using generics (divs) because they don't want/need the specific semantics. The previous alternative was that the majority were following a pattern that made intentionally semantic table content indistinguishable from generic[0] content. Otherwise, good post. I'd like to see that list started and growing. [0] By "generic" content I just mean any content where there isn't a strong desire/need on the dev side to describe it very specifically.
- k__ 10y ago
  What I don't understand, we have a whole bunch of semantic HTML elements for years now (<main>, <section>, <header>, etc.) and no need for <div class="main"> anymore, but they don't get used very often.
  - bshimmin 10y ago
    There are two reasons: 1) There's no real world benefit to using these elements, in any easily demonstrable way (maybe there's some sort of tiny accessibility or SEO advantage, but it's fractional in comparison with, say, just using H1/H2/H3 correctly), which mostly leaves them as an exercise in academic purity. 2) The definitions are really woolly and require far too much thought, especially given the previous reason. Why bother debating whether something is a SECTION or an ARTICLE or a MAIN when you can just use a DIV, with whatever probably overly specific `class` you were going to use anyway, and it will still work in exactly the same way?
  - patates 10y ago

freshyill 10y ago

I imagine you'd have a different opinion if you needed to use a screen reader.

martin_drapeau 10y ago

On a new app I'm developing I am using display: table and display: table-cell. These work great. I'm curious as to why this solution is not more widely used or discussed.

parenthephobia 10y ago
1. On many browsers, if you don't use `display: table-row` between those, it'll mess up your content. 2. CSS only almost exposes the HTML table layout system. e.g. There are no column groups, or column or row spans. There's no way to indicate a table header in CSS that would make a browser repeat it when printing a table over multiple pages. 3. People who learn by rote that table is evil without really learning why are likely to assume that using CSS to make something behave (almost) like a table is also evil.