oddbird / susy

Pre-grid responsive layout toolkit for Sass, now deprecated
http://oddbird.net/susy/
BSD 3-Clause "New" or "Revised" License
3.87k stars 348 forks source link

Container on body or helper div? #628

Closed ghost closed 7 years ago

ghost commented 7 years ago

Given the simple modern website structure example layout from MDN I was wondering where to put the container?

<body 
  <header>
    <h1>Header</h1>
  </header>

  <nav>
    <!-- main navigation in here -->
  </nav>

  <!-- Here is our page's main content -->
  <main>
.
.
.

The docs use container on the body tag, however Zell writes that doing so is not a good idea.

What should I follow?

The reason why I posted the HTML above is because of what I want to achieve with it. Something like this http://www.wilsonfletcher.com/ from a layout point of view.

Ideally the header and nav will be one area/section of the layout, where the company/website name will be top left and the nav top right. So in order to have two separate boxes inside that area I would have to do something like this, no?

<body 
  <div id="susy-header-container">
    <header>
      <h1>Header</h1>
    </header>

    <nav>
      <!-- main navigation in here -->
    </nav>
  </div> <!-- #susy-header-container end -->

  <!-- Here is our page's main content -->
  <main id="susy-main-container">
.
.
.

Then the nav will contain menu items that I like to be nested inside the nav area.

Am I correct in understanding that when I set the container on the body it will set it for the header, nav, main and footer area or can I set a new container on the main tag, for example with <main id="susy-main-container"> that would follow directly under the nav tag?

Just started with Susy, since I am broke I will have to wait till I can afford Zell's book, so I am using the docs and this smashingmagazine post to get a basic layout going. Leveluptuts also puts container on the body tag. Properly confused about where to put the container now, hehe.

However I like to learn things properly from the ground up and know what I am doing, so I came here to ask about what the best practice for this would be using Susy. Asking something like this on StackOverflow is not appreciated as it might be perceived more of an opinion based question rather than a technical/coding best practise, plus it is Monday and I cannot take that kind of nitty gritty today.

Needless to say if I could somehow do this without using the extra #susy-header-container I would prefer that, trying to keep the HTML as clean as possible. Also considering class or id for either the header or main tags, since they only come up once per page, is it OK to use ids there? Gosh the more I know about this the more I feel like I am possibly doing it all wrong, horrid feeling..

Thank you for your advice on this matter.

mirisuzanne commented 7 years ago

The container is not required. All it helps you do is constrain a grid width - so the only rule is: use it where you need the overall grid-width constrained. On a design like the one you linked, that often means you need containers inside some, but not all, sections.

<section class="full-width-background-stuff">
  <!-- stuff in here can be full-width -->
  <div class="container-to-constrain-line-lengths">
    <!-- stuff in here has a constrained max-width -->
  </div>
</section>

Most demos show you the simplest use-case, where you want the entire document constrained to the same max-width. There's no reason you have to do it like them, or even use containers in the first place.

ghost commented 7 years ago

Thank you for your informative reply.

The past couple of days I have been working with your advice and now again I find my understanding overthrown by wanting to make a centred fixed header with a width of 1200px for example. As long as I keep the position static it is all fine, when I make it fixed it does not respect the set container width any more.

Yes, I do know fixed elements break free from the document flow, so this behaviour is expected. This means it does not care about the set container width any more and therefore I would have to create a separate container with a max-width inside the fixed header, no?

I have come up with something but here I have a full fixed header from the beginning onwards. http://www.sassmeister.com/gist/a77da1f77143f2fac4bd11e428206b96 Is this how you would go about creating this type of layout with susy? Am I missing something here?

Is it possible to have a fixed centred header with setting a container of 1200px in the susy setup and then inside that container for example have a company/brand div with span(10 of 16) and menu div with span(4 of 16) without actually having to wrap the company div and menu div inside the fixed header into another div giving it the desired the max-width?

What I mean is something like this.

SCSS
$susy: (
  container: 1200px;
);

HTML
<header>
  <div class="fixed-core">
    <div class="company">Brand</div>
    <div class="menu">Menu</div>
  </div>
</header>

SCSS/CSS
header {
  position: fixed;
  @include span(16 of 16); // 1200px max-width is gone due to fixed positioning, right??
}

