
Show HN: Mimic – class-fied inline CSS - peterchon
http://peterchon.github.io/mimic/
======
nness
I feel like this is akin to "killing the patient to cure the disease." In the
uses I can see for this, the way this framework solves the problem, to me,
seems to be worse than any problem itself. Namely, I would like to know how
this is any better than !important on your CSS properties.

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.)

~~~
peterchon
Hi, thanks for taking a look. Could you tell me why this won't work without
JS?

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.

~~~
talmand
I too don't understand the JS comment.

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.

~~~
peterchon
Thanks, yes I agree it's a lot - but I'm hoping to make something that people
can customize so that you don't have 0-100px of choices (but for now, it's an
attempt at something new)

------
elaus
Could you please elaborate a bit more on how a class "padding:10" is better
than just adding an inline style "padding:10px"?

~~~
zamalek
I'd presume because you can do browser-specific hacks/normalization with
classes but not inline styles.

I don't really see the point of all of this, either, though. Maybe it's
satire?

~~~
grrowl
It must be effective satire, my blood boils with the possibility it's an
honest attempt.

~~~
peterchon
Hi, I'm sorry that I gave you such stress - it wasn't my intention. It would
be helpful if you could explain why it caused you such angst.

------
juhq
When doing things like this, you should take ie into consideration
[http://spaceninja.com/2015/03/31/ie-css-
limits/](http://spaceninja.com/2015/03/31/ie-css-limits/)

Using parker
([https://github.com/katiefenn/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)

~~~
peterchon
Interesting - I'll take a look.

------
bbx
How do you handle advanced selectors? Or hover states? Or priority? Or
inheritance?

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".

~~~
oneeyedpigeon
Although bear in mind that bootstrap still does class="alert alert-danger" so
they disagree slightly on that point.

~~~
Raphmedia
Yes, but "alert" simply means "this is an alert" (so, it may be a box or a
popup, depending on where it is on the app/website). "alert alert-danger"
means that this alert, whatever shape it is in, is also the alert for danger.
It may be red, yellow, blink, have javascript attached to it, etc.

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".

~~~
oneeyedpigeon
Yes, I fully understand why "alert-danger" is better than "alert-red". What I
_don 't_ quite get is why "alert alert-danger" is better than "alert-danger".
Isn't it possible - using a preprocessor - to maintain alert-danger, alert-
warning etc? If multiple classes _must_ be used, why not just "danger" which
then allows the red coloration to be shared amongst different object types
without being repeated.

~~~
Raphmedia
In my opinion it is better since having the two classes allow you, amongst
other things, to use advanced selectors.

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

~~~
oneeyedpigeon
What does

.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; }

~~~
Raphmedia
In my opinion, you are mostly right that "alert danger" and "alert alert-
danger" would be the same. The exception would be that you could easily apply
global styles to "alert danger" via the ".danger" class. However, I find that
in big websites, I don't want to rely on the global scope (for lack of better
words) too much.

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).

------
arsalanb
Hey, this is a very radical approach. I have great respect for people who ship
something (anything!), because they have the vision to see things differently
and actually execute this vision.

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! :)

~~~
peterchon
I appreciate your kind words. It's always tough to put things out there for
scrutiny.

------
bobwaycott
So, basically this is just meant to feel better about using the `class` attr
instead of using the `style` attr. Oh, and spaces instead of semicolons?

------
inaccessible
So now I don't have to use inline styles, just spam my css file with
margin:0-100 and padding:0-100 classes, and I'm good to go?

~~~
peterchon
Hi, thanks for looking. You don't have to do anything that you don't want to
do.

------
solveforall
As someone who is perpetually terrified to do a Show HN, congrats for shipping
something. I also don't think this idea is much better than inline style
attributes, but it's something different at least. You seem to take
constructive criticism well and that's a good sign. My advice (worth nothing
since I haven't shipped) is to learn from the feedback and come back with
something else.

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.

------
sdnguyen90
Going to be honest.. this doesn't look too well thought out. Something like
z-index you have a class for values of 0 up to 100. Not necessary IMO.

I'd recommend taking a look at Basscss for some inspiration. From my
perspective, you're trying to create something similar to Basscss.

~~~
peterchon
Perhaps, which is why I appreciate everyone's feedback.

