Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider Vertical Rhythm #11601

Closed
heyallan opened this issue Nov 23, 2013 · 14 comments
Closed

Reconsider Vertical Rhythm #11601

heyallan opened this issue Nov 23, 2013 · 14 comments
Labels

Comments

@heyallan
Copy link

Bootstrap CSS adds margin-bottom to some components and margin-top to others. Then if, for example, you start a new row with a h1 (which has margin-top) it will be "natively" pushed away from the previous component creating a good sense of component separation right out-of-the-box. In contrast if you start the row with something like a div.carousel (which has NO margin-top) it'll stick to the previous component without any spacing in between, breaking the rhythm reached so far.

Also double margins create collapsing margins very often. Thus we have to create unnecessary "spacer" divs and custom CSS classes either to add margins or to keep collapsing margins under control.

Harry Roberts has made a great work explaining why this is important: http://csswizardry.com/2012/06/single-direction-margin-declarations/.

Now can vertical rhythm be re-considered to eliminate margin-top in favor of margin-bottom only?

@carasmo
Copy link

carasmo commented Nov 24, 2013

Yes!

@leeaston
Copy link

Me too!

@mdo
Copy link
Member

mdo commented Nov 24, 2013

Yeah, I've been feeling the pain on this one as well. We added the top margins in v3, I think. I override these quite often.

I'm not sure if this is something we can easily change without breaking backward compatibility. We need to set more explicit rules about that and document them in our repo somewhere. My gut feeling is this, with regards to CSS explicitly:

  • Backward compatibility only applies to functionality, class names, mixins names, and variables.
  • Backward compatibility does not apply to specific values like margin, padding, font-size, etc.

I know this devolves this thread into something else, but fuck it, let's hash it out because that's the bigger problem here. Thoughts from the community, @cvrebert, and @juthilo?

@StevenBlack
Copy link
Contributor

Here is everywhere in LESS files where margin-top is set to something other than zero.

less/alerts.less:32:    margin-top: 5px;
less/button-groups.less:200:    margin-top: -1px;
less/buttons.less:148:  margin-top: 5px;
less/carousel.less:121:    margin-top: -10px;
less/carousel.less:214:      margin-top: -15px;
less/forms.less:46:  margin-top: 1px \9; /* IE8-9 */
less/forms.less:179:  margin-top: 10px;
less/forms.less:199:  margin-top: -5px; // Move up sibling radios or checkboxes for tighter spacing
less/forms.less:278:  margin-top: 5px;
less/media.less:19:  margin-top: 15px;
less/mixins.less:546:  margin-top: ((@navbar-height - @element-height) / 2);
less/modals.less:81:  margin-top: -2px;
less/modals.less:99:  margin-top: 15px;
less/navbar.less:194:    margin-top: 4px;
less/navs.less:157:      margin-top: 2px;
less/navs.less:259:  margin-top: -1px;
less/panels.less:135:      margin-top: 5px;
less/popovers.less:26:  &.top     { margin-top: -10px; }
less/popovers.less:28:  &.bottom  { margin-top: 10px; }
less/popovers.less:89:    margin-top: -@popover-arrow-outer-width;
less/popovers.less:120:    margin-top: -@popover-arrow-outer-width;
less/scaffolding.less:99:  margin-top:    @line-height-computed;
less/tooltip.less:17:  &.top    { margin-top:  -3px; padding: @tooltip-arrow-width 0; }
less/tooltip.less:19:  &.bottom { margin-top:   3px; padding: @tooltip-arrow-width 0; }
less/tooltip.less:65:    margin-top: -@tooltip-arrow-width;
less/tooltip.less:72:    margin-top: -@tooltip-arrow-width;
less/type.less:96:  margin-top: @line-height-computed;
less/type.less:107:  margin-top: (@line-height-computed / 2);

Edit: And here's where the top margin is set to something other than zero with a straight margin selector.

less/carousel.less:158:    margin: 1px;
less/dropdowns.less:41:  margin: 2px 0 0; // override default ul
less/forms.less:45:  margin: 4px 0 0;
less/mixins.less:387:  margin: ((@line-height-computed / 2) - 1) 0;
less/navbar.less:209:  margin: (@navbar-padding-vertical / 2) -@navbar-padding-horizontal;
less/pager.less:8:  margin: @line-height-computed 0;
less/pagination.less:7:  margin: @line-height-computed 0;
less/print.less:54:    margin: 2cm .5cm;
less/scaffolding.less:114:  margin: -1px;
less/type.less:129:  margin: (@line-height-computed * 2) 0 @line-height-computed;

