Menu icon Foundation

My Posts


My Comments

Kevin Lozandier commented on Vinay Raghu's post over 5 years

The best option I could think of is deliberately not including the _grid.scss file and relying on the +grid-column mixin & Foundation's SCSS media-query variables instead.

If for some reason those items are also inside grid.scss, you'd have to extract them and the dependent variables involved. That shouldn't be a problem since Zurb's developers have done a good job putting all the variables inside _settings.sass for the most part.

Zurb likely can make these things separate from the rest of the grid.scss file, if they're in there, from the rest of that file generating the CSS related to the grid you don't want.

If enough people request it, I'm sure it'll be done soon (if not in the works already).

I mentioned this feature/improvement before and other meta-programming features involving Sass 3.3 last summer actually; now that Sass 3.3 is officially released and Foundation 5 being in a mature state, I hope this in particular is being considered.

Kevin Lozandier commented on Vinay Raghu's post over 5 years

It's not a good idea to use @extend in such a fashion.

You'll quickly have very unwieldy, unnecessarily long style declarations with your current use of @extend .

Personally, I have sort of a three-strikes-and-you're-out rule with @extend: If I find myself associating more than 3 CSS declarations to a single @extend, I refactor it to be a mixin to be kind to my future self.

Foundation Zurb already comes with a mixin that'll allow you to have the result you're looking for via the +grid-column() mixin

In fact, it's far less code using it than what you've provided above.

That's one of the key benefits of using the Sass version of Foundation you're currently not taking in consideration:

You don't have to restrict yourself to the "small", "medium", and "large" prebuilt breakpoints Foundation comes out of the box with for primarily the CSS version for the sake of a proper starting point for rapid prototyping with just classes.

Combined with media queries that come into fruition as you think about what sizes causes your vision of the site layout to break down (or using Sass extensions like breakpoint, a Sass extension dedicated to breakpoints and media queries, to help with this), the built-in mixins provided to you by the thoughtful folks at Zurb allows you to the freedom you want from the large-x, medium-x, and small-x classes already.

I've had to address this earlier this week actually through a SassMeister gist.

Going the next level towards the semantic grid system you're hoping to build for your project

After the rapid prototyping phase of your project, you may see that your page types are in very distinct blocks that warrants using a more simple or more robust grid behind the scenes: For example, you know you need at most 4 columns for a specific view port range or have a 2-8-2 ratio relationship between your sidebars and your main content.

In situations like that, you may want to use a dedicated grid framework like Singularitygs or Suzy.

Your mileage may vary; for example it may be optimizing too early or forcing relationships that just aren't there yet if you use such grid frameworks immediately in a project.

Being frameworks dedicated to grids, your rapid prototyping time is likely to increase and you may later find that it was overkill to take such a route (i.e., you find that just a 12-column grid will do you just fine) in the first place.

Kevin Lozandier commented on Gareth Edwards's post over 5 years

Howdy, fellow Zurbian:

I noticed you said you're using the Sass version of Sass.

Well, allow me to show you awesomeness of using the Sass version of Foundation to accomplish what you're accomplishing.

The completed result can be found here if you're pressed for time or have a hard time following what I have to say below: http://sassmeister.com/gist/9476796

Assumptions

I'll assume you're doing this mobile-first since Foundation is--you know--a mobile-first CSS system.

I'm assuming you identified the major breakpoints of your design that'll break it--and it coincidently was two or three for you to solve your problem the way you're doing it now--using Foundation's "large", "medium", and "small" major breakpoints and the associated helper classes and functions associated with them .

Alternatively, I'm assuming you're just rapid prototyping and find the "large", "medium", and "small" built-in helpers handy.

Otherwise, like what James Stone said, you're not maximizing the power of the Sass version of Foundation. Allow me to help you with that.

Anyhow, let's get your problem solved:

Step 1: Eliminate the classes you have and just use 1 for each distinct block of content

Since you're using the Sass version of Foundation, you're better off making most of the built-in Sass mixins Foundation has built-in to have less classes to worry about in your html files.

.html
<div class="rowColumn">
<div class="box1"></div>
<div class="box2"></div>
</div>

For the sake of simplicity, I'll just use divs and use .rowColumn, .box1, & .box2 to refer to the row and two boxes you want styled; .box1 will be the box you want hidden initially, and .box2 will be the box that you want to offset in large screen sizes.

Step 2: "Small screen" styles

Since you're starting off mobile-first and you want .box1 to be initially hidden, you can use display:none to make it hidden and have its space occupied by .box2 as a result.

No need for classes yet.

