3 ms·

I think this is absolutely incredible. This is exactly how I've always envisioned responsive design. I'm really looking forward to the usual HN pessimistic dis

I think this is absolutely incredible. This is exactly how I've always envisioned responsive design. I'm really looking forward to the usual HN pessimistic discussion on why this is bad/wrong/could be done better. I know a lot of people don't like the negativity, but I really enjoy it because I get pumped up about stuff like this. WSJ is pretty reputable too. MIT licesnse for everything Copyright (c) 2012 The Wall Street Journal, http://wsj.com/ http://wsj.com/

cheald 13y ago
My biggest complaints with it are that this mixes up content and presentation concerns again and we already have great tools for declarative responsive design. After however many years of working to get people to separate their content from their presentation, tools like this rush back in and encourage people to again start smashing them together. Being a Javascript tool, it also means that if a client doesn't run your JS for whatever reason, your entire site becomes rather unusable (you'll notice a lack of default/fallback classes and whatnot in the examples provided). > Where should your advertising code get placed when you're on a desktop? Does the page require an alternate slideshow widget on touch enabled devices? These are adaptive content concerns (the type of content served is adapted to fit the client, generally through progressive enhancement), rather than a responsive concerns (the content served is presented according to the client's metrics and capabilities). Completely valid use case here, IMO. Pitching it as an adaptive content library would be much nicer, because there actually is a need for good tools to do that well, whereas responsive content is basically fully handled by media queries and a tiny sprinkling of non-presentational Modernizr.
- jmhnilbog 13y ago
  The lib is very, very flexible, so you could code a responsive site that worked via non-JS methods, then use it solely for progressive enhancement. It's basically a way to set arbitrary content rules within the content (A relates to B in a certain way when this is true, and in a different way when that is true) and define the interactions, reasonings, and timing in the script.
  - cheald 13y ago
    Completely agreed, and I like it a lot for that use case. I'm just not wild about it basically being pitched as a married-to-the-markup alternative to CSS.
- untog 13y ago
  After however many years of working to get people to separate their content from their presentation Counter-point: content and presentation are not always separate. Particularly in news (this comes from the Wall Street Journal) immersive articles like Snow Fall (http://www.nytimes.com/projects/2012/snow-fall/ http://www.nytimes.com/projects/2012/snow-fall/) are very popular. We need to cover those cases, too.
  - cheald 13y ago
    Acknowledged and agreed. I work in news, and believe me, Snow Fall comes up frequently. But, it's worth noting that while the presentation is a major part of the experience there, it's also an extremely mobile-unfriendly experience. It's a beautiful, gorgeous presentation that makes some very specific assumptions about the classes of devices it's going to render on - entirely the opposite intent of something like this library.
- peterhunt 13y ago
  I'm concerned less about clients not running JS (well, Googlebot, but solvable) but more about the first-load page experience being weird. I wonder how they've solved this. However I really have to challenge the idea that separating content and presentation concerns is a worthwhile endeavor. The idea of CSS selectors was introduced to reduce the coupling of style and markup in the name of "separation of concerns" and is arguably the least-maintainable technology we have to deal with on the Web today. It increases complexity because markup and presentation will always be tightly coupled and hey, they're pretty cohesive too, and CSS gives us a big global namespace and thrown-together specificity semantics that aren't backed by any underlying theory. Now that we have ARIA the accessibility excuse for separating presentation from content loses much of its weight. And really, how many times have you completely reskinned a site with just CSS? You can't even change the order of inline items. BTW, I'm not a CSS hater per se -- I really like media queries, how it describes text, and many of its layout options -- but the idea of using selectors to decouple it from the DOM has resulted in far more problems than solutions.

cheald 13y ago

My biggest complaints with it are that this mixes up content and presentation concerns again and we already have great tools for declarative responsive design. After however many years of working to get people to separate their content from their presentation, tools like this rush back in and encourage people to again start smashing them together. Being a Javascript tool, it also means that if a client doesn't run your JS for whatever reason, your entire site becomes rather unusable (you'll notice a lack of default/fallback classes and whatnot in the examples provided). > Where should your advertising code get placed when you're on a desktop? Does the page require an alternate slideshow widget on touch enabled devices? These are adaptive content concerns (the type of content served is adapted to fit the client, generally through progressive enhancement), rather than a responsive concerns (the content served is presented according to the client's metrics and capabilities). Completely valid use case here, IMO. Pitching it as an adaptive content library would be much nicer, because there actually is a need for good tools to do that well, whereas responsive content is basically fully handled by media queries and a tiny sprinkling of non-presentational Modernizr.

jmhnilbog 13y ago
The lib is very, very flexible, so you could code a responsive site that worked via non-JS methods, then use it solely for progressive enhancement. It's basically a way to set arbitrary content rules within the content (A relates to B in a certain way when this is true, and in a different way when that is true) and define the interactions, reasonings, and timing in the script.
- cheald 13y ago
  Completely agreed, and I like it a lot for that use case. I'm just not wild about it basically being pitched as a married-to-the-markup alternative to CSS.
untog 13y ago
After however many years of working to get people to separate their content from their presentation Counter-point: content and presentation are not always separate. Particularly in news (this comes from the Wall Street Journal) immersive articles like Snow Fall (http://www.nytimes.com/projects/2012/snow-fall/ http://www.nytimes.com/projects/2012/snow-fall/) are very popular. We need to cover those cases, too.
- cheald 13y ago
  Acknowledged and agreed. I work in news, and believe me, Snow Fall comes up frequently. But, it's worth noting that while the presentation is a major part of the experience there, it's also an extremely mobile-unfriendly experience. It's a beautiful, gorgeous presentation that makes some very specific assumptions about the classes of devices it's going to render on - entirely the opposite intent of something like this library.
peterhunt 13y ago
I'm concerned less about clients not running JS (well, Googlebot, but solvable) but more about the first-load page experience being weird. I wonder how they've solved this. However I really have to challenge the idea that separating content and presentation concerns is a worthwhile endeavor. The idea of CSS selectors was introduced to reduce the coupling of style and markup in the name of "separation of concerns" and is arguably the least-maintainable technology we have to deal with on the Web today. It increases complexity because markup and presentation will always be tightly coupled and hey, they're pretty cohesive too, and CSS gives us a big global namespace and thrown-together specificity semantics that aren't backed by any underlying theory. Now that we have ARIA the accessibility excuse for separating presentation from content loses much of its weight. And really, how many times have you completely reskinned a site with just CSS? You can't even change the order of inline items. BTW, I'm not a CSS hater per se -- I really like media queries, how it describes text, and many of its layout options -- but the idea of using selectors to decouple it from the DOM has resulted in far more problems than solutions.