Show HN: Mimic – class-fied inline CSS
peterchon.github.io
peterchon.github.io
Firstly, you're messing up your separation of concerns, you're also messing up an attribute with values that other developers will probably see as a bug — "why isn't this in a style tag?" It also won't work with JavaScript disabled (a few people will complain about that, they always do).
Why use classes at all? If the idea is to not rely on CSS, we could use a data attribute, like data-mimic or data-mimic-width="1", to apply to additional styles (although some CMS' will struggle with this).
(I realise its so easy to be negative, and HN submissions usually have their unfair share of criticism from people who think they know better. Although it obviously solves a problem for the author, at the crux of it, I'd refactor this if I found it in any projects I look after.)
EDIT just actually read the post properly "More to come, including jQuery-less js components. Please stay tuned!" :-)
Is there some specific reason you're trying to solve this with css classes? In this case you're better off just using style="margin:0", or am I missing something?
My motivation to write this is because I always have to go back and make quick margin/padding/etc changes and I hated trying to come up with more class names.
As mentioned, this isn't a framework. It was a way for me to add styles when writing styles to custom directives.
But, if this isn't a framework then it seems rather large. If it were to do only what you describe, simple classes for simple changes, then you are loading in lots of stuff in your inc imports that isn't required.
I don't necessarily have a problem with it, it's not a bad idea. Personally I wouldn't be against using something like this that's tailored to a design so that only the necessary classes are required. That way it isn't necessary to have stepping of 1 to 100 on each property.
I don't really see the point of all of this, either, though. Maybe it's satire?
I don't think it's a "better" way, I wanted to explore another way of adding quick styles without having to come up with a class name.
Using parker (https://github.com/katiefenn/parker) tool to analyze the css:
curl http://peterchon.github.io/mimic/css/mimic.css -s | parker -s
PARKER-JS
Total Stylesheets: 1
Total Stylesheet Size: 126045
Total Rules: 2551
Total Selectors: 2611
Total Identifiers: 5292
Total Declarations: 3849
Selectors Per Rule: 1.0235201881615053
Identifiers Per Selector: 2.026809651474531
Specificity Per Selector: 19.89199540405975
Top Selector Specificity: 40
Top Selector Specificity Selector: .row\:12 .col\:1
Total Id Selectors: 0
Total Unique Colors: 6
Unique Colors: #3F3F3F,#3E49FF,#45497F,#1336CC,#CFCFCF,#CCCCCC
Total Important Keywords: 0
Total Media Queries: 1
Media Queries: screen and (max-width: 736px)There is a lot of reasons why separating content and styling is benefitial to both the designer and the developer. And why semantic classes, especially with tools like Sass where abstraction and reusability are key, allow to describe the content, not define its looks.
That's why we went from color="red" to style="color:red;" to class="red-text" to class="alert alert-red" to class="alert-danger".
I'm not trying to be bootstrap. I wanted a way for users to add css without using an inline-css. As for psudo selectors, it's still easy: .do-this-on-hover:hover { ... }
However, it is not "alert alert-red"... What if your client wanted to never use the colour red again because his competition is branded red? You need to go through all the CSS (a few lines of :red needs to be changed to :yellow). You however also need to go through all your view, templates, possibly some hardcoded parts of the code, to change "alert-red" to "alert-yellow"... simply have it "alert-danger".
Here is an horrible example from the top of my mind:
<nav class="menu">...</nav>
<div class="alert alert-<?php echo $alert-type; ?>">...</div>
.alert { border: 1px solid #ccc; } // Basic alert style
.alert-success { border-color: green; } // Success alert are green
.alert-warning { border-color: yellow; } // Warning alert are yellow
.alert-danger { border: 3px dashed red; } // Danger alert are red !!and have a bigger border!!
.menu { margin-bottom: 14px; } // The menu has a margin of 14px under it so nothing can get close
.menu + .alert { margin-top: -14px; } // Alert following the menu need to ignore the menu's margin
.menu + .alert-danger { margin-top: -16px; } // However, the borders of alert-danger are bigger than the regular alerts
.menu + .alert-danger { margin-top: -16px; }
do that
.menu + .alert.danger { margin-top: -16px; }
doesn't? Isn't "alert-danger" redundant? It means that, in practice, you need to do something like:
.alert-danger, .list-danger, .heading-danger, .foo-danger, .bar-danger, .hum-danger { color: red; }
instead of just
.danger { color: red; }
All my alerts and message styling would be in a separate myApp-messages.scss that would ultimately be merged into myApp.min.css
In this myApp-messages.scss, I would create all my own classes that then extend global style definitions if needed but avoid using them.
.alert{
color: $text-color;
background: $light-background-color;
&.alert-danger {
@extend .danger; // if needed at all
color: $danger-color;
}
As for "alert alert-danger" vs. "alert-danger". It is true that you could do something like :
.alert {
color: $text-color;
background: $light-background-color;
.alert-danger{
@extend .alert;
color: $danger-color;
In the "alert alert-danger" case, you can easily target all <div class="alert"> and then use advanced selectors to filter out or target more specifically its other states. You can also easily append/toggle the modifier classes with jQuery. With <div class="alert-danger", you rely on the css preprocessor to do all the work and in doing so cut yourself from using some tools.
It's all a matter of philosophy, really. I like to have as many tools to do a job as possible, so I try to have as much classes on my elements as I can without going overboard (I'm looking at you, Drupal).
This may take some getting used to, and a lot of debate if using this is really worth it, but it's something. Nice job! :)
Also, I should mention I did have a use for something like this. On my site, I sanitize HTML generated by user plugins, and to ensure the HTML doesn't mess up other parts of the page, I would provide a set of allowed CSS classes, but disallow inline styles. The CSS classes would not include "position" properties, so "position: static" wouldn't be allowed. Later I was able to use phloc to parse the inline styles but prohibit "position", so I didn't need a huge set of CSS classes anymore.
I'd recommend taking a look at Basscss for some inspiration. From my perspective, you're trying to create something similar to Basscss.
Urgh.
Also, you cannot use numbers as classes. That's not allowed and may mess up some browsers / devices.
The style definition might be ignored in some browsers. Some other might break when they see an invalid character and stop parsing your styles.
That being said, most modern browser will be able to parse the CSS without you needing to escape any characters.
Check https://github.com/EasyBoxModel/EBM/blob/master/app/assets/c... to get the idea.
Benefits over just using inline styles: 1) support for pseudo-classes (:hover) 2) reduce markup bloat (shorter class declarations vs equivalent inline-style declarations)
But this speaks for the current state of frontend. We are willing to be open/accept a lot of crazy ideas about organizing the frontend, but thankfully there is a limit.