Would it make sense to add flexbox mixins?

Just found out about Chopstick in Responsive Design Weekly, and I'm tempted to try. Beginner of everything web here, so sorry for the question.

I saw the example of Chopstick and the default theme of the SCSS file, and spotted a background-color on the html which is not the primary background color. Why does the primary color get moved to .holder?

Create a pattern for tables with default responsive table styles

See _mixins.scss L66. Update block mixin to use

• background color
• foreground color
• border radius
• border width

In stead of having all the media queries at the bottom of the file, we need to use inline media queries so they appear in a more logical place.

Preferably, we use the @include mq($bpn) mixin for all media queries.

I feel we should rename this repo from chopstick-demo to something more suiting now that we still can: chopstick-skeleton, chopstick-boilerplate or chopstick-styleguide would all make more sense I think :).

Anyone else has any suggestion?

Unable to build with Jekyll.
Keep getting error:
Liquid Exception: invalid byte sequence in US-ASCII in grid.html

Jekyll version
jekyll 1.2.1
Ruby version
2.0.0

Example: proto

How about nailing a date and discuss new goals?

Improve first-run experience by making sure a screen.css file is generated on the first install/run of Chopstick.

A pattern for a navigation list = a vertical list of links with dividers.

It’s time that we think about versioning and releases. I believe Semantic Versioning is a good starting point. But any input at all is welcome :)

Maybe we can add more colour variables in a _colours.scss file? We can work with smart defaults like: http://clrs.cc. Could be useful for quickly prototyping things with a nicer colour palette?

Just a brainfart :).

A pattern for icons (using png & svg). Also provide a sketch template to create new icons.

See http://css-tricks.com/inheriting-box-sizing-probably-slightly-better-best-practice/

Make chopstick modular (replace git subtrees)
http://doodle.com/hf6cusxi3kshsn65

I think we should also show the HTML snippets in the style guide (next to which scss file to load)

http://www.stubbornella.org/content/2010/06/25/the-media-object-saves-hundreds-of-lines-of-code/

Inspired by: http://nvie.com/posts/a-successful-git-branching-model/

We already us feature branches so we only need a few tweaks:

• no more committing on the master
• add a develop branch
• start using bugfix branches

We should probably look to using Bower to manage JS dependencies.

Should I add this to the color settings?

$grey-00 : hsl(hue($alpha-ui-color),10,45);
$grey-01 : hsl(hue($alpha-ui-color),10,55);
$grey-02 : hsl(hue($alpha-ui-color),15,65);
$grey-03 : hsl(hue($alpha-ui-color),15,75);
$grey-04 : hsl(hue($alpha-ui-color),15,85);
$grey-05 : hsl(hue($alpha-ui-color),25,95);

I think we need to cover some more complex form cases as well, such as inline forms.

• Simple form: basic comment style form > e-mail, name, comment, opt-in, submit
• Advanced form: multiple fieldsets > select, radiobutton, date picker, number, ... , submit
• Inline forms: multiple examples of inline form elements > radiobuttons, select, text, …

If your Ruby version is different then the one specified in the gemfile. Bundle install returns an error. It's easily fixed when you change the version in the gemfile. Is there a way this error can be avoided?

We are using gulp for some time now and it seems like a more flexible solution for generating our scss, javascript, etc.

I'm open to discuss the pro's and con's.

We should tweak the button mixin so text aligns nicely vertical.
We could also maybe extend the pattern to create a range of buttons (ex. icon button, multiline button, ... )

Maybe it's a good idea to extend the current media.scss file to a more generic objects.scss? I am thinking more modular layout classes like holders, inline-listing options, reverse floating, islands, ... being placed there . Maybe we should introduce the naming method described in SMACCS for these things? For example .l-float-rev and so on ...

I am missing some essential components while prototyping. For example, modal windows, a good tabs component, ... . Should we choose to keep Chopstick as a base and combine it with Bootstrap? Or should we create our own components which we could implement separatly from core?

The git subtree system is not working properly or is too difficult to maintain. This causes some difficulties to keep chopstick in sync with potnoodle.

I like the use of bower in the new version of Inuit CSS. This means splitting our functions and patterns into separate repositories and then loading them into the boilerplate and potnoodle with bower.

Any other ideas on changing or fixing this system?

• e.g. colors, media queries, . . .
• Location: theme/

http://zerosixthree.se/vertical-align-anything-with-just-3-lines-of-css/

This probably needs to be split up into multiple issues, but it would be nice to have scales for:

• z-index (https://gist.github.com/fat/1f6da6b3bd0311a1f8a0)
• colors (lighter and darker versions of all colors)
• type-size
• horizontal and vertical padding/margin (grid and baseline grid)
• breakpoints

We would preferably decide on:

• What kind of system/terminology will we use for the scales? Simple example: $color, $color-dark, $color-darker or something more generic like $color-alpha, $color-beta . . .
• Can we automate all those scales by default and allow a user to override them?
• . . .

I understand that it's no primary goal of Sass to generate readable css. But I usually compile the css in expanded output style to make it a "little bit" readable for other developers. I noticed that most of the shared Sass files start with a multiline comment on top. But these are mixins, so the only thing that is inserted in order of appearance in the screen.css is the multiline comment. If you open the screen.css, here's what I see:

/*
    Grid
*/
/*
    Typography
*/
/*
    User Interface Elements
*/

Only the comments are inserted because the other content of the file are mostly just mixins. Would it be better to use single line comments for this, because they are omitted in the screen.css? Chopstick uses this notation a lot:

// 
// Title
// 

The labels only get half the gutter. Is there a reason for that?

We need a flexible script to easily show/hide elements + apply it to the html snippets.

We can easily integrate autoprefixer (https://github.com/ai/autoprefixer) into Compass. Additionally we could remove all vendor prefixes in our code.

1. Add autoprefixer to the gemfile
   gem install autoprefixer-rails
2. Require autoprefixer in compass

require 'autoprefixer-rails'

on_stylesheet_saved do |file|
  css = File.read(file)
  File.open(file, 'w') do |io|
    io << AutoprefixerRails.process(css)
  end
end

Add background-stuff @Dietr can you describe this further?

A pattern for islands (aka callout aka panel aka wells). Multiple variations based on grey and the brand color.

I never use the hide-text extend because if often doesn't seem to work (strange). I actually replace the hide-text extend with this instead:

%hide-text {
    font: 0/0 serif;
    text-shadow: none;
    color: transparent;
}

After much deliberation over here the people of HTML5 Boilerplate settled on this. So is there a chance that chopstick approves this too?