A Styleguide Idea
The amazing @san_toki very kindly redesigned my site and I’ve been spending time getting everything up and running ready for release. One of the tasks I’ve working on is re-building the styleguide.
The old styleguide is still alive at https://gauntface.com/styleguide/, it’s pretty shoddy looking, but it helped me focus on treating my UI as components rather than a big CSS file with duplicated styles.
The redesign gave me a chance to address some of the shortfalls of this current approach:
- I was still tripping up on designing for different screen sizes.
- I loved the baseline grid but it was hard to switch on and off and apply for all components.
- The components and pages had a lot of manual work to keep them up and running.
Enter Styleguide v2
The styleguide ultimately became a toolbar.
This toolbar sits at the top of my styleguide and controls a component page which is displayed in an iframe below it. The left set of icons change the screen size and right allow toggling of remote stylesheets and grid lines.
Screen Sizes
To test screen sizes I normally drag the browser to change it’s width or use DevTools device mode. This can be cumbersome when you just want a gut check.
By loading my component pages in an iframe, I can set the width when ever a button is clicked on the toolbar. The great thing with iframes is that changing the width will trigger the media queries of the page inside it. All I have to do is click the mobile device and boom.
Iframes have their shortcomings and I can’t emulate things like screen density, but for gut checks, this is all I need.
By this point you may be wondering about the two icons left of the mobile device…..well I kind of had this curiosity of what a website would look like if it worked on a watch. There is pretty much zero chance of it ever being a thing, but….
- It’s a fun idea to consider
- It tested my ability to work on small screens
- There is always the Web Browser for Android Wear.
Side Note: Developing for the Web Browser on Android Wear is hard. Still got a ton of things to try out, but it’s quickly falling down my to-do list (other more pressing matters like — oh I don’t know — launching the site, is taking priority).
Baseline Grid
The baseline grid was super easy. Add a button that adds the grid overlay into the iframe.
Cheeky click on the grid on the top right and I can toggle through a dark and light grid.
This allows me to check whether everything sits on this grid vertically. Horizontally this is useful for left alignment (See how the icons sit on grid below).
Critical Path
These above features were built when I started building the new components.
What I wanted to do was solve how much CSS I was in-lining, largely because I couldn't easily split my old CSS between critical and non-critical. Instead, I in-lined everything and accepted this wasn’t ideal.
I went through a few different ways of structuring my CSS and the final version I landed on, is splitting up each component’s styles into separate in-line and remote stylesheets.
With this, I can use the loadCSS library to async load the remote stylesheets. Looking through the library source I can use the same logic of the library to disable and enable the remote stylesheets on demand.
Clicking on the icon next to the grid icon on the top right, I can see what the component looks like with and without the remote styles.
The awesome @aerotwist took this idea and made it into a bookmarklet so you can try it out on any page.
That’s it. That’s my styleguide, built to test across devices, test against a grid and test for critical path.
Building the Pages
The main thing I struggled with in the past was building the pages from these components.
At the moment I’m doing it by constructing a pages styles based on the components used in them and from this list, build an inline and remote CSS file for the page.
Below is an example JSON file defining the home pages components.
I created a gulp task which goes through each component looking for specific files, for example, appbar would result in looking for ‘appbar/_appbar-inline.scss’, ‘appbar/_appbar-remote.scss’ and ‘appbar/_appbar-mixins.scss’. With this list of component files, it generates a sass file with these as imports and runs it through gulp-sass.
This makes it a little easier to glance at what is being pulled into each of my pages. I only have to manage one list and the rest is managed by the build process. Time will tell if I still like this after a while of living with it.
Thoughts
The main thing I’m curious about is what people think of this approach.
Are parts of it useful?
Does any of this even matter?
It may be simply too much effort for what it achieves, but I’m hoping that if some of the approaches are solid, it could be adopted by others and made general enough for anyone to adopt.
The critical path I’m still exploring, but this approach thus far is serving me well.
Now to finish the site, get live and then drop a link to it on here….
