kittygiraudel / sass-boilerplate Goto Github PK

I know I already suggested a change on the name of this folder and, exactly because of that, why not name it others?

;-)

Hi!

I'm putting my mess in order using this boilerplate and found a issue.

Shouldn't the functions file came before the variables one? We can use functions to modify variables and functions don't run until being called somewhere.

Example:

$_color-base-grey: rgb(229, 231, 234);

$_palettes: (
    'purple': (
        'base': rgb(42, 40, 80),
        'light': rgb(51, 46, 140),
        'dark': rgb(40, 38, 65)
    ),
    'grey':  (
        'base': $_color-base-grey,
        'light': tint($_color-base-grey, 10%),
        'dark': shade($_color-base-grey, 10%)
    )
);

Thank for your help!

The current version is actually just inlcuded normalize.css.

@JohnAlbin is truly sass, offer some control on final output and is based on currently included @necolas normalize.css

Hey Hugo, nice boilerplate, learned some things from it — thanks for sharing!

I just had a question about your when-inside mixin. What's the use case for this? What makes it preferable to just writing #context & { ... }?

https://github.com/HugoGiraudel/sass-boilerplate/blob/master/stylesheets/utils/_mixins.scss#L29-L33

The above code will throw a warning (nesting should not be greater than 1) from sass lint:

.example {
  top: 43px;
  &__section { // <-- this line
    width: 100%;
  }
}

I'll not pull request it, because I can't find the reason it isn't working on my test.

The .scss-lint.yml should have this on its first line:

exclude: 'stylesheets/vendor/*.*'

I'm testing on Sublime Text, but no luck yet... I gonna try more.

I hope that the code is public domain. It would be nice if this is explicitly stated in README.

Hello @hugogiraudel .
I really liked the 7-1 pattern.
I was wondering if it's a good thought to used it only with Vanilla CSS.

Thank you.

I am reading in your documentation 'vendors' all the time.
Is there any reason to have it in singular?

in main.scss file line 5: vendors/normalize
the vendors folder is vendor not vendors!

Hi, how to use $breakpoint , i tried these both it seem didnt work? Thanks

is it

@include media("small") { .box { width: 350px; } }

or

.box { width: 500px; @include media("small") { width: 350px; } }

Even though your documentation says macro first wouldn't it help with defining the micro and building up from that?

Hi,
I have a question about the eighth folder, called vendor extension.
Now, In my project I have two vendor files, magnific popup (a simple Jquery popup plugin) and balloon.css (a tooltip library).
For both of them I have a very few custom styles,

for example this is the extended styles for the tooltip library:

/*-------------------------------------
  Magnific Popup Video Animation
-------------------------------------*/

/* Overlay */
.mfp-bg {
  opacity: 0;
  transition: opacity trs(sm);

  &.mfp-ready {
    opacity: .6;
  }

  &.mfp-removing {
    opacity: 0;
  }
}

/* Content*/
.mfp-content {
  opacity: 0;
  transition: opacity trs(md);

  .mfp-ready & {
    opacity: 1;
  }

  .mfp-removing & {
    opacity: 0;
  }
}

And this styles for the popup:

/*-------------------------------------
  Extend Tooltip Css
-------------------------------------*/

.tooltip {
  --balloon-font-size: 1.3rem;

  &::after {
    padding: .75rem 1.3rem !important;
  }
}

/* attach the arrow (::before) to the body (::after) */
[data-balloon-pos="right"]::before {
  transform: translate(.1rem, -50%) !important;
}

[data-balloon-pos="down"]::before {
  transform: translate(-50%, .1rem) !important;
}

.tooltip--error {
--balloon-color: #{color(red)};
}

Like you see, not a big amount of CSS.

Currently I have this styles in my _base.scss file (at the bottom of it) and I don't know if is very needed a eighth folder, with a file for each vendor. I thought that maybe I can create only one file called "_extend-vendors.scss" for collect all of them and put it in base folder.

What do you think about the problem?

