Closed mrmartineau closed 7 years ago
Looks good đź‘Ť
The SASS importer looks interesting – guessing it’s the npm-sass
module that does the magic? Does it mean that if someone imports the module as part of their project they would have to edit the file in the node_modules
folder if they wanted to change those styles? Just wondering how this would work in practice in terms of modifying the component styles.
Definitely agreed on the _build-configs
folder name change and SVG stuff sounds cool too.
Yes, npm-sass
does the magic there but I am worried that importing many modules with it may reduce performance and slow build times, so we'd have to keep an eye on that. Currently my postcss-playground repo has 5 files and one imported from npm and takes <2s to complete..
Ok. If someone downloaded Kickoff and wanted to add some buttons styles to the _buttons.scss
file (just as an example, would the SCSS file be included in the node-modules
folder if it was an npm module? Or is there a way of installing it such that the SCSS file would be in the SCSS folder somewhere?
Just wondering how the structure of the SCSS would change (if at all).
Yes you're right, I hadn't thought of that.. perhaps it is only useful to transfer components that aren't likely to be modified like the grid. Forms probably would not be able to be a 3rd party dependency because of this unless we removed all styling from them and then created themes for the fields - something that is also very intriguing
Just as an aside that I thought about over the weekend – when we migrate this over to the generator, we’ll need to update the Statix config as well (as it works differently in Gulp to how it works in Grunt).
Shouldn’t be a big task but it’ll need checking when the generator gets looked at.
Is it worth moving it to gulp now so that it will be ready for the generator?
We already use Statix in Gulp for our docs at JE, so this should be pretty trivial.
Grid module has now been separated. I’m going to pick up the statix tasks now, and if there’s anything specific you want me to test, let me know
@ashleynolan I tried the grid stuff this morning - it works perfectly. đź‘Ť
I also found a better media-query mixin library that we ought to use. I have created a features/next_mixins. Syntax looks like the below and it even works with our $breakpoints
sass map!
@include media(">mid") {
width: 100%;
}
@include media(">mid", "<=large") {
width: 50%;
}
Just been looking through it and the source code – looks really nice implementation.
Only thing I can see that might be missing is whether it converts pixels to em units. If it doesn’t do this, would this be something we could look to PR into the library?
@ashleynolan can you remind me of the specific reason we convert to ems? I have just looked at the source and see that it supports all units but I don't think it converts to ems.
@ashleynolan this article says we don't need to worry about it anymore because browsers are all consistent now: https://cloudfour.com/thinks/the-ems-have-it-proportional-media-queries-ftw. If that's the case I would move to use this because of the many benefits it gives us devs.
Accessibility reasons – around zooming and default font sizes. There used to be a Chrome bug that warranted it as well, but that has been long fixed.
I have been chatting with the devs of include-media
and I think I figured out a fix: see this comment: https://github.com/eduardoboucas/include-media/issues/93#issuecomment-253166723
Sounds good. If we can resolve that issue, looks like it would be a great solution. Been wanting a min-height mixin for a while so this would come for free with this too :)
@ashleynolan you may have seen that I submitted a PR to the grid so that it uses include-media as well. Have a look, try it out and let us know what you think
FYI, this is our updated checklist for v8:
Ok cool - good to have this. I started having a look through the repo yesterday. Will try and make a bit of time over the weekend to take a look over the site and generator too.
Will prioritise that first and then get onto the statix integration after that.
@ashleynolan :+1:
v8.0.0 is ready. Gonna merge it in now..
Kickoff 8 will introduce some fairly fundamental changes to the project without changing how developers use it.
gulp
We are working on switching the build tools to gulp (with the potential addition of webpack for javascript compilation). This new tooling affords quite a few other benefits, not least are how we compile our sass. I have created a repo postcss-playground to demo this.
We currently have a directory named
_grunt-configs
, I propose that we change it to a non-specific name like_build-configs
so that we are not restricted by the tools we use. Potentially a.build-configs
folder would be nice because it is hidden (on a mac) and treated more like dotfiles/configs on some systems.Modularise sass components
With this new tooling we are able to
@import
sass modules from an npm 🎉 This means we can finally move our grid, forms and probably most of the components into their own repo and maintain them independently. The added benefit of this is that it allows other devs to consume these packages without having to consume all of Kickoff..SVGs
We used to use Grunticon but removed it recently. Now its time for a better solution to resolution independant graphics. I would like to be able to have a folder full of individual SVGs, have a build tool convert them into a SVG sprite/map and then consume them as an external on the page using the
use
syntax. Browser support is obviously going to be an issue so something like svg4everybody to shim browsers with poor support (thanks @nicbell).React
The work on [kickoff-react]() will be independent of this update but it is worth noting here as something we are developing at the moment.
Checklist
@import normalize
[50d1b90]Have I missed anything?