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
Make grid-column-gutter define responsive gutters by default #8259 #8693
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
4dd5d99
Add static grid gutters #8508
ncoden 948ddd5
Standardize grid gutters
ncoden cc14c08
Fix grid gutters
ncoden 085cabb
Fix grid gutters (2)
ncoden de3b357
Fix grid-column-row parameter in doc
ncoden 19bae9b
Make grid-column-gutter define responsive gutters by default #8259
ncoden File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... it took me a while to realize this was actually calling a function by the same name, rather than infinitely recursing through the mixin... hmm. I see looking at our codebase that this isn't that uncommon of a pattern, but it struck me as unintuitive at first glance. Is this a common scss practice? (cc @brettsmason @JeremyEnglert @andycochran @ncoden @zurbrandon @rafibomb). Alternatively, my inclination would be to have some sort of consistent scheme for naming functions that are connected to particular mixins, for example by prefixing with a '-' or something similar.
A quick look around at some existing scss styleguides doesn't seem to highlight function naming... interested in your thoughts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the
namespace-function-role-bar-baz
naming convention, we're limited, we can't explicitly differentiate the namespace from the function role.So we can make a little, easy and temporary change and rename it to :
But we can also expand our naming convention to
namespace_function-role-...
:At term, I hope we will switch all the components/functions/mixins names to a better naming convention, full-BEM:
namespace__element--modifier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So there's 2 aspects to this... there's having a consistent naming scheme in general, and there's the question of how to handle interconnected functions and mixins.
With regards to the first, I've heard arguments for and against BEM - generally it feels unnecessarily verbose to me, though I'd be open to arguments why that verbosity is helpful - but I think in most cases our naming conventions have at least been reasonably consistent when it comes to component structure and final class name.
On the second though, I'd personally like some sort of immediate visual cue as to what role the thing I'm looking at is... for example, in ruby modules and class names are CamelCase, constants are CAPITALIZED, and variables and method names are snake_case. In scss we have an immediate visual cue of something being a $variable, but no naming distinction between a @mixin (which must be @include'd in) and a @function which is called directly...
I'd like to propose we adopt some sort of convention that gives that immediate visual cue at least within foundation. I don't have a strong opinion on what it is...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't found scss naming convention for functions, variables and mixins when I was working on CaliOpen, so I used an adapted BEM :
Here an exemple : https://gist.github.com/ncoden/171b26636f052c41739aff3c26ab8357
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CSS is case-insensitive, so Sass repeated the
bugfeature. But sometimes I see code which break thealways-snipal-case
for aCamelCase
alternative version of BEM, because case errors never happen.Also, everything is declared in the global scope, so we have to almost always deal with a namespace. But maybe we can write something like
NameSpace_CONST
?To distribute the different cases to the differentes Sass things, we only have to deal between
@mixin
and@function
.@mixin
(and the.class
involved) is more a OO Class, so I would sayCamelCase
@function
(with$variable
, unless for const) takes the rest,snipal-case
orsnake_case
.I made the following exemple : https://gist.github.com/ncoden/a1cef157c7ebe236fe115cd6d2bd4a26
I don't like it, but I don't find better for now. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: When I say BEM, I talk about the global "Block Element Modifier" separation, not the official (and strict) getbem convention
BEM was not only created to help the developer knowing what he uses, but to prevent unwanted behaviours when using CSS classes : properties overwritten by specificity, naming collisions across components or frameworks... I remember having these problems with Foundation
Also, there is a lot of BEM grammars, some more verbose than others (i.e.
block-foo__element-bar--modifier-baz
,BlockFoo_ElementBar-ModifierBaz
, etc...). Generally, each developer using BEM has its own variante !You can also take a look at SMACSS (great explanation here). It's more complete than BEM, full of great advices !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very interesting. Curious what our more SCSS-focused yetinauts think @andycochran @brettsmason @JeremyEnglert @zurbrandon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I think that every element declared in the global namespace should be prefixed. Foundation variables, function and mixins should begin with
zf-
. We should do it also for CSS classes, but it could be a bit disturbing for the static Foundation users. We can purpose an optional prefix option (disabled by default), but it would create multiple standards.