Hi, @hugogiraudel! Thanks for awesome the boilerplate.

When I use webpack I importing any vendor library like as:

// 2. Vendors
@import
'~normalize.css',
'~bootstrap/scss/bootstrap-grid.scss';

Maybe Do you need rewrite recommendation how work with vendor libraries when using webpack or similar tool?

Hi there! I'm struggling to understand something, please let me know if I'm missing some point. Thank you!

Naturally, many of our macro components (which are located in the "layout" folder) are composed of (i.e. contain) some micro components (modules).

For example, a header (macro) has a search box that is actually a textbox module (micro). Pretty straight-forward so far.

I'm also following the BEM methodology, so this relationship would look something like this;

• We have a block named .textbox (=> components/_textbox.scss)
• Then in our header block (=> layout/_header.scss), we have an element (and by element I mean a BEM element) named .header__search-box. As you know this is called a "mix" in BEM, and is perfectly valid and common.

Now, the header-search-box element might need to override some of the default declarations on the .textbox block.

This means that layout/_header.scss has to be imported after components/_textbox.scss in order for its declarations to take precedence, obviously. But I noticed that the 7-1 architecture states the following:

Files should be imported according to the folder they live in, one after the other in the following order:

abstracts/
vendors/
base/
layout/
components/
pages/
themes/

Components should be imported AFTER layouts. This doesn't make a lot of sense to me. And it would actually be problematic in cases like the one I just described. I wanted to know what the specific rationale behind this particular order is, and whether you think the case I'm presenting is reasonable or not.

What I'm saying in a nutshell is: Macro components are composed of micro components. In many cases, micro components would need to change style depending on the context they're used (meaning within which macro component), this is achieved in BEM with mixes, but it would only work if macro component styles are located AFTER the micro component styles in the final stylesheet. But the 7-1 architecture recommended order of importing files doesn't allow this.

Thanks in advance.

Like:

To build that boilerplate with `node-sass` installed globally do following:

- install `node-sass` if not yet installed:
``bash
npm install -g node-sass
``
- run build command from command line:
``bash
node-sass stylesheets/main.scss dist/main.css 
``

Thanks!

Hi, 👋

What is the reason behind the "layout" naming. Why it is not "layouts"?

Thank you 🍨

Hi!

From what I understand all of the sass is compiled into a single CSS.
What would be a good approach if I use it with asp MVC app, where I bundle the CSS files that are only used for that specific view, should I have more files aside from "main.scss" ?

SASS/SCSS are discouraging and phasing out support for @import rule in favor of the @use rule.

This makes styling more readable, safer and reduces compile time.

For more detail see '⚠Heads Up!' notice in the documentation here.

Read @use rule docs here.

Would it be worth updating main.scss in response to this?

This is what it (Gulp) throws

Error in plugin 'sass'
Message:
    src\sass\main.scss
Error: File to import not found or unreadable: abstracts/variables.
       Parent style sheet: C:/Users/Selrond/Desktop/Code/100DaysOfCode/003/src/sass/main.scss
        on line 4 of src/sass/main.scss
>> @import
   ^

It looks as if the second way of importing the partials fails to compile on gulp-sass?

Hi (again/yet)!

Shouldn't the vendor folder be the first one to be imported? We can put a lot of things inside it, not only css. Let's say I want to include Sass Blend Modes. They're functions, which I could use to modify my own variables and functions. I need them loaded before my config files.

Thank you (again/yet), Hugo!

There are fonts, helpers and typography in basefolder and those three are not included in mainor anywhere in boilerplate.

If it is intentional then it should be noted in README.md.

Or is it just an oversight?

I saw this in Omega 4.x theme for Drupal and adopted myself as those are abstracts — not generating anything on their own.

Would it make sense using 'index.scss' according to sass-eyeglass module spec
as main/"entry" file for the project instead main.scss?

Hi, @hugogiraudel.

Have you ever thought about a folder for tests?

Where should i place common simple responsive rules?
My opinion is 3. 'base/responsive';