geddski / csstyle Goto Github PK

Hi, csstyle is great work!
and I would like to use this in my project
and I have a question.

I totally agree with this library's component writing style. but where should I write "layout" css ?
such as position and top left and so on.

thanks.

It seems to have a problem in your library with my current version of Sass

``07 May 12:51:08 - error: Compiling of app/stylesheets/main.sass failed. DEPRECATION WARNING on line 50 of /Users/Loschcode/Google Drive/projects/panda-lo/website/app_front/node_modules/csstyle/csstyle.scss: #{} interpolation near operators will be simplified
in a future version of Sass. To preserve the current behavior, use quotes:

unquote("#{&}")```

Please allow user-defined delimiters. For example I use a variation on BEM naming proposed by Nicholas Gallagher here.

This means that component names are Pascal-case, subcomponent names are camel-case and all components are separated with a single - rather than a __. Being able to configure the delimiters you use would make this lib much more flexible. Simple namespaced variables would be great:

$cssstyle-component-delimeter: '__' !default;

Hi, When I'm using this the sourcemap points to the_ csstyle.scss file :(

And as Myth is based on Rework it could be supported as well (hopefully).

Great project! I'm using it for a new site right now.

Wondering what your prescribed approach is for handling pseudo class (states) for component parts:

@include component(figure) {
  ...
  @include part(caption) {
    ...
    opacity: 0;
  }

  &:hover .figure__caption {
    opacity: 1;
  }
}

That's the only way I can figure out to do it, but seems counter-productive.

Thanks!

csstyle, at least when used as a component of postcss, causes a space character to be appended to all selectors.

body {
  color: red;
}

becomes

 body {
  color: red;
}

This is not an actual issue, but I didn't find a place to discuss this.

Let's say I have a header component, and I'm using options to set the background image depending on the page. I also want to use a small or large version of the background image depending on the viewport resolution.

Option A

@include component(header) {
    // some styling

    @media all and (min-width: 320px) {
        @include option(contact){
            // set background image
        }
        @include option(about){
            // set background image
        }
    }
    @media all and (min-width: 768px) {
        @include option(contact){
            // set background image
        }
        @include option(about){
            // set background image
        }
    }
}

Option B

@include component(header) {
    // some styling

    @include option(contact){
        @media all and (min-width: 320px) {
            // set background image
        }
        @media all and (min-width: 768px) {
            // set background image
        }
    }

    @include option(about){
        @media all and (min-width: 320px) {
            // set background image
        }
        @media all and (min-width: 768px) {
            // set background image
        }
    }
}

Is there any difference at all?

Hi,

seems all external links on the preview site are dead, console messages:

Refused to display 'https://github.com/geddski/csstyle#getting-started' in a frame because it set 'X-Frame-Options' to 'deny'.

Hi guys :)

I use csstyle since the first release (If I remember well). I wanted to know if someone did a framework a la bootstrap with csstyle in mind ?

Some basic components, buttons, panel, navbar, etc ...

It can be awesome, with csstyle you can "extend" a component and add new properties, in bootstrap right now it's always a bit "hacky".

Kind regards,

Jérémie

I found that your naming convension is more clean than BEM one. So it should be very nice to introduce it to others too.

Please, add Yeoman Generator http://yeoman.io/generators/ for csstyle with the basic scafolding and structs, this will help to bump csstyle approach

Consider:

@include component (module) {
    @include option(big) {
        @include part(part) {
            color: red;
        }
    }
}

With node-sass 3.3.3 the output (as I would expect) is:

.module.\--big .module__part {
  color: red; }

With node-sass 3.4.1 the output is:

.module.\--big__part {
  color: red; }

Is this a bug or an expected change? If the latter, how would I achieve the output of the first example?

We use less at work and are getting ready to make an overhaul of our styles. With support for less, we may adopt the csstyle methodology.

• Remove and gitignore sass cache
• Put site into it's own repo (cssstyle-www)

After some great feedback from Paul Irish and a lot of brainstorming, I think we could probably remove locations entirely. Locations' purpose are to allow consumers of a component to override aspects of the component when it's being used in a certain context. It's a common use case and csstyle needs to support it. Locations have a couple of problems however:

1. Because they use id they automatically override every part of component, including its options. So if you wanted to override the base style of a component using a location but leave it alone when it's using an option, you're out of luck.
2. People start using locations in places where they really should be using a component.
3. There are a lot of semantics to remember with components, parts, options, tweaks, & locations.

I think components themselves provide enough context:

@include component(sidebar){
  @include component(button){
    // override some aspect of button when inside sidebar
  }
}

And they do this with a single class name rather than an id. The only problem with this is that options and parts also only add a single class name. This would lead to load-order importance which is something csstyle is supposed to handle for you. One option would be to have csstyle add another class onto the parts & options selectors that get generated so that they are automatically more specific than the base styles applied to a component inside of another component.

I'm open to ideas and feedback before making a breaking change like this.

I wanted to share with you the sass structure i'm using with csstyle. I wanted some feedbacks about the "idea".

I work always like that:

1 - I do the html layout of the page with a grid system like bootstrap grid.
2 - I create my base components under the components folder and I include them in the html layout. (When I start a new project I have always my default components from previous projects, it's a good foundation ^^')
3 - After that I put in the html the contexts. For example in the screenshot I have a contexts/home/_footer.sass which means I will style the component footer in the home page. I use the @include location(home_footer) system for that.

Like that I still "atomic". I don't put the mess in my base components with 22 options, I just use the convention to render a component following a context.

What do you think guys ?

For my job, i'm creating some base components (button, well, form, etc ...) to have a fresh UI when I start a new project.

For sure I will edit some components to match with the current design of the application I will build.

So I wanted to know how to extend a component (clean way).

// button.sass
@include component(button)
  // ....

// app.sass

// Here I want to "hook", "extends" the component and add new classes
@ ????????

// I didn't try that but maybe it works ?
@include component(button)
  // My hooks here.

I would be happy to implement and test. Just want to make sure this is something you'd accept if a PR came in.

Hello,
Any chance in implementing a feature to check for duplicate components.
This would help us avoid overriding existing components.

Cheers

So github will recommend people look at the contributing guidelines when posting an issue... Also, the contributing guidelines in the readme isn't complete.

can't get to http://csstyle.io

I'd like to create a grid component like this:

<div class="grid --v --h">...</div>

--v stands for "vertical" and --h stands for "horizontal".

Here is how a vertical grid (<div class="grid --v"></div>) might look like: http://jsfiddle.net/5jpLdwx4/

But, adding the --h option causing the CSS to be overridden:

.grid.\--h {
  background-color: rgba(0, 0, 255, 0.2);
  background-image: linear-gradient(to bottom, rgba(0, 0, 0, 0.3) 0%, transparent 10%, transparent 100%);
  background-size: 20px 100%;
}
.grid.\--v {
  background-color: rgba(255, 0, 0, 0.2);
  background-image: linear-gradient(to bottom, rgba(0, 0, 0, 0.3) 0%, transparent 10%, transparent 100%);
  background-size: 100% 9px;
}

So, the vertical grid is overriding the horizontal one.

Is there a way to implement both --h and --v with a single element?

What a reason yo use this CSStyle? Such elements as component, tweak, location are only classes. It will not speed up work.

"Projects occasionally need to override styles in specific locations e.g. just on the home page or just in the chat feature. Locations are applied using an @ sign followed by the location name."

Rly? Why not use a normal parent div with class? The effect will be the same. Do I not understand something?

Please add CSSStyle to bower. This would be very useful for obvious reasons, but would also allow CSSStyle to be added to Sassmeister which is a great way to get people playing with it quickly.

[Edit] Looks like there is already a PR adding a bower.json.

Would you accept a Pull-Request for a config switch to support http://cssguidelin.es/ ?

$csstyle-support-guidelines: true;
@import 'csstyle';

Then the options can be used like

<div class="component component--option">

instead of

<div class="component --option">

as the headline says, we should have both .scss and .sass file

That would be consistent with the CLI type approach. Thoughts?

This example work fine:

@include component(foo) {
    & {
        @include part(bar) {
            // something
        }
    }
}

.foo__bar {
    padding: 1em;
}

This produces a wrong output:

@include component(foo) {
    &:last-child {
        @include part(bar) {
            // something
        }
    }
}

/* Expected */
.foo:last-child .foo__bar {
    padding: 1em;
}

/* Given */
.foo:last-child__bar {
    padding: 1em;
}

Using :not pseudo-element will produce an error:

@include component(foo) {
    &:not(:first-child) {
        @include part(bar) {
            // something
        }
    }
}

The thrown error is invalid selector after )

Given this markup

<div class="main">
    <div class="module --title-at-right">
        <div class="module__title">...</div>
    </div>
</div>

And that SCSS

@include component(main) {
    @include component(module) {

        // standard title stay at the left
        @include part(title) {
            float: left;
        }

        // if module has the --title-at-right option,
        // the title should stay at the right
        @include option(title-at-right) {
            @include part(title) {
                float: right;
            }
        }
    }
]

This compiled CSS outputs

.main .module_title {
    float: left;
}

.main .module.\--title-at-right .main .module__title {
    float: right;
}

But .main should not be nested under the .module component. The right result should be:

.main .module_title {
    float: left;
}

.main .module.\--title-at-right .module__title {
    float: right;
}

Nesting a part under a option should print only the first grade parent component, and not all hierarchy.

CSS and HTML are not my work, but is it valid to have @, +, -- in class names?

The syntax of class names is overcomplicated - there are too many symbols: --, __, +, @. This is definitely not KISS.

Hi :)

I'm really excited about your project and i think your concept is awesome (I imagined something like this 1 week ago after a huge customer project).

Right now I use bootstrap or skeleton for grids and a plenty of third packages for javascript (slideshow, etc ...) and I have a question :

• If I start to use this concept for my next project, I can forget bootstrap for grids and minimal UI because definitely it's not the same concept in mind. Imagine the mess into my HTML code. Btw I can use a grid on demand with Sass like Susy but ... what will happen for javascript plugins ? They use a lot of css code to run and i want keep a clean HTML, I don't want mix two concepts of CSS if you know what I mean.

So, right now i'm fucking excited but I dunno how to start ... I hate you :p !

Hey guys, it's me again ...

I'm finishing a big project and i used bootstrap for the grid system and csstyle for all components. I'm trying to find the best way to do the responsive design.

We can take that example :

@include component(upload)

  background-color: #f5f5f5
  min-height: 15em
  border-radius: 6px
  border: 1px solid #f5f5f5
  padding: 2em

  @include part(entry)
    display: inline-block
    float: left

  @include part(cover)
    text-align: center

Imagine i need to change the part "entry", i can imagine that way :

@include component(upload)

  background-color: #f5f5f5
  min-height: 15em
  border-radius: 6px
  border: 1px solid #f5f5f5
  padding: 2em

  @include part(entry)
    display: inline-block
    float: left
    @media(max-width: 400px)
      display: block

    @media(max-width: 700px)
      // Other things

  @include part(cover)
    text-align: center

But i think it will become the mess for the 20 components i have in the project.

Hey,

a Stylus version would be cool. It shouldn't be soo hard to convert, or?

I see csstyle plan to support rework #13 but dont start to work in it because rework not support nested styles.

I suggest to start with support for postcss that has support for nested styles with a plugin and it has the same features (and more) that rework.

What do you think?

Foundation 5.4.6 axed support for SASS 3.4.5 for various reasons. My compilers can only run this framework with SASS 3.2, 3.3 if I use an unofficial tweak.

I love the concept of your tool, but need to have previous version access until fix.

Is there a way I can @import your files and compile using SASS 3.2 (prepros 4.0), or is all of your new features in csstyle.scss use SASS 4.0 compiling?

Hope this makes sense.

I'm using gulp-sass, which relies upon node-sass, which relies upon libsass, which is currently around sass level ~3.2: sass/libsass#282

I can get around it by switching from gulp-sass to gulp-ruby-sass, which uses the ruby version of sass instead of libsass, but it's much slower than libsass; e.g., a 400ms scss compile becomes 5600ms, which becomes painful enough that it discourages me from using csstyle.

One cool thing would be to be able to autodoc all components. This doc would show every component and option available along with html samples and the results. Since you already define components with functions it would remove a lot of boilerplate from https://github.com/kneath/kss. WDYT?

Add support for CSStyle using Stylus

This will have some benefits. The most notable benefit is that Stylus leaves custom @rules as-is when it compiles down to CSS (so, @component { } in file.styl will be @component { } in file.css. That means that the Stylus CSStyle plugin can simply hook into Stylus, listen for it's end event, grab the processed css, pass it to PostCSS which will run it through CSStyle and finally pass it back to Stylus, and hey presto, a working Stylus plugin! :)

module.exports = function(opts) {
  opts = opts || {};
  var settings = _.defaults({
    // csstyle prefix settings
  }, opts);

  return function(style){
    style = this || style;
    var filename = style.options.filename;

    style.on('end', function(err, css){
      // ... handle error

      // configure the options to be passed to csstyle
      process_opts = {
        from: filename,
        to: path.join(
          path.dirname(filename),
          path.basename(filename, path.extname(filename))
        ) + '.css'
      }

      // if there is a stylus sourcemap, ensure postcss also generates one
      if (style.sourcemap) {
        process_opts.map = { annotation: false }
      }

      // run csstyle
      var res = postcss(opts).use(nested).use(csstyle(settings).process(css, process_opts);

      // if sourcemaps are generated, combine the two
      if (res.map && style.sourcemap) {
        var combined_map = map.transfer({
          fromSourceMap: res.map.toString(),
          toSourceMap: style.sourcemap
        });

        // then set the combined result as the new sourcemap
        style.sourcemap = JSON.parse(combined_map);
      }

      // return the css output
      return res.css;
    });

  }

}

The second benefit is that postcss-nested supports custom @rules bubbling:

By default, plugin will unwrap only @media, @support and @document
at-rules. You can add your custom at-rules to this list by bubble option:

postcss([ require('postcss-nested')({ bubble: ['phone'] }) ]

Which will help clean up a lot of the PostCSS code in CSStyle.

If only Sass and Less also allowed custom @rules and left them as-is - then no one would have to write 3 different versions of their plugin ^_^

Also, I did read something (trying to find it, will update this when I do) about PostCSS plugins eventually being able to detect the use of plugins previously in the chain, so you could refactor CSStyle to be a plugin pack consisting of:

• postcss-simple-nested - the function of this is obvious.
• postcss-csstyle-transformer - this handles transforming at-rules to selectors.

Then, if nested is not found, you could simply flag csstyle to use it - if it is found, csstyle will just use the already-existing version in the pipeline - this makes installation/setup a tad easier, and has a little bit of performance benefit.

What do you think @geddski?

Can someone please explain me this?

Whats the difference between

<style>
.button {
    background: #6BD9ED;
    padding: 15px;
}
</style>
<a class="button">Neat!</a>

and

@include component(button) {
  background: #6BD9ED;
  padding: 15px;
}

<a class="button">Neat!</a>

why should I use compoment(name) instead of .classname.

and what does "generates your selectors for you" mean?

Thanks

A few people have suggested making / the default symbol for parts. For example:

div class="button/icon"

I like this quite a bit. It deviates from BEM a bit more which is fine. It also makes csstyle even more similar to the CLI with directories separated by / (on *nix at least). Only downside is that parts would have to be escaped when accessed with certain JS apis. But parts are probably the least accessed class from JS so I'm cool with the tradeoffs. Going to make this happen soon unless anyone has a good counterargument.

I think a comparison with BEM would be really great in the FAQ. A why of csstyle.

The biggest change I've noticed is the modifier, and I think there's some potential for issues where components overlap. See: https://en.bem.info/faq/#why-include-the-block-name-in-names-of-modifier-and-element particularly the part about ambiguity of what a modifier belongs to[1]. and potential for modifier overlap. I was interested in your considerations & solutions around this sort of problem?

[1] For clarity, I mean this line:

This kind of HTML markup leaves it unclear as to whether the modifier relates to the menu item (menu__item.active) or the button (button.active). Specifying the block name (button_active) indicates the BEM entity to which the modifier will be applied.

Hello!

The concept looks awesome. Unfortunately I cannot make it work on either Rails or Jekyll, because there comes the following conversion error:

Conversion error: Jekyll::Converters::Scss encountered an error while converting 'css/csstyle.scss':
Invalid CSS after "...x: str-index(#{": expected expression (e.g. 1px, bold), was "&}, "__") - 1;"

Any hint how that can be solved?

The styles generated by cssstyle.io are not rendering on iOS. Can you confirm this please?
I need help.

an example would be a sub class {./--} not rendering

I'm using your mixins for a (atomic design) project, and I really like it. But I've done some minor changes to it because I found the mixin's names to be kind of weird and hard to read in context.

Here's my suggestion for new names:

/* Component (same as before) */
@include component(componentName) { }

/* Modifier (previously option) */
@include modifier(modifierName) { }

/* Child (previously part) */
@include child(childName) { }

/* Tweak (same as before) */
@include tweak(tweakName) { }

/* Location (same as before) */
@include location(locationName) { }

Just ignore it if you don't agree :)

Kepp up the good work!

I've been unable to get cssstyle working in my gulpfile. Maybe I'm just not using it correctly?

Whenever I run my default task, I get this error:

[22:39:28] TypeError: undefined is not a function
    at Gulp.<anonymous> (/Users/dtigraphics/Git/block-css/gulpfile.js:81:17)
    at module.exports (/Users/dtigraphics/Git/block-css/node_modules/gulp/node_modules/orchestrator/lib/runTask.js:34:7)
    at Gulp.Orchestrator._runTask (/Users/dtigraphics/Git/block-css/node_modules/gulp/node_modules/orchestrator/index.js:273:3)
    at Gulp.Orchestrator._runStep (/Users/dtigraphics/Git/block-css/node_modules/gulp/node_modules/orchestrator/index.js:214:10)
    at /Users/dtigraphics/Git/block-css/node_modules/gulp/node_modules/orchestrator/index.js:279:18
    at finish (/Users/dtigraphics/Git/block-css/node_modules/gulp/node_modules/orchestrator/lib/runTask.js:21:8)
    at /Users/dtigraphics/Git/block-css/node_modules/gulp/node_modules/orchestrator/lib/runTask.js:52:4
    at f (/Users/dtigraphics/Git/block-css/node_modules/gulp/node_modules/orchestrator/node_modules/end-of-stream/node_modules/once/once.js:17:25)
    at DestroyableTransform.onend (/Users/dtigraphics/Git/block-css/node_modules/gulp/node_modules/orchestrator/node_modules/end-of-stream/index.js:31:18)
    at DestroyableTransform.emit (events.js:129:20)

BTW: I'm using gulp-load-plugins to auto load all plugins but even require-ing it manually it still isn't working. In my gulp file I have this:

gulp.task ('css', ['minify:css'], function (){
    processors = [
        p.mixins,
        p.nested,
        p.cssnext({
            features: {
              customProperties: {
                variables: cssVars
              },
              compress: false,
              autoprefixer: { 
                browsers: ['last 2 version', '> 5%'] 
              },
              rem: false,
              colorRgba: false,
              filter: {
                oldIE: false
              }
            }
        }),
        plugins.cssstyle(),
        p.fakeid()

    ];
    return gulp.src(basePaths.src + assetPaths.css + appFiles.css)
        .pipe(plugins.sourcemaps.init())
        .pipe(plugins.postcss(processors))
        .pipe(plugins.pxtorem(pxtoremOptions))
        .pipe(plugins.sourcemaps.write('.'))
        .pipe(gulp.dest(basePaths.dest + assetPaths.css));
});

Any thoughts? Thanks!

My build tool uses libsass, which doesn't seem to provide the features that are required by csstyle :( What version of SASS is required for csstyle? They're currently working on 3.0rc4, but I don't know what version of Ruby SASS that corresponds to.

Would csstyle still (mostly) work without the nesting features that rely on #{&}?

@geddski or @kentcdodds
Apologise in advance. I maybe asking questions in the wrong section... by submitting a ticket.

How would you recommend approaching sass convention for modifying components within a larger component?

Would this work?

<div class="button-group">
    <a class="button">Cancel</a>
    <a class="button">Confirm</a>
</div>

@include component(button-group) {
    width: 100%;
    text-align: center;
    @include component(button) {
        display: inline-block;
    }
}

Thanks!