Things That Conflict Me

Random topics that I find myself pausing at throughout my day/work.

Using JavaScript vs. CSS to determine display by breakpoints

When working in a JavaScript context, having a global keeper of the current screen size (xs, sm, md, lg, mdOnly, smAndUp) as Vuetify does is very handy. For example:

<div v-if="$vuetify.breakpoint.smOnly">...</div>

I use this object a lot to fine-tune display needs. However, it does feel like a lot of overhead/processing for something that can also be achieved with CSS. With layouts that change significantly depending on particular conditions, however, this might not be true. Often the conditional is much more complicated than the one above. Knowing when/how best to use these features is something that gives me pause. In practice it ends up being a mix of JavaScript lookup (which does cause a delay as the window is resized, compared to CSS media queries which seem to switch more quickly), CSS classes, and specific breakpoint handling in the style sheet. It may be helpful to work through some of the commonalities and define a rough set of guidelines.

Lately my strategy is often to give components particular state based on particular class names/flags (such as op-card--transparent or op-card--condensed), and define as much as possible on the class.

Using "atomic CSS" classes

I think most people have come to recognize the convention of frameworks the use classes like text-small, text-normal, text-large, py-0, pa-0, etc. These are utility classes to be used throughout mark-up to achieve necessary spacing, sizing, etc. I do use them a lot. Some general feelings from use:

🟢 Very handy to use these classes on the fly to achieve quick prototypes, without thinking too hard about the details

🟢 Used consistently, can standardize choices that often get lost or messy in development (getting exact font size, colors, spacing, etc. slightly wrong)

🟢 Does not require a build process to apply (though you might still want a build process to create/manage the classes)

🟢 Helpful for context-specific overrides for otherwise well-established choices in the base style sheets — and with minimal use it can be obvious to the reader that it's an override

🔴 In practice, it begins to feel like a proxy for inline styling — try changing all uses of text-small to text-normal for a particular card type that has not yet been componentized — component use definitely mitigates this problem — otherwise this is not very different from using inline styles in place of external style sheets (though still a step up, as multiple styles can be defined for a class)

🔴 Even with components, it's easy to lose track of "base choices" when atomic CSS is the primary means of styling — there is a lot of copy/paste in my workflow with these classes — compared to working with preprocessor mixins and variables which I find a little easier to manage/track for consistency

Examples

🔗 Buzzfeed's atomic CSS framework