Like any ordinary block element, .box2 by default occupies the entire width of its container, there's little modification it needs unless you want to use @include grid-column here for the box to inherit the padding and other characteristics Foundation applies to styles using its grid classes.

Step 3: "Large screen" styles.

Since you want .box1 to occupy 2 columns based on your requirements, you can use Foundation's @include grid-column mixin and set the number of columns via the $columns variable to 2.

With .box2, in order to be in the same row as .box1 can only span 9 columns if you want the box to take up 10 columns but also have an offset of 1 column.

This is easily achieved with the @include grid-column():

@include grid-column($columns: 9, $offset: 1) 

To fit within the conventions of Foundation's "small", "medium", and "large", and you want to leverage that in Sass, you can use Foundation's pre-built media query strings used to create the small-x, medium-x, and large-x classes":

@media #{$small-only}, @media #{$medium-only}, @media #{$medium-only} classes respectfully.

There's -up variants of these sizes, like #{$medium-up}} are essentially min-width calls compared to the versions above I just described; for more information about these media queries , check out the documentation for the Sass variables associated with the size thresholds of Foundation:

Again, refer to the final result if none of this made any sense to you:

Kevin Lozandier commented on Rafi Benkual's post over 5 years

Any particular reason why SassMeister (http://sassmeister.com/) can't be used (especially for Sass 3.3 lovers such as myself )?

Kevin Lozandier commented on Kevin Lozandier's post over 5 years

Thanks, Brandon, it's certainly not a 'major' issue as far as Foundation's core functionality as a badass rapid prototyping framework, but I hope it gets addressed when resources aren't stretched too thin; perhaps I'll spend some time it with a "Florian's solution" one of these days. :)