------
Raphmedia
That's the equivalent of a front-end developper going into back-end, saying
"screw this!" and hardcoding everything.

Urgh.

Also, you cannot use numbers as classes. That's not allowed and may mess up
some browsers / devices.

~~~
peterchon
Hi thanks for looking. Could you elaborate on your last statement?

~~~
Raphmedia
Sorry, I was wrong. It seem that they cannot _start_ with a number but you can
use a number in them so long as your class start with a valid character. I'm
however worried at the use of the : character.

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.

~~~
oneeyedpigeon
I don't think there's anything invalid about the colon character in a
classname. It's _unusual_ sure, and probably not recommended (it has to be
escaped in selectors, for one, which is a bit of a pain) but if it causes any
tools to break, I think that's the fault of the tool.

~~~
peterchon
of course, and I completely agree. I started off using a hyphen, but tried a
colon just to make it look similar to inline-css.

------
jsalinas
It's sad that this reminds me to the worst CSS framework I've ever used (and
was forced to use):
[https://github.com/EasyBoxModel/EBM](https://github.com/EasyBoxModel/EBM)

Check
[https://github.com/EasyBoxModel/EBM/blob/master/app/assets/c...](https://github.com/EasyBoxModel/EBM/blob/master/app/assets/css/ebm.css)
to get the idea.

~~~
peterchon
Hey sorry that you were stuck with a framework. It's not a framework, it's
meant to be a quick way to add styles without having to make more css classes.

------
joe5150
This doesn't result in very readable markup or have any of the benefits of
actual inline CSS, so I don't really see the need here.

~~~
peterchon
I appreciate you taking a look, thanks!

------
tjsix
I don't really want to be negative but I really can't see how this could be
used for anything other than a quick prototype scenario. I'm never going to
add 126kb of css to a project just for shortcuts like this, it just doesn't
make sense given that the large majority of that added css weight will never
be used.

------
KoulMomo
Yahoo actually came up with something similar
[http://acss.io/](http://acss.io/)

Benefits over just using inline styles: 1) support for pseudo-classes (:hover)
2) reduce markup bloat (shorter class declarations vs equivalent inline-style
declarations)

------
namuol
wat.css ¯\\_(ツ)_/¯

------
robotnoises
I don't think this is a joke. I think this is just something that probably
isn't useful as a library/framework/whatever + maybe an incomplete
understanding of how CSS best fits into the puzzle.

~~~
peterchon
Thanks for taking a look. As mentioned, it's not a framework - it's a way for
me to add simple styling without having to find/add/replace existing class. It
may not seem useful to you as a complete solution like bootstrap - but when
writing custom directives, it really helped me.

------
eduardo-costa
There is something similar. [https://github.com/eduardo-
costa/shortcutcss](https://github.com/eduardo-costa/shortcutcss)

------
Kiro
I don't think it's a joke. It contains some useful stuff like row and col
which you can't do with inline CSS.

~~~
oneeyedpigeon
Sure, the row and col stuff makes sense ... which makes it all the more
bizarre that the terrible inline-as-classname stuff is included. I fear it
might be more a 'troll' than a joke; either that or this person has _really_
got the wrong end of the stick.

~~~
peterchon
Thanks for taking a look, I appreciate everyone's opinion on things. Could you
share why you think this way?

~~~
oneeyedpigeon
Because why wouldn't you just use inline styles if you really wanted to do
this kind of thing?

~~~
peterchon
There's nothing stopping you from using inline-styles. It's another approach.

------
Mahn
Perfect, now we just need an equally redundant pseudo syntax template system
that produces html on top of this.

------
willthefirst
irony has reached the front end.

------
dr_faustus
Brilliant!

~~~
dr_faustus
Doesn't anyone get that this is a joke?!?

~~~
kbody
I thought so as well, then I read some comments and doubt it a bit.

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.

------
rafaqueque
This is getting crazy.

~~~
peterchon
Thanks for taking a look. Could you share why you feel that way?

------
jarco
This is by far the most insane and stupid idea I have seen this year.

~~~
peterchon
Well, the year isn't over yet :P

~~~
oneeyedpigeon
You have more up your sleeve?! ;)

~~~
peterchon
It does say: "more to come" maybe you'll get more laughs.

