Week 11 — Behind, but I’ll do it!
So I’m now ~6 weeks behind on my initial plan. The good news is that Cap are happy to support me with some extra study time to get back on track. I personally believe I can still deliver a high quality product within the 18 days that remain!
These posts however will be reduced in size and predominately bullet pointed to demonstrate and document progress efficiently.
- I produced a questionnaire for colleagues to fill out. My aim is to gather information on what components and frameworks they use. This will form the basis of ‘iteration 2/3’ of my accessibility guidance.
- I completed iteration 1 of my accessibility guidance. This collection of useful resources has given me the knowledge required to produce good content. It’s available on GitHub to enable others to find similar information if they so wish. I followed a defined process for identifying links which is documented at the top of the page.
- I produced a colour contrast checker this will be useful for others as it gives feedback on the colour contrast of two colours and what text size is considered acceptable under the WCAG guidelines.
Some additional goodness
When building the colour contrast tool I tried out a new framework ‘styled-components’. This framework puts ‘CSS in JS’ which is against what I considered ‘best practice’ for the last few years. However after experimenting I was surprisingly convinced:
- My components were ‘Pure’ — Given the same input the same output would be rendered. This results in predictability and consistency, something I appreciate as a programmer.
- Because my components were pure testing is easy! You can use Enzyme (Airbnb testing utils) with Jest (Facebooks test tool) to validate your component.
- As the styling was ‘scoped’ to a component many of the problems with CSS I have experienced in the past were gone. I no longer had to worry about styles somewhere else in my code base affecting my component — This was the biggest positive for me, as I usually use namespacing for this which results in duplicate CSS anyway!
Why doing things in public rocks!
So after experimenting with ‘styled-components’ I tweeted the person who wrote the framework.
Which was then picked up by a developer at PayPal who wrote another “CSS in JS” framework ‘glamorous’. He forked the project and converted it to ‘glamorous’.
Interestingly after some time someone spotted a security vulnerability which I had unknowingly created. Similar to SQL injection, CSS injection is considered a major vulnerability which is explained extremely well in the in the link in the tweet. In my case it’s relatively minor, but in a ‘real’ application it could cause major problems.
Following standard practice I did the following to resolve it:
- Opened a Github issue describing the problem and documenting steps to reproduce
- Fixed the issue on a new branch
- Pull requested the fix into the master branch
- Redeployed to ‘production’. In my case I use Github pages so the master branch is automatically deployed onto the web.
- Raised a Pull Request on the ‘glamorous’ implementation.