5 ms·

I do to, sometimes. I wonder if there is any thought given to making tables responsive rather than reinventing the wheel here.

by return0 10y ago

yellowapple 10y ago
The (theoretical) issue here is that a "table" has a certain semantic meaning ("a container for tabular data"), and that using a table for something outside that semantic meaning can introduce confusion, be it for fellow programmers (including your future self!) or for those who are interpreting your page in weird ways (robots, people using screen readers, etc.). In the few times I actually bother with frontend "design", my goal is usually for my actual HTML to contain as few hints about how said HTML should be displayed as possible, and to let CSS handle the display specifics. This usually means that I don't touch `div` and I don't touch `class` unless absolutely necessary. CSS provides more than enough selectors for "absolutely necessary" to be false in the vast majority of cases. Of course, this ain't for everyone. Some people stick with tables. Some people use div/class for everything. Some people just treat Javascript like the new Postscript and generate pages on the fly. You do you. However, these tend to have their share of downsides, among them being a tendency to deviate strongly from the semantics of HyperText documents. Tables ought to be responsive anyway, though, even if that just means "add a horizontal scrollbar if the screen is below a certain size". I'm pretty sure that's already possible through CSS, but it involves overriding a lot of the work the browser does for you, and unless the data encapsulated by that table is indeed meant to be tabular, you're probably better off with divs (or better yet, with more specific HTML elements).
- HalfwayToDice 10y ago
  I have 30,000 unique visitors to my website every day. The number who care whether HTML tags are being outside their semantic purity is zero.
  - extra88 10y ago
    A. How would you know what they care about? B. Maybe if you cared, you'd have 30,300 unique visitors, or more. I don't know, I don't know how bad your site's code is.
  - yellowapple 10y ago
    Great! If it ain't broke, don't fix it. If you don't have users with screen readers and don't have any issues with search engines parsing your web page, then you do you.
    - HalfwayToDice 10y ago
      Screen readers and search engines haven't been confused by tables since last century.
      - yellowapple 10y ago
        According to other comments to the linked article, the former at the very least ain't universally true.
- TeMPOraL 10y ago
  OK, so tables have semantics of tabular data. But the shit ton of semantically meaningless divs that are sprinkled around the structure to provide hooks for CSS declarations in the "usual" style of doing layouts is somehow better? It's much larger, much less readable, much less obvious, and breaks the "separation of content and layout" rule even stronger than tables. So again, why is this better? And yes, I've been in this space for years, and this is one of the better example why I feel most of the webdev world is cargo-cult advice that's internally inconsistent if you look at it carefully.
  - andreareina 10y ago
    I feel like this is the reason behind HTML5's semantic elements (e.g. article, nav, etc).
  - extra88 10y ago
    Using an element that lacks semantics (<div>) is always better than mis-using an element that has semantics (<tr>, <td>). Why would you need to use more divs than table elements to achieve the same visual layout? I feel like you're not comparing apples to apples. What's so readable and obvious about tables nested 3-4 levels deep? Anyone who really thinks about how CSS can be used is also going to be against div-itis but it's still less-bad than tables for layout. They're also going to be against excessive use of classes and class names that connote style (class="red") rather than purpose (class="alert").
  - kuschku 10y ago
    The divs are sprinkled just to say "this is a block, it can be moved or arranged however wished", and styling within the block is done separately. It’s not intended to do anything more or less.
  - yellowapple 10y ago
    "But the shit ton of semantically meaningless divs that are sprinkled around the structure to provide hooks for CSS declarations in the 'usual' style of doing layouts is somehow better?" No, it's not, as I thought I made plainly clear in my comment. HTML5 introduced a smorgasbord of new tags to avoid that. You're right that a lot of modern web development fashion is silly, but there are alternatives besides just sticking to tables for everything.
- andreareina 10y ago
  w.r.t. avoiding div and class, how do you make sense of the element <-> rule mapping? There's definitely enough specificity to make such a mapping, but I just end up with a big bowl of spaghetti. EDIT: I guess I'm mostly talking about class, HTML5 semantic elements takes over much of the utility of divs in this usecase.
  - yellowapple 10y ago
    I usually just base it on whether or not an element is a direct child of some other element. For example, the header of the page itself will usually have a different style than the header of an article or aside or something, so I can use CSS' child selectors for that. This often does indeed result in a bowl of spaghetti, but said bowl is in CSS rather than HTML. Things like SASS/SCSS help tremendously.

