Last Friday, I gave the first in a series of front-end web development talks here in Taipei. There were 11 attendees as we discussed in length how to structure a site’s styles with CSS components and Drupal 8 naming conventions.
The success of the class was entirely due to the participants who were engaged and asked lots of questions to probe their understanding of the concepts and challenge me on things that seemed a bit off on my slides. We talked for over 3 hours; here are some highlights:
We started the evening by going over the core front-end development principles: progressive enhancement, accessibility, front-end performance, re-use, and automation. When we talked in detail about the layered approach for progressive enhancement, they noticed right away that it implies accessibility. Very astute! Now that I’ve had a few days to reflect on this, I can see a general pattern. Not only does progressive enhancement imply accessibility. Accessibility implies front-end performance. Front-end performance implies re-use. Re-use implies automation. They are all inter-related.
A few of the participants had used Angular.js, so we discussed how Web Components (the W3C spec), React.js components, and other framework components are slightly different than CSS components. Those components require a specific HTML element that contains any other markup; this forms a strict HTML structure that is always used when the component is used. CSS components, on the other hand, have a strict structure of class naming, not of HTML elements. The structure of our CSS component, e.g. .the-component, .the-component__an-element, etc., should never imply an HTML structure because they could be applied to different HTML structures. The classic example of this is the .button CSS component which can be applied to inputs (<input type="button">), buttons (<button>), and links (<a>).
They were amused by my drawing skills when I showed them my example CSS component: flower power.
When they saw my .flower__bed element, they asked how I would handle adding a .tree component that could also use a planting bed. Great question as it shows a very typical scenario in web development. I built the original .flower component with a simple initial requirement: the website only has one component. Now they were saying the requirements have changed; we have a design system with multiple components, a flower and a tree. Changing requirements on projects is natural. In this case we just need to do a simple re-factor. The .flower__bed probably needs to be refactored to be its own component, a .planting-bed component that can contain a .flower or a .tree.
They loved the class name of shame, .channel-tab__guide__upcoming-video__info__time. That name implies all sorts of HTML structure that makes the component difficult to refactor. .channel-tab__video-time is more flexible and much simpler.
One participant asked about an example class name I had shown, .the-component--modifier__an-element and we discussed how that should probably be replaced with .the-component.the-component--modifier .the-component__an-element as it makes it easier to create compose-able modifiers (e.g. .button, .button--big, .button--red can be combined to create a big button, a red button or a big red button.)
I love discussions of the ideas I present because I gain valuable insight from the participants. Thank you so much to all who attended!
By the way, if you missed the class or don’t live in Taipei, I’m available to teach your organization remotely or in person. Just contact me!
Comments