Hacker News Reader

Comment by have_faith | Hacker News Reader

The problem with all of these responsive grid systems is that they are opinionated about how a component responds.

Responsiveness is not a document level problem, it's a component level problem and each component has it's own concerns. One component might keep the 2up grid from desktop to mobile, another might collapse to single column half way, and so on. Having generic desktop and mobile class names ala bootstrap doesn't solve this. You end up with components that have to collapse at pre-defined points and a massive amount of class soup on your containers.

This is related to the fact that components respond to the window width and not their parent containers size. Components are very dumb right now, we need smart components that understand their surroundings beyond the window. Then we will have truly portable components!

View on HN

The problem with all of these responsive grid systems is that it's so easy to do a grid in plain CSS with flexbox and media queries that they're close to zero added value in almost all cases.

I just wanted to say the same :)

Agreed, flexbox is one of the best things to happen to CSS in a very very long time.

> very very long time.

It's sad really. Table-based layouts have been considered bad practice for years but CSS is only just now becoming a superset. That is if you're lucky enough to be free of old browsers. If you want everything to "just work" tables are still the practical choice to this day. Kudos to PG for sticking to what he learned in the 90's when he built HN.

Yes! It's sad that table-based layouts became "bad practice". Generally they're a lot simpler to understand than the mess of CSS and bizarrely named divs we have today.

I think part of the reason tables became considered "bad" was that back at that time most web pages were built by interspersed HTML and ASP or PHP code and getting all the TR and TD tags balanced especially with rowspans or colspans thrown in quickly became a mess. Every page was a standalone thing also, it was much less common to see templating systems used to establish the overall structure of the site. So if you ever got the assignment to "reskin" a website, it was a huge amount of very tedious work making repeated similar changes to all the tables and other markup on every page.

Today we have much better ways to create an overall layout and separate markup from content. Using tables today would be a lot less of a problem than it was when they were decreed to be "bad."

From what I could tell, it is because HTML tables have a specific structural meaning, which is among other things used by screen readers. So if used properly, a person who needs a screen reader could reliably have the contents of a table read to them, but if it's used for layout the result is useless. There seems to be enough people conscious of this that use of tables for layout has always been frowned on. Now there are better hints for screen readers, ,but tables are still useful for screen readers "out of the box."

In any case, tables are not nearly as flexible as a true responsive layout.

Yeah a huge part of this too was, for whatever reason, old search engines not being able to index what was inside of tables. I imagine it's not even like that anymore.

An important reason that table based layouts became obsolete in HTML is because the way table cells are rendered is not the same as how `div`s are rendered. It's shockingly difficult to get a table cell to keep a consistent size. This makes some sense if you're using it as a simple data container, but doesn't work at all if you're trying to use it as a generic content container the way we use `div`s

Also, if by "bizarrely named divs" you mean things like "section", "article", "header", "footer", etc., I have to disagree; I think these are a huge improvement in terms of readability and allowing a developer to communicate the intended purpose and structure of the code, and they offer significant advantages in accessibility as well. You ask me, the semantic web is a wonderful thing

> Components are very dumb right now, we need smart components that understand their surroundings beyond the window. Then we will have truly portable components!

This is the iceberg problem. Component based programming has been around since probably the 60's. The easy part is making components. The hard part is making them (and this is the Holy Grail), portable. Pipes and Filters in the Unix OS is a simple example of one form of component development that actually works well.

This is what I feel is missing from web components. Some sort of generic api for components to reason about their immediate environment. Similar to the Unix OS pipes and filter api that means every program understands how to get some information about the context that it is being run in.

It's not difficult to imagine a calendar component that needs to visually display vastly differently depending on how much space it's parent gives it. Currently there is no generic way to solve this.

> It's not difficult to imagine a calendar component that needs to visually display vastly differently depending on how much space it's parent gives it. Currently there is no generic way to solve this.

Maybe I'm being naive here, but isn't this solved really by getting the width of a block level element rendered by the Calendar component?

Yeah it does mean you need to get the width and then render everything else, but it's doable.

I think a lot of these grid systems and layout libraries are overkill, and in turn, make the designs they are being used for, more complicated than they need to be.

Sure, it would be great to have a more component focused tool for FE development, but I think creating separate, fixed-width designs for tablet, phone, and desktop, with containers does the job fairly well. When the designs try to resize components for every use case you get more headache than it's worth.

I think the sole exception to this might be a full-blow library for Material Design since it's the only open standard we have right now, and it's very, very good.

> Responsiveness is not a document level problem, it's a component level problem and each component has it's own concerns.

Responsiveness is both (you build responsive pages/documents, but you can only reuse responsive components) and that's very much the issue: the tooling only supports responsive documents, but not responsive components.

Have you tried EQCSS(http://elementqueries.com/) ?

The concepts looks good, bu I haven't seen anyone recommending it .

It's because element queries are undecidable in the general case. A better approach is a constraint solver, which is how GSS[1] works.

[1]: https://gridstylesheets.org/

One of the demos on the EQCSS website is a responsive grid where the breakpoints are based on the grids own width, not the width of the browser. This seems to be what the parent comment was talking about.

Element query grid demo: http://elementqueries.com/demos/element-query-grid.html

Reply on news.ycombinator.com