I do to, sometimes. I wonder if there is any thought given to making tables responsive rather than reinventing the wheel here.

by return0 10y ago

I do to, sometimes. I wonder if there is any thought given to making tables responsive rather than reinventing the wheel here.

yellowapple 10y ago

The (theoretical) issue here is that a "table" has a certain semantic meaning ("a container for tabular data"), and that using a table for something outside that semantic meaning can introduce confusion, be it for fellow programmers (including your future self!) or for those who are interpreting your page in weird ways (robots, people using screen readers, etc.). In the few times I actually bother with frontend "design", my goal is usually for my actual HTML to contain as few hints about how said HTML should be displayed as possible, and to let CSS handle the display specifics. This usually means that I don't touch `div` and I don't touch `class` unless absolutely necessary. CSS provides more than enough selectors for "absolutely necessary" to be false in the vast majority of cases. Of course, this ain't for everyone. Some people stick with tables. Some people use div/class for everything. Some people just treat Javascript like the new Postscript and generate pages on the fly. You do you. However, these tend to have their share of downsides, among them being a tendency to deviate strongly from the semantics of HyperText documents. Tables ought to be responsive anyway, though, even if that just means "add a horizontal scrollbar if the screen is below a certain size". I'm pretty sure that's already possible through CSS, but it involves overriding a lot of the work the browser does for you, and unless the data encapsulated by that table is indeed meant to be tabular, you're probably better off with divs (or better yet, with more specific HTML elements).

HalfwayToDice 10y ago
I have 30,000 unique visitors to my website every day. The number who care whether HTML tags are being outside their semantic purity is zero.
- extra88 10y ago
  A. How would you know what they care about? B. Maybe if you cared, you'd have 30,300 unique visitors, or more. I don't know, I don't know how bad your site's code is.
- yellowapple 10y ago
  Great! If it ain't broke, don't fix it. If you don't have users with screen readers and don't have any issues with search engines parsing your web page, then you do you.
  - HalfwayToDice 10y ago
    Screen readers and search engines haven't been confused by tables since last century.
    - yellowapple 10y ago
      According to other comments to the linked article, the former at the very least ain't universally true.
TeMPOraL 10y ago
OK, so tables have semantics of tabular data. But the shit ton of semantically meaningless divs that are sprinkled around the structure to provide hooks for CSS declarations in the "usual" style of doing layouts is somehow better? It's much larger, much less readable, much less obvious, and breaks the "separation of content and layout" rule even stronger than tables. So again, why is this better? And yes, I've been in this space for years, and this is one of the better example why I feel most of the webdev world is cargo-cult advice that's internally inconsistent if you look at it carefully.
- andreareina 10y ago
  I feel like this is the reason behind HTML5's semantic elements (e.g. article, nav, etc).
- extra88 10y ago
  Using an element that lacks semantics (<div>) is always better than mis-using an element that has semantics (<tr>, <td>). Why would you need to use more divs than table elements to achieve the same visual layout? I feel like you're not comparing apples to apples. What's so readable and obvious about tables nested 3-4 levels deep? Anyone who really thinks about how CSS can be used is also going to be against div-itis but it's still less-bad than tables for layout. They're also going to be against excessive use of classes and class names that connote style (class="red") rather than purpose (class="alert").
- kuschku 10y ago
  The divs are sprinkled just to say "this is a block, it can be moved or arranged however wished", and styling within the block is done separately. It’s not intended to do anything more or less.
- yellowapple 10y ago
  "But the shit ton of semantically meaningless divs that are sprinkled around the structure to provide hooks for CSS declarations in the 'usual' style of doing layouts is somehow better?" No, it's not, as I thought I made plainly clear in my comment. HTML5 introduced a smorgasbord of new tags to avoid that. You're right that a lot of modern web development fashion is silly, but there are alternatives besides just sticking to tables for everything.
andreareina 10y ago
w.r.t. avoiding div and class, how do you make sense of the element <-> rule mapping? There's definitely enough specificity to make such a mapping, but I just end up with a big bowl of spaghetti. EDIT: I guess I'm mostly talking about class, HTML5 semantic elements takes over much of the utility of divs in this usecase.
- yellowapple 10y ago
  I usually just base it on whether or not an element is a direct child of some other element. For example, the header of the page itself will usually have a different style than the header of an article or aside or something, so I can use CSS' child selectors for that. This often does indeed result in a bowl of spaghetti, but said bowl is in CSS rather than HTML. Things like SASS/SCSS help tremendously.