.fixed-core {
  max-width: 1200px; // or have a new susy container here??
  margin-left: auto;
  margin-right: auto;
}

.company {
  @include span(10 of 16);
}

.menu {
  @include span(4 of 16 last);
}
mirisuzanne commented 7 years ago

The solution on Sassmeister works by creating a full-width grid, and pushing elements center. That's a fine approach, but probably more work than needed. I'd probably define multiple smaller centered grids, like you suggest in your code clipping – one inside and one outside the fixed header:

header {
  position: fixed;
  width: 100%; // no need for `span` here, it does too many things
}

.fixed-core {
  @include container;
}

article {
  @include container;
}

As a side note: I almost never recommend span(full) or span(16 of 16) (the same thing) - because block elements are full-width by default, and you rarely need all the output that comes with span (floats, margins, clearing, etc).

ghost commented 7 years ago

..and again many thanks for your quick reply and the many tips you give. Something I so far have not found in tuts (perhaps I am not looking in the right places..).

I guess I can live with an extra HTML element introduced as opposed to pushing elements centre. Also understand much better now how to use the container, thank you.

Started using Susy to write cleaner HTML but see that with a fixed header the .fixed-core approach can be regarded as cleaner as well, it certainly has less CSS output what I also try to keep as minimal as possible.

Will tweak this approach and post the code thereafter, perhaps with a sample Sassmeister or Gist, then close this issue (or keep it open for other devs starting out with your Susy?), rest assured your input is highly appreciated.

mirisuzanne commented 7 years ago

No problem! I know I've answered this question on stackoverflow in the past, but not sure about other tutorials. The extra-div limitation doesn't really come from Susy - it's just a limit of CSS. I generally always recommend finding the cleanest CSS/html solution, and then seeing where Susy can help add meaning, or keep your math simple. The push/pull option gives cleaner html, but at the expense of CSS. I think the extra div is a good balance for both.

I'll close. People can still search closed issues.

ghost commented 7 years ago

Yes, this clearly is a limit of CSS and not Susy, I see what you mean now and will go with the added .fixed-core approach.

There is one last observation I can make, though again this might not be directly related to Susy as well as not being a limit of CSS, however it does affect Susy.

Using Indrek Paas' fluid-type mixin on the html or body tag will mess with the Susy container in the sense that for the .fixed-core width set in the em unit the width will not be respected or in fact be way more than what the calculated value would be at a baseline of 16px whereas values set in the px unit for width will work indeed.

http://www.sassmeister.com/gist/d03575a967842b9452eaa54ae96192e1

The Susy container in em is stretched out, the container in px is correct.

So setting the Susy container in the em unit makes it fluid, ok yes, but what are these, in the example, 20em based on if not on a baseline of 16px? What is the reference for those 20em and why does it work when I set it with px?

mirisuzanne commented 7 years ago

That link doesn't work for me, but that sounds like expected behavior. em values are relative to the current font size - not a 16px default. If you set a responsive font-size, and a container based on that font size, you'll get a responsive container. That's not a bug, or "wrong" - it's useful for building flexible containers that retain line-length. If you want a static container, you should use static units (like px).

ghost commented 7 years ago

Ok, I understand all this much much better now, and yes, em being relative to the current font-size makes a lot of sense.

Strange the link is gone, even bookmarked it and did work couple hours ago, oh well, will make a new gist and update the link for others to see and be able to learn from all this like I did.

Much better understand how to use container, responsive typography and that mixed with em or px values depending on what I need, ah I like all this so much, thank you for actively developing this, I have a feeling I will learn a lot lot more from using Susy in the time to come.

edit All the saves on Sassmeister, at least mine, seem to be gone, well the gists are there in my GitHub account but the links to them on Sassmeister are gone, not sure what is going on.. also the links further up this issue that you have seen are now gone.. strange..

ghost commented 7 years ago

While SassMeister sorts this out here is the final code I have been using along a link to the SCSS on SassMeister.

Miriam, thank you indeed very much for your help and support, I will keep exploring Susy as more advanced layouts are needed and must say I am very happy I started using Susy, once you get your head round it it just aids perfectly to the workflow enabled devs to swiftly create a solid layout. Thank you.