search

html-next / flexi

Just a layout framework. Design for cross-platform with ease.
https://flexi.readme.io/docs
MIT License
219 stars 36 forks source link

Orientation and layouts #42

Closed yankeeinlondon closed 7 years ago

yankeeinlondon commented 8 years ago

This isn't really an "issue" but more request for your views and/or place for discussion on views regarding how "orientation" might participate in layouts.

yankeeinlondon commented 8 years ago

My initial thought was it would be nice to have the "breakpoints" be the primary model, and "orientation" be considered secondary. My thinking being that "overall real-estate" (aka, breakpoint) is a primary concern and causes design restructuring. However orientation, when it is being design for, is typically even more divergent in design (often not just reflowing but different content). In most cases, I think orientation benefits from breakpoints concern as well which is why I see a tiered model making sense.

Here how you might employ the template generator (I think dot syntax makes more sense than further depth in the current path):

ember g layout /component/page-example/mobile.portrait 
ember g layout /component/page-example/mobile.landscape

Haven't spent a lot of time thinking about this but interested in your reaction.

yankeeinlondon commented 8 years ago

Ok, I noticed in the README documentation (but not the "doc site") there is reference to orientation. What I don't like about the current implementation is that it treats orientation and device as independent variables which is probably not the way you want to design things (first reaction).

Maybe if the tiered format were used, the breakpoints could be compared to the larger dimension rather than statically to the width?

runspired commented 8 years ago

Currently, width is considered the primary driver of layout, and orientation secondary.

Some of the problems with using orientation for additional layout options are:

  1. Orientation is purely derivative of the aspect ratio, there unfortunately are not device APIs which we can rely on to reliably give us the true orientation.
  2. Breakpoint names are purely derivative of the width, and not necessarily reflective of a "true state". e.g. mobile and tablet are sizes, not devices.

I've been brainstorming ways to get better "true state" access, but the DOM apis for doing so are incomplete, and the user-agent / platform regex options are brittle.

Regardless, the suggestion of allowing secondary layout states within a primary breakpoint interests me. It could be that "true states", if able to be known (or reasonably guessed), could all be secondary layout states within the primary width based breakpoint.

yankeeinlondon commented 8 years ago
  1. Orientation is purely derivative of the aspect ratio, there unfortunately are not device APIs which we can rely on to reliably give us the true orientation.

Yes but I would propose that that is actually is more meaningful than "true orientation". In photography and other domains that use this nomenclature "portrait" and "landscape" is just shorthand for whether width or height is greater length. This is also the key characteristic that you'd want to design to.

  1. Breakpoint names are purely derivative of the width, and not necessarily reflective of a "true state". e.g. mobile and tablet are sizes, not devices.

Yes I think feature detection and user-agent sniffing, etc. is a measure of last resort and certainly shouldn't find a home in something like flexi but similar to the above point I think there is a clear benefit to modifying the "breakpoint" pattern to not rely on width but instead use the largest side. In CSS this is problematic but in Javascript we can reliably pick up both dimensions.

For this to work you would have to assume a default aspect ratio but by just defaulting to 16:10 you'd immediately have a breakpoint measure which would be more useful than a width-only measurement.

runspired commented 8 years ago

I think there is a clear benefit to modifying the "breakpoint" pattern to not rely on width but instead use the largest side.

You just caused so many thoughts to enter my mind. I'm going to think this over. I'll be going on vacation for a while starting early next week, I'll ponder this while away.

yankeeinlondon commented 8 years ago

Well have a great break. Try to think non-ember thoughts on your time off. :)

I have an addon called ui-responsive and I figured I'd demonstrate what I'm talking about using it. That's now done, have a look when you have time:

https://ui-responsive-toolbelt.firebaseapp.com/

I need some z's. Talk to you later.

greyhwndz commented 8 years ago

this nomenclature "portrait" and "landscape" is just shorthand for whether width or height is greater length.

Looks like this could be a good basis of implementing orientation-related logic. Makes sense and I think devices in general should leverage on this. There ain't no "landscape" orientation where the height is larger than width :)

On the other hand, since flexi base its magic from detecting the width and height of the 'container' element may have a bearing on how this will further be implemented. There are still some gray areas for me regarding flex (still learning/exploring it) but as far as I understood the concept upon which flexi leverages its functionality, it may have a bearing on the 'semantics' of orientation.

RobbieTheWagner commented 7 years ago

I'm unclear on why this is needed. If you just design your content based on width, most things will look okay across all breakpoints. Can someone elaborate on why this is needed?

yankeeinlondon commented 7 years ago

Do you mean setting flex-basis and width via stylesheets? This was meant to take a component of the page and fix the width to a discrete width and then allow "fill" to use the remaining space rather than the grid system which is some arbitrary percentage of available real-estate. It's mainly exposing the flex-basis functionality of flexbox to the flexi API.

RobbieTheWagner commented 7 years ago

@ksnyde was this comment meant for another issue? This issue is about orientation.

yankeeinlondon commented 7 years ago

Yes sorry I was in hurry in my last response. Not to mention a bit jet-lagged from moving half-way around the world. Anyway, now that my excuses are out of the way ... this issue is a little dated so I'm fine with it being closed. When I get back to Flexi (hopefully soon) I may come back to this and see if I think it's worth restating but not sure it is.

RobbieTheWagner commented 7 years ago

@ksnyde no problem. Hope your move went well! I'm just trying to prune the issues here, as we move toward 2.0. Please feel free to reach back out if you feel there is a need to implement something.