6 ms·

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 probl

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!

JustSomeNobody 10y ago
> 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.
- have_faith 10y ago
  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.
  - mikewhy 10y ago
    > 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.
- aarmenante 10y ago
  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.
  - YngwieMalware 10y ago
    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.
masklinn 10y ago
> 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.
calinet6 10y ago
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.
- starikovs 10y ago
  I just wanted to say the same :)
- YngwieMalware 10y ago
  Agreed, flexbox is one of the best things to happen to CSS in a very very long time.
  - MawNicker 10y ago
    > 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.
    - icedchai 10y ago
      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.
      - ams6110 10y ago
        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."
rtcoms 10y ago
Have you tried EQCSS(http://elementqueries.com/ http://elementqueries.com/) ? The concepts looks good, bu I haven't seen anyone recommending it .
- quarterto 10y ago
  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/ https://gridstylesheets.org/
- err4nt 10y ago
  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 http://elementqueries.com/demos/element-query-grid.html

JustSomeNobody 10y ago

> 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.

have_faith 10y ago
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.
- mikewhy 10y ago
  > 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.
aarmenante 10y ago
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.
- YngwieMalware 10y ago
  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.

masklinn 10y ago

> 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.

calinet6 10y ago

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.

starikovs 10y ago
I just wanted to say the same :)
YngwieMalware 10y ago
Agreed, flexbox is one of the best things to happen to CSS in a very very long time.
- MawNicker 10y ago
  > 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.
  - icedchai 10y ago
    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.
    - ams6110 10y ago
      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."

rtcoms 10y ago

Have you tried EQCSS(http://elementqueries.com/ http://elementqueries.com/) ? The concepts looks good, bu I haven't seen anyone recommending it .

quarterto 10y ago
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/ https://gridstylesheets.org/
err4nt 10y ago
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 http://elementqueries.com/demos/element-query-grid.html