4 ms·
I feel you're approaching the problem in the wrong mindset. You're imagining that you have one module and that's all you ever have. Instead, think of a the CSS
by russelluresti 14y ago
I feel you're approaching the problem in the wrong mindset. You're imagining that you have one module and that's all you ever have. Instead, think of a the CSS module (your .testimonial module) as an interface - a blueprint to implement different types of .testimonial module variations.
The BEM architecture calls these "Modifiers" (http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/ http://csswizardry.com/2013/01/mindbemding-getting-your-head...).
When I look at your example, I don't think of a .testimonial object in two different contexts (one vertical in the sidebar of the signup page while one horizontal on the pricing page). Instead, I think of two different variations of the .testimonial object. So while your .testimonial class may define certain global styles, you change what you need by variations like .testimonial.vertical or .testimonial.horizontal (though I wouldn't actually use those names, but you get the idea).
This requires making a decision on when to apply what classes, but that's okay. You shouldn't be trying to abstract away actual UI decision-making to an automated tool or process. You seem to think that settings rules and logic to be executed based on those rules (when x, execute y; when y, execute z; etc.) will mean you always end up with a usable interface. However, this is not the case.
Ultimately, UI is not "write-once, use anywhere", and that's okay.
- condiment 14y agoI agree with this. Media queries are a tool that eliminates the need to maintain separate HTML templates for mobile- or tablet-specific versions of a website. They work well at this task. Element queries as described by the author address an entirely different set of concerns, which is that modular components of HTML might be re-used in varying situations, and depending on the implementation you might want to style them differently. Media queries are the wrong tool to solve this problem. The problem is that when we want to use this: .testimonial (max-width:27em) {font-size: 0.8em;} We have to use a context-specific style definition instead: .testimonial {font-size: 1em;} .signup .testimonial {font-size: 0.8em;} Or, better (from the parent): .testimonial.vertical {font-size: 0.8em;} .testimonial.horizontal {font-size: 1em;} You might still have to revisit each of these styles in a media query to apply changes depending on the global presentation. So while the proposed element query might eliminate the need to chain selectors, I do not believe that it simplifies media queries in any meaningful way.
- Wintamute 14y agoNo, the problem is with your class names .testimonial.vertical .testimonial.horizontal By including those classes in the actual markup you're hard-coding semantics about the presentation of those two elements that may cease to be relevant when the screen changes width. What if when the screen gets sufficiently narrow you want the horizontal layout to actually change to vertical? The breakpoint at which that happens is more closely linked to the size of the element than the global size of the whole screen (which media queries relate to). So the point is that with element queries you're defining modular breakpoints that directly relate to your CSS modules, not the global size of the screen, and you're not polluting/complicating markup with CSS class names that could become non-semantic in drastically differing viewport dimensions.
- cia_plant 14y agoI think there must be some schism here between people with a design background and people with a programming background, or something. As someone who is more of a programmer, if I can think of a way to specify what I want unambiguously, and my language doesn't let me use that method to actually specify the computer's behavior, then the language is broken.