This is a continuation from the previous post: Is it time to drop the media object?
Having dropped the media object in favour of the flag object I’ve come to find that the uses for this abstraction reach far beyond it’s initial purpose of vertically centering images and text side by side. For a start it doesn’t have to be images and text, it could be form elements, two bodies of text and much more.
With this in mind I propose changing the classnames. Here is the original code for the Flag object:
N.B. The code has changed very slightly with use of the parent selector suffix which was introduced in Sass 3.3 It allows us to append to a parent selector, in my opinion this ‘ghost nesting’ makes the code easier to read, demonstrating nesting without any increase in specificity. It also plays very nicely with BEM.
As you can see here, some of the classnames are assuming that we are using an image, which as I mentioned earlier might not always be the case. It makes good sense to have more extraneous classnames. Perhaps in some way describing their behaviour, rather than what they contain.
“I use this abstraction multiple times in literally every project, and you should too.”
I propose renaming
flag__image with names that better describe their
behaviour. Simply because one takes up a fixed width, dictated by it’s content and
the other takes up the remaining space I propose the following classnames:
The classnames now sort of mimik their pysical properties.
The hyphenated `-cp standing for component.
Here is how the flag now looks with my proposed changes
##Example uses for the flag object##
##Some final words##
As you can see from the examples above there are far more applications for the flag object than it was initially designed for, we don’t even have to use all of the flag object’s components, as in the example with text vertically centered over a banner iamge, that doesn’t make any use of the solid component at all.
Like the Media Object, this abstraction could literally save hundreds, maybe even thousands of lines of code in a large project due to it’s versatility. I use this abstraction multiple times in literally every project, and you should too.