@StevenBlack
Copy link
Contributor

A possibly reasonable take: We don't need to worry about, therefore don't need to change,

  • Tooltips
  • Popovers
  • Modals
  • Dropdowns

... since none of these participate in page layouts. But I could be wrong about that.

@juthilo
Copy link
Collaborator

juthilo commented Nov 24, 2013

From the top off my head:
While I wouldn't release a fix for this issue as a patch due to the broad scope if the issue (thanks @StevenBlack), I'd say this basically affects sites just like color changes or the like do.

I'd love to hear from the community though. What kind of overrides are in place out there and how much work would result from a fix for this issue (for example)?

All in all, personally, I like the two points/possible rules posted by @mdo.

@leeaston
Copy link

Similar idea over at Foundation:
foundation/foundation-sites#3565

@carasmo
Copy link

carasmo commented Nov 25, 2013

So far, doing only bottom margin on any p, ul (first level), ol (first level), h1-h6, .h1-.h6, tables, forms, hr works well. However having that 10px top margin on the h* tag makes a nice 30px vertical space between columns BUT that 10px causes trouble when putting columns side by side and having an image or just paragraph text in on column and a headline and something else in another column.

But it works "more better" than having a top margin. I am able to space things a lot better and also make adjustments because I know that the previous element had a bottom margin of a known amount. The only issue I can see is that 20 px is not enough as the last margin in certain situations. It's after the image that it shows the most.

Here's what I'm talking about:

http://jsbin.com/AzICaQes/1

It's not a big deal to me. I would not put a margin on the columns unless the last child has nothing on the bottom but that's a bitch of a complication.

Before:
screen shot 2013-11-25 at 1 07 52 pm

After:
screen shot 2013-11-25 at 1 07 38 pm

Before:
screen shot 2013-11-25 at 1 05 29 pm

@StevenBlack
Copy link
Contributor

Nice.

Here's what that looks like on baselines. This is with Web Developer Toolbar's "Outline Block Level Elements" turned on, and the grid is from Slammer, a good app for that.

@carasmo
Copy link

carasmo commented Nov 25, 2013

Here it is with just bottom margins. I didn't realize I was live editing the first one.

http://jsbin.com/AzICaQes/4

@carasmo
Copy link

carasmo commented Nov 25, 2013

This before (below) is only a margin bottom 2rem on all but the main title. The .well has a 2rem padding on all sides except bottom is 0. This 20px/2rem is my default margin bottom, but certain layouts need to be tighter.

before-2

Then after all I did was change all bottoms to 1.2 rem.

after-2

.news-style h1, 
.news-style h2, 
.news-style h3, 
.news-style h4, 
.news-style h5, 
.news-style h6, 
.news-style p, 
.news-style ul, 
.news-style ol, 
.news-style form, 
.news-style table,
.news-style .well 
.news-style hr {
    margin-bottom:1.2rem;
}
.news-style .well { 
  padding: 1.2rem 1.2rem 0 1.2rem; 
}
.news-style hr {
    margin-bottom:1.2rem;
}
.news-style p {
    font-size:14px;
    line-height:1.5;
}
.news-style .section-title {
    margin-bottom:3rem;
}

Oh, yeah, all my gutters are percentages so that's why it also looks this way. I have some mixins to make the rem and pixels at the same time, I'm still debating what to do, when ie8 goes bye-bye I will stick with rem only. There's also a polyfil that turns rem to pixels for ie8.

@mdo
Copy link
Member

mdo commented Nov 30, 2013

Punting til v4 since this would break backward compatibility. Definitely want to redo this for that release though.

@jmcbee
Copy link

jmcbee commented Oct 8, 2014

So.. what happened to this?

@cvrebert
Copy link
Collaborator

cvrebert commented Oct 8, 2014

As the last comment says, it's been deferred to v4.

Tangential X-Ref: foundation/foundation-sites#5653

@twbs twbs locked and limited conversation to collaborators Oct 8, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

8 participants