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

Fixed vs Fluid #12

Open
Evanion opened this issue Jul 26, 2012 · 5 comments
Open

Fixed vs Fluid #12

Evanion opened this issue Jul 26, 2012 · 5 comments

Comments

@Evanion
Copy link

Evanion commented Jul 26, 2012

I'm guessing you haven't started on the responsive part of the less/fluid tree yet.
Regardless of the Fluid vs fixed question, I think it's important that the gridsystem used in this project should support both sass and less, in order to keep the respective branches as similar as possible.

Semantic.gs vs frameless/golden grid:
From a fluid standpoint, their more or less the same. But semantic uses pixels, and Golden uses em for non fluid elements... like height.

I feel em is a better choice, as it will make the design scale if the user changes the font size.
we can't really use % for height in a div etc, browsers tend to not like that... so that leaves us with px or em, px wont scale if the user changes the font size, but em does. giving the template a better way to adapt for visually impaired people.

I would vote for Frameless/golden due to em.

Could add both fixed and fluid to the markup, all that would be needed is a body tag class. It's more work, but would let people chose for them self what version they prefer, after all, if the design is originally fluid, it's only the wrappers and elements like sidebars that would need to be changed if someone wanted fixed width.

@markahesketh
Copy link
Owner

On the LESS branch I've not done anything with media queries yet, but its built on a fluid grid so you should see all the columns resize as you bring the browser width from widescreen to small screen.

I've not looked at rearranging the sidebars etc for mobile/tablet device screens and such just yet, not got around to that yet.

Regarding the em heights etc, I'm not sure Semantic GS does anything to do with height. But then I guess this doesnt require a grid? Elements requiring a height can be set with em regardless of the grid I guess? Everything, even with its a fixed-width layout uses % for it's sizes such as margins and widths.

Am I missing something or would the element not scale with a font-size because its content has become bigger? I try to always use ems on text/heading margins and padding for this reason, as well as line-height of course.

Agreed on both LESS and SASS to be included, people have their preferences and its common for both to be included.

@markahesketh
Copy link
Owner

Just a quick note... you'll see what I mean in the LESS branch with things like the homepage slideshow resizing fluidly as you resize, I think its a nice addition.

The slideshow script used shows the navigation arrows on hover, until you get to touch screen device widths where they display fully. Quite like that.

@Evanion
Copy link
Author

Evanion commented Jul 26, 2012

EMs is a semi fluid value, as the textsize increases, so does the size of the em, that way paddings, margins etc will always be relational to the fontsize. a 5px padding will always stay 5px high, and can make it look strange if the text gets too big. I have been thinking of adding a fontsize switcher in the template.

@markahesketh
Copy link
Owner

I've been using this mixin in LESS:

// -|- Relative EM font sizing - http://bit.ly/NwjdmM ---------------
.font-size(@sizeValue){
    @remValue: (@sizeValue / 10);
    @pxValue: @sizeValue;
    font-size: ~"@{pxValue}px"; 
    font-size: ~"@{remValue}rem";
}

So setting .font-size(16) will create the right rem value for the font, which is relative to the root rather than parent like em. There's good browser support for it, and IE7/8 will fallback to the px value instead.

@Evanion
Copy link
Author

Evanion commented Jul 26, 2012

ok
I will do some testing with golden, and see how it compares.
But I have some ideas that I think will do well in a boilerplate.

I have been thinking ov fluid vs fixed over the night, and I think that fluid is a better startingpoint, as I said before, we can always add fixed markup to the wrappers, and have them be activated by a body class.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants