But that doesn't magically insert comments explaining the reasoning behind doing a certain thing a certain way. I don't know about you, but I have those comments in my CSS just for myself, which is a good indicator a newbie might have use for them as well. Lucky for me I do parsing/compacting/caching the CSS on the fly, so I might as well put a comment into the compact version explaining where to get the "max" version. But I don't see how it would be much work with static files for that matter.
I have comments in my css too, mostly things like "product grid", "product detail" etc, which only really function as things to navigate with by searching.
Expecting comments in css to act as some sort of tutorial is a dead end, any website will involve html/css/js working in tandem, why put them in css, rather than html, or js?
A better format for this would be a number of good old fashioned tutorials, screencasts etc geared toward providing the mental tools to inspect any website.
So, sure it wouldn't be much work to add in a comment pointing to an unminified css file, but i fear it would be of little utility to someone learning. That is ignoring the fact i often have 20+ css files across a large site (minified compiled and combined before serving), similar number of js resources and who knows how many combinations of html templates...
What sort of comments do you add? Mine are usually of two varieties - either explaining a pixel value (width + border + margin), or adding a short note about why I did something unconventional (two pixels removed so FireFox doesn't flow to the next line). In either case, someone learning CSS wouldn't be hugely benefitted by them, since I don't make the comments all that verbose.
That said, I usually don't minify my CSS anyway. I was just wondering if there are any significant cases where comments would make a huge difference to someone who is learning CSS.
I think the latter is what could be useful to people learning.
E.g. "set X to Y so browser B doesn't do Z" is actually useful to someone who has never seen that behaviour and may encounter it, or be looking at you sources cause it seems you handled it somehow but it doesn't work on one's own page.
CSS is the easiest part of the design cycle. (The hard part is actually mocking something to look great.. implementing it is the fun part.)
Creating CSS which matches your design should not really be an issue, and as others have pointed out, if you see something on another website that you like, then you can just use chrome inspector which would always work by an order of magnitude better than using a main.max.css sheet as you suggest.
I'm not going to be elitist and say that learning CSS is a non-issue, but maintaining a commented CSS would be ridiculous. Especially when all of my CSS is automatically compliled (lessCSS) and comments are stripped.
What would your main.max.css look like?
.container {
border: 1px solid black; // This adds a solid black border
float: left; // Remove element from doc flow, and align left
padding: 10px; // This adds a 10px padding
background: white; // This sets the background white
}
When I read the title of this post, I thought that you might of been suggesting that developers maintain two sheets, a
[1] main.min.css
[2] main.max.css
Inside of the min CSS, you might use all of your layouting styles and lightweight background styles. However, inside of the max you would add all of your complementary styles.
Such as all of the background gradients. All of your vendor specific box shadows, border-radius', box-sizing, opacitys, etc. Getting background gradients compatible accross different browser vendors totally bloats my CSS (by about a 100-140kb (since I use alot of high quality gradients instead of png).
I could perhaps get behind the idea to seperate two sheets. One min.css for pure templating and layout, and a max.css for all that awesomeness.
The only benefit this would give is being able to detect a user agent and serve up the more lightweight version.
Anyway, big NO NO, for your suggestion. I can't get behind that idea.
That's not a very fair example. That would be like commenting Python like this:
def foo(): # This defines a function
a = 5 # This defines a variable, a = 5
return a + 5 # The function returns the value of a + 5
Not to argue in favor of or against max.css, but nobody comments their code like that. It's more about things like this:
.ribbon-edge {
/**
* By setting the width and height to 0
* and having a really large border, we
* can use the way the borders intersect
* to create a ribbon edge for our header/
* This results in three angled red borders,
* and one transparent, right-facing triangle
* on the left side.
*/
width: 0;
height: 0;
border: 50px solid transparent;
border-left-color: red;
}
Of course this seems like a bad idea, especially since most developers don't bother to:
1) Fully think through what they are doing (clearly they are experts)
2) Comment their code, regardless of where it is in the stack
Generally, when I comment code, I dont do things like "this adds a solid black border". Ya-don't-fucking-say? What should be done, is comment on how this piece of code relates to the larger system at hand, how it interacts with other portions of code, or what else it relies on to work, an example of where it is used, and what not to expect from it. If developers thought this way, we would:
1) Overall have better software in this world, as it requires that the developer think through what he is writing thoroughly instead of rapid-browser iterations and "it works I'm done."
2) Help other developers in our own project, and anyone else who is trying to learn from the source without the benefit of the context the code was written in.
As time goes on I see developers getting comfortable with Ruby, Coffeescript, and the like. They don't comment at all because "the code is readable." Well, if it was readable, they wouldn't fucking call it code! All this really tells me is they don't respect their craft or anyone else who needs to interface or change that code after they've moved on.
As professionals we should take pride in our work. If engineers built bridges like we do software many many people would die and software would be illegal. Now of course development is a little different as most software crashes don't kill people (although some certainly could), but don't use that argument as a way to get comfortable and not do your job with pride.
Yeah initially I agreed with this article, but after reading the comments and thinking about the fact that i always use sass or stylus for css, I think it makes more sense to publish your source on github and put the github url in a comment - this is much better for learning anyway.
since you want the source for the deployed version, not master, and we're trying to make things easy for people grokking what's deployed, not express an opinion about branch naming and deployment practices :)
Publishing the repository URL and/or deployed branch/tag/revision might also be awesome, but it serves a different albeit overlapping set of goals.
I consider myself both a non-designer and a non-programmer. I'm able to do basic things in Photoshop, and if i was really determined, i could probably replicate a decent design from somewhere else, but it would take some conscious effort. Similarly, I dont consider myself a programmer, but i can read javascript code, and i've done a little bit of programming here and there but never completed a full web app journey from start to finish as part of a team, or even on my own.
I finally took the leap a few months ago, and have started out on my own app. The thing that i have found most in my journey is that there seems to be a wealth of information out there for newbies - such as the htmlcss book or the w3schools site - and a wealth of information for people at a more advanced level - though i've noticed conversation between experienced devs is what is helping them. There doesnt however, seem to be much targeted at the intermediate level of developers that kind of get wedged in between a rock and a hard place (like me).
Take git or mercurial for example. Lots of information explaining what git is, what the advantages of dvcs are. Also plenty of tips and tricks and cheat sheets for someone already using dvcs, but nothing at someone that's understood the basics but wants to go up a level.
People like me are desperately trying to get to the next level in both design and development.
So i beg all of you that are at a more advanced level and have been doing design or dev for a considerable length of time, to please think about us intermediate people; us non-designers and non-programmers that want to create something great and have finally plucked up the courage to have a go. Help us out. Please.
I'm not saying that many of us, won't still try even if you dont reach out to us. The best way to learn, of course is just to dive in and keep cracking on at it, but if you guys were to think about us, it would make our lives just that little bit easier and more rewarding.
This intermediate level doesn't exist. Once you understand the basics, look to see what else is possible and then read up individually until you get a more thorough understanding. For example with git:
For some reason, whenever I've used mozilla's site, it has a horrible response time. Whether this is due to extreme load or just a crappy server, half the time I quit after waiting 20 seconds for a page to load (my normal wait time is less than 5 seconds).
W3Schools is still an OK reference site. I haven't really looked at their tutorials.
I think this is even more important for Javascript files. So many times I'll look at something to learn and find it's minified, which makes it a lot harder, there are tools to deminify but obviously a lot of semantic information is lost and then I can't step through etc.
I fail to see that as a problem. Source code for programs have nearly always been compiled and often obfuscated so why should Javascript be treated any differently?
Not a bad idea, though I'd just avoide the .max all together. Perhaps I'm missing the point and/or assuming everyone already does this, but I always make my .min.css files from .css (eg foo.css becomes foo.min.css).
Better yet, just allow directory indexes on /js and /css, showing the smaller files that the minified one is built from. You can do this, and also minify them using a Makefile.
In this thread I ended up proposing something very much like what Dan is saying here but realized (after Kevin Dangoor, product manager of Firefox's Developer Tools, chimed in) that indeed source maps were designed exactly for this situation, no authoring convention or filename guessing necessary.
Source maps not only can point to the original sources, but can translate between minified css and fully formatted Sass with comments, and developer tools can identify the mapping.
As for how ready this is, CSS source map plumbing is in both Firefox and WebKit, though they are not totally complete. I believe FF has a Google Summer of Code student working on the feature: https://wiki.mozilla.org/DevTools/Features/CSSSourceMap
While the idea seems decent, it completely forgets about CSS preprocessors (LESS/SASS). When using one, the original 'source' stylesheets usually don't even make it into deployment server, for they are just used to build final CSS. Even if not minified, that CSS file would likely be pretty unreadable, not to mention that it wouldn't really reflect the original patterns and ideas used in source files.
This takes out any or all learning curve for beginners. If we did this it would disrupt the web development industry, think of it like natural selection. Half of why web developers are so great is their resourceful. I just see this as a terrible way to teach people to copy and paste. Creating myspace all over again
Call me crazy, but why would you waste a user's bandwidth on this? Also, usually, there is a foo.css, next to a foo.min.css, why introduce a new paradigm?
on top of that, there's right click on an element -> inspect, and it will tell you all you need to know, in any proper browser.
There really isn't a need to do it in the manner that was suggested. If a frontend developer wanted to provide a copy with comments, it's better to host it on github & comment the link in the css file.
At the end of the day, I'm not writing my CSS for others to learn from outside of the // hidden comments for my devs that don't get compiled in the final CSS. There are tools out there to reverse engineer/un-minify CSS and JS files if they are so intrigued, and if they want to learn the best way for them to do so is to get down and dirty the same way the rest of us did and just learn what works and how it works outright. Having the Inspectors already gives them a leg up over a lot of us.
I would say Firebug or Inspector is a better tool for poking around in CSS than trying to look at a raw stylesheet. There are hidden settings that you'll never see otherwise (that don't get used much, admittedly) and it gives you the ability to make a change and see how it affects the current page.
The CSS you see in those tools is real decompressed CSS (organized a bit better than most stylesheets) and is pretty much exactly what you'd put in a stylesheet.
As I've been playing with SASS I had decided that I would place the resulting scss file in with the actual css file. My reasoning being very close to what the article states; my css file is compressed and comments stripped, the scss file is not. Granted, I would probably have to put a link to the file somewhere but it would be nice if this somehow became a thing people just did.
Beyond Firefug and Inspector, there are also CSS prettifier tools out there like the excellent http://procssor.com/process. That's about the best you can hope to do, unless you are expecting developers to put extra educational content in their maxified CSS files. Which ain't gonna happen!
Hi all. Thanks for your comments on this. I've addressed a few of the misunderstandings and concerns raised here on HN, Twitter et al over on my blog: http://daneden.me/2012/07/max-css-in-depth/
This almost seems like a browser problem for me, rather than a problem that developers should solve.
If you use Firebug or the equivalent across the browsers it's very easy to see the "maximised" CSS, but surely a setting to do this when viewing the CSS would be a good thing?
