container responsiveness #186

Closed
PSeitz opened this Issue Dec 10, 2014 · 14 comments

Projects

None yet

5 participants

@PSeitz
PSeitz commented Dec 10, 2014

On mobile you usually want to utilize the whole width, the container class could use some better defaults instead width 80% for smaller devices.

@luisrudge

agree! maybe something like 98% for smaller devices

@luisrudge

or 100% with a little padding

@deeve007

And that would be for the developer to decide per project, no?

I prefer my "starting framework" to have narrower width of some kind, then if I want certain elements to go full width (ie. header) it's simple enough to add negative margins in my project specific CSS.

@luisrudge

@deeve007 if you think like that, you'd have to write everything from scratch every time. This project is awesome because it has sensible defaults. 80% on the desktop? That seems pretty reasonable. 80% on mobile? Not reasonable at all. You're losing 20% of content and that doesn't seem the default for the mobile web of today. My point is that the default should be changed for mobile and should the developer wants to make it 80%, it's the dev's call.

@deeve007

Why are you writing it from scratch? Any dev would first make their own custom changes to this anyway to create their own "base" framework, so if you don't like 80% change it to what you want. I'm guessing (going on the base frameworks I've created for my own projects) that the skeleton dev has chosen 80% as it's what he uses for most of his projects. If I decide to start using skeleton (and I'm liking the changes that have been made, especially to go mobile first) then I will fork and make the minor changes to make it "my" starting framework. That is what github is for.

@luisrudge

I'm not writing from scratch. Hell no :) My point was that the 'base' should be discussed. It's not about doing this for you or for me, but 80% on mobile doesn't seem like a common thing on mobile websites. Because of that, I think the default should be what's being done on mobile web today - and that's 100%.

@deeve007

Then we disagree on what's being done today? I don't think there's any "standard", and I haven't done many projects at all with mobile width being 100%. I do set negative margins for some elements, such as header and/or footer for example, but my wrapper DIV by default is certainly not 100%.

But I'll leave that choice up to Dave, since he's been generous enough to release this for everyone's use. ;)

@luisrudge

Ahh, I see what you mean now! I think we're talking about the same thing - but in different ways.
I prefer everything 100% and wrap my content inside 80%.
You prefer everything 100% and your "full width" components with 100% (or negative margins).

It's just different ways to achieve the same thing.

@PSeitz
PSeitz commented Dec 10, 2014

I would go for 100% as well.
Negative margins seem like a bad idea, that's the reason bootstrap is broken on phones (horizontal scrolling issue in some cases)

@luisrudge

Yeah, I understand @deeve007's point, but I think it's easier to wrap your content in your preferred width, than use negative margins

@deeve007

I haven't seen any instance where using negative margins in this way "breaks" on phones, would love to see an example.

And in my experience negative margins requires less code, and is more flexible, hence why I use that method.

@Madebym
Madebym commented Dec 11, 2014

Most definitely not 80% for mobile!! But this raises up a few more questions in my mind, Skeleton should really add some more grid related utillity classes for easier development.

I am all for simplicity and bare bones when starting, but I really feel that some important things are missing. Offsetting columns, would be nice to have them, but not a game breaker.
Edit: Just now saw that offsetting columns were added :)

What I really need are classes that allow me to have some columns stay the same on mobile and not stack. Maybe I want to have them stack on tablet size, etc. This so much helps in development, with Skeleton as it is now, the only option is to have collapsed rows on mobile, it needs more flexibility in this department.

@dhg
Owner
dhg commented Dec 11, 2014

Hey ya'll - thanks for digging into this. I see what you mean on the grid limiting to 80% width on mobile. I always kinda worked around this by actually closing the .container and then creating a parent element to it, then re-wrapping the .container in that to create a 100% width parent with an 80% .container, but this does seem inefficient. Lemme dig into how this could be better and see if it's something I can improve on.

@dhg dhg added this to the v2.0.2 milestone Dec 11, 2014
@dhg dhg added the other label Dec 11, 2014
@dhg
Owner
dhg commented Dec 16, 2014

Alright everybody - I just packaged up v2.0.2 and made some updates that satisfy some of the issues here, but not all of them. Here's what's new:

  • .container is width: 100% with 20px of left/right padding at any viewport smaller than 400px
  • .container is width: 85% for viewports between 400-550px
  • .container is width: 80% for viewports between 550px and larger

What this release does not address is the issue discussed about negative margin-ing and need for "full-width" sections. This is how I see it – I experimented with a number of different options in a separate branch (https://github.com/dhg/Skeleton/tree/update-grid-test) including even a very Bootstrap-esque grid with negative-margins etc. In the end, the best solution for this I believe, is to add a simple wrapper (this is what I do in the landing page example fwiw:

<-- full bleed section -->
<section class="section">
  <div class="container">
    <-- content to be in grid -->
  </div>
</section>

Since it's totally fine to have more than one .container in a page, this totally makes sense to me as the right way to create a full-bleed section that contains contents the same as any other .container content.

Closing this for now, but let me know if I missed anything or there's further discussion to be had!

@dhg dhg closed this Dec 16, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment