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.)
Hey, thanks for taking a look. I'm sorry that it wasn't a parody. It's something that's helped me make quick small style changes without having to make more css classes.
Ahhhhh... I'm sorry for suggesting it was a parody.
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?
I wouldn't necessarily say that I'm trying to solve a problem. It's more of why not have modular css-classes that I can use to build things when using custom directives.
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.
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.
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)
My apologies, I noticed a JS folder and comments on the page and assume it was part of the solution. (Seems the timeframe to edit my original comment has expired).
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)
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".
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 { ... }
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".
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.
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 :
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).
But then you'll create bloat. Multiple classes assigned to an element is far more efficient then repeating properties with the same values over multiple classes in the stylesheet.
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! :)
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.
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.
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.
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.
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.
Yahoo actually came up with something similar 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)
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.
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.
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.
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.
Thanks for taking a look. I appreciate everyone's feedback. I understand that it looks redundant and unorthodox, but this way of writing css does help me when I need to add a quick style fix here and there without having to change my main style sheet.
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.)