This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why do /**/ comments work in stylesheets but // comments don't?
In CSS there is only one way to create comments: /* I'm a comment */
The problem is that it isn't nestable.
Why don't we have an alternative comment syntax like //?
I think the real answer is that CSS treats newlines like any other whitespace, so it wouldn't make sense to have comments that are terminated by a newline. This is from the CSS1 spec: http://www.w3.org/TR/REC-CSS1
A CSS style sheet, for any version of CSS, consists of a list of statements. There are two kinds of statements: at-rules and rulesets. There may be whitespace (spaces, tabs, newlines) around the statements.
Of course, this also makes a lot of sense in the context of minification, as mentioned here: Why do /**/ comments work in stylesheets but // comments don't?.
It's not in the specification, and because CSS is widely used and supported, adding it in is virtually impossible. You can't just publish a new specification and expect all browsers to magically support it.
Internet Explorer 6, a browser more than 10 years old, is still widely used, so you can safely assume that even if this addition to the specification were made, it'd take another 10 years to be supported enough to bother. The problem with //-style comments is that they don't scale - unlike new HTML tags, which can be safely ignored as long as the rest of the document makes sense, adding a //-comment will break unaware user agents.
So the short answer is, we don't have it because we don't.
If it really means that much to you, write a script or macro that converts //-comments into /* */-comments, and apply it before running your web application.
There is a way to have // comments in CSS. If you use Sass/Compass.
I really like using Compass, because it gives me everything I miss about CSS, like functions, variables and so on...
Here is the Compass home page and the underlying Sass-language.
Compass is very nice, because you just have a program running in the background that compiles your Sass-code into real CSS, so your workflow is exactly as normal, but in other files (SCSS or Sass) and with very extended functionality!
Related
I very frequently use the CSS line numbers in Inspect Element to find where a rule is in a particular CSS file. When Sass outputs a CSS file, it imposes its own style rules on it which really don't line up 1:1 with how my SCSS is formatted. This makes it hard to find CSS rules in my code because none of the line numbers match. It's completely disturbing my workflow and is a major barrier to my further adoption of Sass.
I've already looked at sass --style=expanded and sass --style=compressed but neither of them come anywhere close to matching the whitespace style I want.
What I really need is a way to make Dart leave all my whitespace and line breaks exactly as they are, and minify mixins down to a single line each. Something you might call --style=preserve-line-numbers Is it possible?
No. That is not possible by SASS itself.
If you like you may have a look to the avaiable styles:
https://sass-lang.com/documentation/js-api#outputstyle
But to be honest: if you use SASS in the intended way with nested styles, mixins, using modules ... the compiled CSS will considerably differ from the SASS code anyway. That even applys to the line numbers. So your problem is a common challenge in the coding process.
As fast debugging is important SASS offers mapping technique:
If activated you are able to see the source code in the browser on the fly. That's really easy and should meet your demands. Maybe you like to have a look on it. Here is a good overview to it: https://thesassway.com/using-source-maps-with-sass-3-3/
Or however if not that way there is another little trick/workarround which may help:
Most SASS projects organize/structures code in partial files (which doesn't make it possible to keep line numbers). That's for different reasons and speeds up working as well. If you do so you just start every file with a CSS comment which notes the file name only. As comments are shown in the browser tools you are able to find the relevant SASS source file without mapping ... and as partial files are almost not as long finding the relevant code (which differs from the CSS) should not longer be the problem.
// ### examples partial filename in a CSS comment
/* base-typography */
...
/* base-forms */
...
/* section-hero */
...
That is not as fast as mapping technique I would really recommend. But finding the code that way is faster than try to keep line numbers exactly the same and missing that way a lot of other advantages of SASS which speeds up my work (like nestings, setting SASS only comments, using mixins and modules ...).
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to Manage CSS Explosion
I intended to build my web site with consistent styles and a coherent CSS scheme. But styles have crept out of control as I fine-tune individual pages (especially the main search form).
I've already gone through the process one time of breaking down the styles and rebuilding almost from scratch, and now it looks like time to do that again. How can I be efficient about this? I'm looking for a methodology, not a software utility (though I'm open to suggestions there...unless they cost money...).
Added note: I'm using a CSS framework and it's difficult to keep padding and margin coordinated.
Added note 2: The initial responses to this post are about best practices for CSS. Let's assume I already tried to follow best practices (in fact, I did). Now it's the clean-up procedure I'm looking for.
Added note 3: As of 14 June, combining this response (which I just found) with my post below is possibly a comprehensive answer.
Closure notes:
I learned my question is too general, and for that reason I wish I hadn't posted it. (Maybe that's why it got a down-vote ... I'll never know without a comment to explain the reason.) On the other hand I got just what I needed, so I'm happy I did post it.
I'm surprised I didn't get an up-vote for my answer -- even with the priceless input by others, I think it stands up pretty well.
My acceptance is going to be based largely on the usability of the answer, from my point of view -- a point of view that is sadly unable to digest some of the more exciting and comprehensive responses.
Closed as an Exact Duplicate
I just tried posting this again (subject, body, tags) to see if SO would suggest the post "How to Manage CSS Explosion". Interestingly, it did not. I added the tag refactoring to that post.
Split your css into separate files.
Put in one file the CSS reset (if you use one)
Then create a global.css file where you will put global styles that
apply to many-all pages
Then create individual files for your individual pages
Then start styling your pages. Every time you find a style rule that is reusable on many pages make it a CSS class and put it in the global.css file. Avoid using css ID's. You will find that you more often reuse things or will reuse in the future. In this case you use of course CSS classes.
Eventually you will find out that in your global.css you will find mostly CSS classes rules and html tag rules.
In your individual page CSS files you will find specific styles for each page.
That should give you a good first level of organization in your CSS. You can try to keep this separation through the whole development process, and for releases merge the CSS files into one and minify it.
my 2p worth about css cleanup, from a a previous similar question:
Tips for cleaning and maintaining a big css file
hope that this may help you together with others' answers!
start branching the project (here I suppose that you are using a version control tool) - that will allow you to play independently with the code and tag any milestone you will reach.
format your CSS with a beautifier - it will increase readability and will help searching for specific declarations without missing any instances.
try to identify unused / redundant css and get rid of it.
you could try to make your selectors shorter (e.g. .main .foo .bar might be fine as .bar) - it will improve readability and increase the performance, but take this with a pinch of salt and be ready to go back if things start to break at every step you take.
try to eliminate, if possible, any !important - make the selector more specific if needed. A css reset could help with that if most of the !important statements were made to fix browser-specific issues, otherwise introducing a css reset now could potentially add more problems than solve them - this, if there is no css reset in your app at all.
break and regroup the css into different modules (and files if that helps) - Object Oriented CSS is a possible technique to keep things more maintainable, it works best if you start with it but it may also help you in refactoring. https://github.com/stubbornella/oocss/wiki is a valid one but there are alternatives that you can consider, like SMACSS.
After that , you may consider using a css preprocessor such as Less or Sass, allowing you to define variables and mixins (similar to functions), modularity and much more - this may end up being a very expensive task though, so evaluate carefully if this will bring you more benefits than pain.
test as much and as often as you can, consider unit tests to make sure that any changes you make don't break anything somewhere else.
Sometimes re-writing everything may end to be less time consuming than refactoring, so don't be afraid to leave things as they are if your assessment will show that refactoring will not bring enough benefits.
EDIT
Things change and evolve for good; with regards to OOCSS/SMACSS approach, I have been happily following for a while, Yandex's BEM methodology for CSS, I would like to add it as an additional recommendation to the above
The first thing I'll do is separate the CSS based on the purpose. Maybe first the general page layout (DIVs, boxes, ...), then the styling (fonts, H1/H2/.../Hn titles), then some more specialized CSS (CSS for tables, for forms, for specific components of the site).
Such a separation helps to organize the changes; if you have to change or add a font, you know you'll find it in the styling section.
If you have to change the page layout, there goes the same, and so on.
Things tend to get messy when you have "individual pages"; is their layout so different?
You probably have to abstract the common features of the pages (for example, a main content container box) as long as you can.
Then think about specializing more the layout (1-column, 2-column) and so on.
If you have a programmer background, just think about classes and inheritance, the concept - yes I know it's a totally different domain... - but the concept can be useful in designing your css.
Based on this current round of work, here is what I've got so far:
the Planning
Have a system for handling To-Do notations in your HTML and CSS. Many IDEs support this directly, or a global search function will do just fine. Besides tagging issues, you want to note priority and perhaps even functional area (but keep it simple, not a burden).
Don't start revising your code. Use your To-Do system to plan first.
Make a concise list of your overall goals.
Consider overall sylistic changes such as color or font scheme.
Review best practices for CSS. Identify areas where your approach is ineffective, or where a good approach can be applied more consistently. Examples:
Consolidate classes
Eliminate haphazard use of in-line styles
Remove styles that are unused or redundant or conflicting
Improve general consistency; apply a set of conventions
Improve units of measure
Use class and id names that reflect content rather than format
Decide how much of the browser market you want to support and how much to embrace or rely on the newest standards.
Decide if there are any new approaches you want to adopt. Examples:
Use of a reset style sheet to standardize browser presentation
Use of a CSS framework
Use of a specialized library, for example to help with forms
Dynamic CSS (I recently followed advice to use PHP to handle my CSS, so I could dynamically control my color scheme. But I returned to straight CSS, because I like the presentation of CSS code in my IDE and the hybrid method messed that up.)
Review your list of goals and decide which should be pursued now. Any large-scale change should be treated as separate, if possible. If your column layout is a mess, it's not the time to learn how CSS can elegantly replace your javascript. The same goes for best practices, stylistic changes, etc.
If you have your CSS files configured for speed (for example, compacted footprint or all CSS in a single file), change that. Break the code into a human-managable format. Later when you're finished, try benchmarking to see if the more legible version is also efficient enough for production use.
Submit your CSS to a validator. Note any violations you want to fix.
Find instances of in-line styles in your HTML (search for the style attribute). Note any that should be moved to a style sheet.
the Work
Follow your To Do manager. Make common-sense back-ups. As you go, test your work on several browsers.
If you are into regular expressions, be warned: regex is often not effective or safe for rewriting CSS. (Not as hazardous as for HTML, but still). Regex may be useful sending CSS changes into the HTML, but again be careful.
If you have a lot of tweaks to margins and padding, try globally resetting all of them to 0px (okay, use regex here). Then systematically build them back up. You can resolve a lot of confusions this way. Of course, don't include any library or framework style sheets in this process.
Again, submit your CSS to a validator.
I see people has already suggested using approaches like OOCSS etc., so I'm going to offer a different/additional line of thought. I believe that the problem lie deeper than within your CSS and the way you write it. I believe the reason your CSS gets out of hand is this quote from your question:
... as I fine-tune individual pages ...
That makes me think that the problem much lie within your design, rather than you CSS, so let me elaborate a little bit on that. In my opinion a great design is a design that doesn't have to be customized for each individual page - and there are several reasons for that. The main reason is, as you've mentioned yourself, your CSS get out of control. Small tweaks and fixes on individual elements, depending on where they are placed, often leads to a mess that is a pain to maintain and work with. There is also a usability-reason in play here. I believe a UI becomes easier to use if the user is familiar with the UI and recognize herself from page to page, without to much variation. Of course you could have some element that isn't present on each page, or that vary somewhat between pages, but I always strive to keep them at a minimum.
My suggestion is therefor that if you intend to rewrite your CSS, which is time-consuming and hard work anyway, then why not go over and re-evaluate your design at the same time. You will probably find that there are elements that you can modify so that they look the same. Make it a goal to get rid of as many UI-elements as possible, without compromising the design. When you've unified the design as much as possible, then it is time to refactor your CSS, and maybe even your markup?
At this point, it might be better to get rid of all your CSS and start fresh. If you continue on your old code, it is easy to get lazy and get stuck with some of your old less efficient code.
For the coding, I believe the other answers contain lots of good recommendations and best practices. I would personally vote for OOCSS, a new discovery for myself as well, but it has improved the way I structure my CSS a lot. So have a look at that! That will also help you think in terms of reusing elements and the CSS for them, which goes a long way for simplyfing your CSS.
This answer is in regard to the note;
"I'm using a CSS framework and it's difficult to keep padding and margin coordinated." only.
Using a css pre-processor will solve this problem.
Because css has no way to assign inheritance and therefore we have to repeat 'margin:10px' over and over.
with a pre-processor you just do
#margin {10px}
#padding {10px}
then
.mySelector{
margin: #margin;
padding: #padding;
}
For the broader question rethink/simplify your design as your css is directly proportional to the complexity of the design and there is not much you can do about that.
See also, http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/
This is more advice about making your css maintainable than the Q of how to manage the process.
I create a bunch of separate css files each narrowly tailored to a specific attribute (colors, fonts, margins, corners) or feature (nav, form). Then I use a compile phase to combine and minify these files into one or more files to be sent to the client. I do this during my built/test process, but it could be done dynamically by a CGI script.
Before adopting a pre-compiler, consider the often-overlooked multiple-selector syntax:
element,
otherlement
{
margin:10px;
}
In this example, whenever I want an element to have a 10px margin, I add it to the list. I separate different sets of attributes this way - I may list the same element 5 times in my css - associating it with 5 different sets of attributes.
Also don't overlook adding various classes to the body tag to create OO-like inheritance - say you have 3 main sections of your site - assign the body tag a class based on those sections. Likewise, if you have 1000 product pages, you can give the body tag a class like "product485" and then create styles that apply just to that page. For example:
h1 {
margin: 10px;
}
.product485 h1,
.product484 h1
{
margin: 5px;
}
.contact h1 {
margin: 15px;
}
This might all be in a file called "margins.css" which specifies only margins.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
everyone — I was looking over a recent presentation on 960 Grid System, Refresh OKC – April 19th 2011, and on the penultimate slide (101/102), the guy recommends "if you're going to use Sass, use Sass, not SCSS." Given that SCSS is the new main syntax, why prefer Sass to SCSS? Is it simply a preference for conciseness over similarity to CSS, or is there a real reason for using Sass, not SCSS?
I can't think of a good reason :)
I looked at the whole set of slides, I think the presenter (who is also a connected to the SASS project, I think anyway?) is of the mindset to use what you know to "get 'er done"
Sass is supposedly shorter and more concise and it's possible that the speaker knows Sass inside out, but speaking from personal experience having read and written CSS for over 10 years I find SCSS much more intuitive. I do not have to learn the Sass indentation rules, and the brackets in SCSS and CSS provide visual indentation clues for nesting - which is very like most every other language uses, so anyone from a programming/coding background would be familiar with the idea of closing the nests??
.. more importantly every valid CSS is already a valid SCSS so no conversion needed to start using it - e.g. I was able to take my Drupal sheets (all 29 of them!), change their extension and recompile/compress them in very little time.. since then I've been able to take a little chunk at a time and "Sassify" it, using nesting etc. and I still like to see the brackets and semi-colons, it matters not, which you use once it's all compiled anyway!
IMHO Sass itself is too high a barrier to entry for a large project (existing one, i.e. one not built/sassified from scratch), where as it can be modularised with SCSS
So to follow the original author's (of the slideshow) thinking rather than debate pro's and cons I'll just keep using the one I know TYVM :)
I believe that the bracketed .scss syntax is currently the default only because it is more familiar to newbies who switch to SASS from LESS and vanilla CSS.
The indented .sass syntax was the first in SASS, being identical to (and making an ultimate team with) HAML. The new bracketed .scss syntax is similar to LESS, a competitor of SASS, both SASS and LESS make it possible to convert from CSS just by renaming.
The indented .sass syntax has only one drawback: it does not allow splitting function/mixin arguments into multiple lines. That can make the code harder to read (example).
In practice, this problem is rare and might be an indication that the code is poorly designed and requires refactoring.
The only yet decisive advantage of the indented .sass syntax is that it is much cleaner and easier to comprehend, while being equally expressive and powerful.
I have created an animation for you to consider the difference:
Also, didn't you hate it every time when your code failed to work/compile due to a semicolon missing (and maybe the interpreter/compiler producing a misleading error message)?
Basically, the indented .sass syntax just removes bloats of visual noise.
Of course, it requires some time to get used to it. At first it looks alien to anyone who has some experience with CSS or LESS. But once you get accustomized a bit, you'll find yourself feeling distaste to the bracketed syntax of CSS/LESS/SCSS and JavaScript and preferring the clean syntax of SASS, HAML, CoffeeScript and Python/Ruby.
Pros:
It's cleaner. Less visual noise. More elegant.
Cons:
The big one: Can't use newline. This is the only thing that I don't like about SASS. See example below.
The rest: Higher barrier to entry for people who struggle with the apparently difficult concept of indentation.
In SASS you are forced to stick to lines. So if you have
#function -create-gradient-from-color($bgcolor:#000,$depth:6%)
...code...
then you can't do this, which i find much cleaner
#function -create-gradient-from-color(
$bgcolor: #000,
$depth: 6%
)
...code...
That will throw an error because of the newlines.
But you can do that in SCSS, since it doesn't care about newlines
#function -create-gradient-from-color(
$bgcolor: #000,
$depth: 6%
) {
...code...
}
So I find myself keeping things terse in optional argument strings to prevent this situation.
I find SASS much faster to type.
SASS and SCSS both are a huge add-on to CSS - so different that I don't want to confuse them with standard CSS.
It's not hard to learn SASS - lose the brackets, and use tabs to decide nesting.
This question already has answers here:
Detecting IE version using CSS Capability/Feature Detection
(18 answers)
Closed 5 months ago.
So in my interweb travels of evaluating other programmer's CSS I've noticed a bunch of people using the underscore or asterisk hack that is vendor specific to IE browsers for debugging purposes though W3C does not parse this as valid CSS.
I personally prefer comment conditionals where you can at least defer to IE specific CSS that is valid but I guess the only issue with that would be addition of extra CSS.
So I'm curious about a consensus of what you prefer and the positive or negative implications of each method.
Comment conditonals or IE vendor specific hacks?
PS - Honestly this should be titled do you support IE layout or not :-)
Conditional style sheets are the way to go. The word hack itself implies that you're doing something that you shouldn't. But a few short words on both:
Conditional style sheets
(+) Cleaner CSS code
(+) Easier to manage
(+)Easiey to understand for other developers
(+) CSS validates
(-)More CSS files (thus more server load)
Hacks
(+) Faster (possibly)
(-) Messes up your CSS
(-) CSS doesn't validate
(-) Very unclear for other developers (especially non-experienced one's)
(-) Could cause problems with newer versions of IE
I prefer the conditional comments, because it makes your page still validate. I could imagine, however, that you use the vendor hacks, because you won't need an extra css file, saving a request per page loaded (if not for caching, of course). Then again, the css files are cached, and if you use your conditionals wisely, you can make a separate file per IE version, copying hacks if they are needed for more than one version. That way, you need at most one extra css per page, which is then cached as well, thus minimizing the extra load.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Are there any good CSS coding style/standards?
Here is a good one:
http://www.phpied.com/css-coding-conventions/
But the important thing is to pick something and stick with it for consistency.
I agree with most of the points at Andrew Hare's link, but I strongly believe
.class-name {
color: green;
}
is inferior to:
.class-name
{
color: green;
}
on the grounds that:
.class-name, .class-name2 {
color: green;
}
or:
.class-name,
.class-name2 {
color: green;
}
are considerably less obvious to grep or read than:
.class-name,
.class-name2
{
color: green;
}
There's no standard standard, as it were. There are most certainly plenty of in-house standards and conventions. And there are certainly known best practices.
I stick to the following:
Structure your CSS according to it's purpose
That may involve separating out CSS concerns into different files (layout.css, colors.css etc). This may just as well involve clearly dividing up a single CSS file into clear sections along the same lines.
Be as specific as possible
Selectors have differing weights. ID-based selectors are more specific than class-based selectors. Chained selectors (e.g. body div#container div#content p) are very specific indeed.
Start out being as specific as you can, even if it appears you're being too specific. It's quite easy, later down the line, to merge together two very specific style definitions by removing one and making the other less specific.
A style definition with loose specificity may target elements you did not intend in ways that are not immediately apparent or obvious. I think this is the most common cause of CSS frustrations ("Why on earth will this div not let me set a top margin?")
Always specify every single style you wish to apply for a given defintion
For example, if you want all your paragraphs to have pink text, set the text colour to pink and also set the margins/padding/background colour/font and so on.
Don't rely on browser defaults to be suitably consistent. Certainly for the most commonly used elements the main browsers tend to use very similar if not identical default styling.
If you set all the relevant styles yourself you know what the end result should be.
If you only set those styles that are most immediately obvious, the end result will be (most likely) a combination of the browser defaults and your styles. This will eventually catch you out at some point. I think this is the second most common cause of CSS frustrations.
Use ids for styling unique elements
It's generally a good idea to apply an id attribute to any unique element that is going to be interacted with in any way. For CSS this will let you apply suitably specific styles more easily.
Use an id on a unique page
Pages that are significantly different in style and layout to the majority (homepage, search results, 404) should have an id on the body element. This gives you the specificity you need to ensure that your careful homepage styling doesn't get affected by styles you later apply to some internal content page.
Pretty coding style VS site speed
I've been working with pretty huge CSS files, and found out some pretty interesting things that I've never read about before.
#import
One thing is using #import. That's actually a bottleneck - by going away from using #import completely, the site got a lot more snappy.
#every .style { in one line }
When the browser reads a document, it reads line by line, so by switching from my pretty coding style to this, I accomplished 2 things;
A even more snappy site
Less scrolling, better overview. Why? Cause I first scroll down to find the style I'm going to work with, then it's all in the same line and it's not hard to scroll your eyes along the line to find what you're looking for.
The main good coding style is to actually separate css files according to their goals.
See Progressive Enhancement.
That way, whatever coding convention you will choose, you will have consistent and manageable separate css files... easier to debug.
When I code in CSS:
In first part I write the class and id
In last part I write the general element (p, font, etc) because the class and id have more importance for inheritance
I write comment if I want a particular behaviour with IE or with MoSE Browser
You can see some example in CSS Zen Garden
Generally I insert the most important elements over the other: if there's
p.important{/*features of a class*/}
p {/*features of a general element */}
Reading the CSS file I know the format rules before about the most particular elements, after the rules about the most general elements.
It's an habit in programming Java.
Put your css rules (ex: "color: red;") in alphabetical order and also put your selectors (ex: "div { color: red; }") in order they appear in your markup. Separate code for structure from skin.
Just from experience I used to write quite long CSS style sheets. Now my style sheets typically are half a page.
So keep it simple(KISS), line based (greppable) and keep it compact (use font: instead of font-size etc etc.).
Also I highly recommend using CSSlint to check your code for fluff.
Check Sass out. It's a template language for CSS that makes your source code DRY:er and mucho easy to read. Even if you're not using ruby you can use it for this task and automate the building of your css files from Sass source. And there are probably Sass implementations in other languages too.
There's probably loads. At our work we use the following:
/* =div a comment about my div */
div#mydiv {
border:1px solid #000;
}
The =div allows us to search against all div elements by using the search functionality. There's loads more though, I've used many different variations of this in the past.
In addition to what others said, remember that the C stands for 'Cascading', i.e. subelements inherit from top level elements. Sound simple and straight away. But I have often seen CSS files that contain redundant declarations, e.g. for font styles. This makes a CSS more complex and hard to maintain.
So before you add something to your CSS make sure that it is not redundant, i.e. check parent elements and remove redundant declarations from children.
Given this you should organize your CSS in a way so that high level elements (like declarations for the body class) are mentioned first and more specialized elements last.
This might also be helpful, a few tips to keep your CSS styles DRY - as in "Don't Repeat Yourself" link text
I will strongly recommend looking at Less: http://lesscss.org
While not really a standard, it has been gaining a lot of momentum recently. Less is css extension that runs in the browser bringing variables and functions into the language and therefore allowing templating.