AFAIK, based on recent versions of the spec, and the seminal article about the semantic use of buttons (and other things) by Heydon Pickerings (http://coding.smashingmagazine.com/2013/08/20/semantic-css-with-intelligent-selectors/), I think the use cases of outside of forms is valid.

On another note (Karl)

Karl, I can relate to your pain when it comes to the use of the button element on things without a href attribute, Heydon Pickerings and modern HTML5 books since the last update to the specification has set me straight to always question my use of anchor tags instead of the button element for many use cases.

It is why it now irks me when an anchor tag is deliberately being used as a button,and solely styled to be a button, via a class throughout Foundation 5.

Posts Followed

No Content

Following

    No Content

Followers

My Posts

My Comments

You commented on Vinay Raghu's post over 5 years

The best option I could think of is deliberately not including the _grid.scss file and relying on the +grid-column mixin & Foundation's SCSS media-query variables instead.

If for some reason those items are also inside grid.scss, you'd have to extract them and the dependent variables involved. That shouldn't be a problem since Zurb's developers have done a good job putting all the variables inside _settings.sass for the most part.

Zurb likely can make these things separate from the rest of the grid.scss file, if they're in there, from the rest of that file generating the CSS related to the grid you don't want.

If enough people request it, I'm sure it'll be done soon (if not in the works already).

I mentioned this feature/improvement before and other meta-programming features involving Sass 3.3 last summer actually; now that Sass 3.3 is officially released and Foundation 5 being in a mature state, I hope this in particular is being considered.

You commented on Vinay Raghu's post over 5 years

It's not a good idea to use @extend in such a fashion.

You'll quickly have very unwieldy, unnecessarily long style declarations with your current use of @extend .

Personally, I have sort of a three-strikes-and-you're-out rule with @extend: If I find myself associating more than 3 CSS declarations to a single @extend, I refactor it to be a mixin to be kind to my future self.

Foundation Zurb already comes with a mixin that'll allow you to have the result you're looking for via the +grid-column() mixin

In fact, it's far less code using it than what you've provided above.

That's one of the key benefits of using the Sass version of Foundation you're currently not taking in consideration:

You don't have to restrict yourself to the "small", "medium", and "large" prebuilt breakpoints Foundation comes out of the box with for primarily the CSS version for the sake of a proper starting point for rapid prototyping with just classes.

Combined with media queries that come into fruition as you think about what sizes causes your vision of the site layout to break down (or using Sass extensions like breakpoint, a Sass extension dedicated to breakpoints and media queries, to help with this), the built-in mixins provided to you by the thoughtful folks at Zurb allows you to the freedom you want from the large-x, medium-x, and small-x classes already.

I've had to address this earlier this week actually through a SassMeister gist.

Going the next level towards the semantic grid system you're hoping to build for your project

After the rapid prototyping phase of your project, you may see that your page types are in very distinct blocks that warrants using a more simple or more robust grid behind the scenes: For example, you know you need at most 4 columns for a specific view port range or have a 2-8-2 ratio relationship between your sidebars and your main content.

In situations like that, you may want to use a dedicated grid framework like Singularitygs or Suzy.

Your mileage may vary; for example it may be optimizing too early or forcing relationships that just aren't there yet if you use such grid frameworks immediately in a project.

Being frameworks dedicated to grids, your rapid prototyping time is likely to increase and you may later find that it was overkill to take such a route (i.e., you find that just a 12-column grid will do you just fine) in the first place.

You commented on Gareth Edwards's post over 5 years

Howdy, fellow Zurbian:

I noticed you said you're using the Sass version of Sass.

Well, allow me to show you awesomeness of using the Sass version of Foundation to accomplish what you're accomplishing.

The completed result can be found here if you're pressed for time or have a hard time following what I have to say below: http://sassmeister.com/gist/9476796

Assumptions

I'll assume you're doing this mobile-first since Foundation is--you know--a mobile-first CSS system.

I'm assuming you identified the major breakpoints of your design that'll break it--and it coincidently was two or three for you to solve your problem the way you're doing it now--using Foundation's "large", "medium", and "small" major breakpoints and the associated helper classes and functions associated with them .

Alternatively, I'm assuming you're just rapid prototyping and find the "large", "medium", and "small" built-in helpers handy.

Otherwise, like what James Stone said, you're not maximizing the power of the Sass version of Foundation. Allow me to help you with that.

Anyhow, let's get your problem solved:

Step 1: Eliminate the classes you have and just use 1 for each distinct block of content

Since you're using the Sass version of Foundation, you're better off making most of the built-in Sass mixins Foundation has built-in to have less classes to worry about in your html files.

.html
<div class="rowColumn">
<div class="box1"></div>
<div class="box2"></div>
</div>

For the sake of simplicity, I'll just use divs and use .rowColumn, .box1, & .box2 to refer to the row and two boxes you want styled; .box1 will be the box you want hidden initially, and .box2 will be the box that you want to offset in large screen sizes.

Step 2: "Small screen" styles

Since you're starting off mobile-first and you want .box1 to be initially hidden, you can use display:none to make it hidden and have its space occupied by .box2 as a result.

No need for classes yet.

Like any ordinary block element, .box2 by default occupies the entire width of its container, there's little modification it needs unless you want to use @include grid-column here for the box to inherit the padding and other characteristics Foundation applies to styles using its grid classes.

Step 3: "Large screen" styles.

Since you want .box1 to occupy 2 columns based on your requirements, you can use Foundation's @include grid-column mixin and set the number of columns via the $columns variable to 2.

With .box2, in order to be in the same row as .box1 can only span 9 columns if you want the box to take up 10 columns but also have an offset of 1 column.

This is easily achieved with the @include grid-column():

@include grid-column($columns: 9, $offset: 1) 

To fit within the conventions of Foundation's "small", "medium", and "large", and you want to leverage that in Sass, you can use Foundation's pre-built media query strings used to create the small-x, medium-x, and large-x classes":

@media #{$small-only}, @media #{$medium-only}, @media #{$medium-only} classes respectfully.

There's -up variants of these sizes, like #{$medium-up}} are essentially min-width calls compared to the versions above I just described; for more information about these media queries , check out the documentation for the Sass variables associated with the size thresholds of Foundation:

Again, refer to the final result if none of this made any sense to you:

You commented on Rafi Benkual's post over 5 years

Any particular reason why SassMeister (http://sassmeister.com/) can't be used (especially for Sass 3.3 lovers such as myself )?

You commented on Kevin Lozandier's post over 5 years

Thanks, Brandon, it's certainly not a 'major' issue as far as Foundation's core functionality as a badass rapid prototyping framework, but I hope it gets addressed when resources aren't stretched too thin; perhaps I'll spend some time it with a "Florian's solution" one of these days. :)

AFAIK, based on recent versions of the spec, and the seminal article about the semantic use of buttons (and other things) by Heydon Pickerings (http://coding.smashingmagazine.com/2013/08/20/semantic-css-with-intelligent-selectors/), I think the use cases of outside of forms is valid.

On another note (Karl)

Karl, I can relate to your pain when it comes to the use of the button element on things without a href attribute, Heydon Pickerings and modern HTML5 books since the last update to the specification has set me straight to always question my use of anchor tags instead of the button element for many use cases.

It is why it now irks me when an anchor tag is deliberately being used as a button,and solely styled to be a button, via a class throughout Foundation 5.

Posts Followed

No Content

Following

  • No Content

Followers

  • No Content