Use this to demonstrate Adaptive, Responsive, Static and Liquid | Hacker News Reader

Use this to demonstrate Adaptive, Responsive, Static and Liquid

liquidapsive.com

71 pointsjohnpark11 comments

I've never heard this distinction between adaptive and responsive. The article claims that responsive layouts are series of liquid layouts while adaptive layouts are series of static layouts. I was under the impression that "responsive" refers to all usage of media queries to swap layouts, and it just so happens that most of the time liquid layouts are used.

I haven't heard of adaptive before either, but I kind of like it. The original book on responsive design spent a lot of time talking about how to correctly make liquid layouts, and heavily advocated for their use along with media queries. It wasn't until Bootstrap that responsive design also started meaning static layouts with media queries.

It's nice... and also very wrong, if you take the initial definition of adaptive web design!

Adaptive web design as introduced by Aaron Gustafson in the "Adaptive Web Design" book has little to do with layout design, and everything to do with progressive enhancement and adapting the website's behavior to the browser's abilities (geolocation, ...)

But I guess, most people didn't read the book, and now everyone has their own definition for it, so in effect, it doesn't mean much anymore; some say it's non-fluid RWD (like here), some say it's server-side components (like most people), some say it's exactly the same as RWD... oh well, pick your favorite!

I had this idea about using a "utility" function to represent how useful a given amount of screen space is to each widget, and then choosing the layout that maximizes the sum of the utility functions. It hasn't gained any traction, and I haven't had time to implement it myself.

See http://gtk.10911.n7.nabble.com/Idea-for-automatic-widget-lay... for more details.

I quite like this idea. A lot of toolkits already allow a widget to specify a "preferred size." I wonder if a simpler approach to your idea would be similar to e.g. the Accept-Content-Type HTTP header; a widget lists a series of preferred widths (or width ranges) with weights.

  preferred-width: 300px, 1.0; 200px..299px, 0.7; 100px..199px, 0.5;

That's slightly less flexible than a utility curve function, but (especially if ordered) is far easier to optimize for, as choices are ordered and restricted.

When do you use em for height/width on boxes? And why not use % instead?

Most illustrative. Thanks!

Did this site really deserve its own domain? We (as the internet) really ended up misusing the domain system and the only one benefiting from it are those selling domains.

To be fair, the odds of somebody else wishing they could have purchased "liquidapsive.com" for a different purpose are fairly low.

I can't really see a downside to this page having its own domain name. Also your point makes no sense... clearly liquidapsive.com is much more memorable than http://www.yahoo.com/geocities/en/us/~liquidapsive/home.html

So, no, domain (re)sellers aren't the only ones benefiting. And TBH the credibility of your statement is questionable given that ICANN doesn't directly sell domain names anyway.

Well as a common practice seems to be to always go trough google for everything, I'm actually not sure if it does matter?

Besides, even if it where some github.io page or something, I got the link here, now I can bookmark it.

Half a year from now i wont remember liquidapsive.com or http://www.yahoo.com/geocities/en/us/~liquidapsive/home.html anyway.

I actually don't think using domains instead of paths or sub-domains makes things easier at all. Here's an example. Lets say you wan't to know about the latest playstation. Where do you go? ps.com, playstation.com, playstation4.com or sony.com? As a non gamer, I have no idea but I know its made by Sony so I guess that's where I'd go.

Reply on news.ycombinator.com