After browsing css templates in html5up.net, I am really curious as to how design sites/companies produce all their templates. With the amount they churn out, they would surely have to have some sort of efficient system. At first I was thinking that experienced designers might have a combination of coding by hand and copy/pasting large chunks from old templates to new ones. Basing new templates loosely off another in this way would yield some sort of speedy production... Then I thought, with how well organized the front end files are, they can't be coded by hand (or at least not most of it) - it would make sense that they are made from programming that generate the templates, sort of like a template for building templates. I would only go so far as to speculate the possibility, but I would like to know how a person churn out the templates like that. If this isn't the case, is it feasible?
This can be accomplished with preprocessed CSS.
At the simplest level, these languages/frameworks can be viewed as allowing substantial amounts of CSS to be output by making changes to core template files- through the use of variables, mixins, nesting and formulaic derivation / inline functions. Once the templates are set up, something like, say a site colour change, can be accomplished by only changing one or two variables.
You may want to look at SASS (wiki, article)
Sass is a scripting language that is interpreted into Cascading Style
Sheets (CSS). SassScript is the scripting language itself. Sass
consists of two syntaxes. The original syntax, called "the indented
syntax" uses a syntax similar to Haml. It uses indentation to
separate code blocks and newline characters to separate rules. The
newer syntax, "SCSS", uses block formatting like that of CSS. It uses
braces to denote code blocks and semicolons to separate lines within a
block. The indented syntax and SCSS files are traditionally given the
extensions .sass and .scss respectively.
There's also LESS (wiki) which works in a similar way.
LESS (Leaner CSS) is a dynamic stylesheet language designed by Alexis
Sellier. It is influenced by Sass and has influenced the newer "SCSS"
syntax of Sass, which adapted its CSS-like block formatting syntax.
LESS is open-source. Its first version was written in Ruby, however in
the later versions, use of Ruby has been deprecated and replaced by
JavaScript. The indented syntax of LESS is a nested metalanguage, as
valid CSS is valid LESS code with the same semantics. LESS provides
the following mechanisms: variables, nesting, mixins, operators and
functions; the main difference between LESS and other CSS precompilers
being that LESS allows real-time compilation via LESS.js by the
browser. LESS can run on the client-side and server-side, or
can be compiled into plain CSS.
Finally there's stylus (wiki)
Stylus is a dynamic stylesheet language designed influenced by Sass
and LESS. It's regarded as the third most used CSS preprocessor
syntax.
Related
I am a pure designer, so I totally new to the field of front-end development.
I have learned what is LESS, what is SASS.
But when I open a HTML template, there are some LESS or SCSS files, but also a lot of CSS files. I am quite confused what's the relationship between LESS/SCSS and CSS?
If LESS/SCSS is so good to use why people still write 10 thousand lines in CSS file, which is impossible for me to read through..?
Are those CSS files like "bootstrap.css" or "animate.min.css" just libraries for LESS/SCSS to use? Or what other relationship between them?
A lot of frameworks ship with not only the LESS and SASS files, but also the results of those files (the exported CSS files). In the case of Bootstrap, this is particularly true: none of the ".css" files are libraries for the LESS. They are the result.
The authors of these frameworks assume that some people want the LESS/SASS workflow, and others want to include the CSS and be done with it. So they include it all. In many cases, the ill-documented sprawling CSS files are actually demonstrating that the assumption about LESS ("so good to use") is not always true. Writing CSS without a preprocessor and with best practices will more often result in a smaller more readable (and well-documented) file than a LESS/SASS-based workflow.
Having spent some time with LESS, I think I might be ready to move back to straight-up CSS.
I've been trying to figure this one out for a while, is there an type of image or url embedding for CSS or its language derivatives (SASS, LESS etc) that do not use this specific syntax?
url:(foo.png) # with or without quotation
I know that SASS can and does use
asset-url('foo.png', image);
but I am counting this as a match (due to my regular expression formula that this is for)
Specific things that I am looking for would be for instance how HTML handles urls with both href and src, though this is unrelated I would like to use it as an example due to the fact that it utilizes urls in different ways. Thanks for taking a minute to quiz over this one =)
CSS can only reference images by the url() function (even embedded image data is a data url). However, compile to CSS languages like LESS and SASS, are far less straight forward...
asset-url() is not a SASS native function. It's provided by the sass-rails gem, and so only available in the context of a rails application. So asset-url() is a custom function that is provided by a library. And you can even write your own function that abstract away calls to url() behind your own custom mixins.
If you want to find all image URLs referenced in some CSS, they only reliable way to do it is to compile it to CSS and then search through that, because that's the only way you can know for sure. And as a bonus, this approach will work for other CSS preprocessors that you havent written a scanner for, because all you care about is CSS.
I have an existing Django project which uses regular CSS. The style sheets are broken up by functionality, so there is a nav.css, course.css, default.css, reset.css, etc. All of these are imported in a main.css, which is referenced from the html pages.
I would like to use Compass in this project so I can make the style sheets more manageable and also make it easy to skin the UI.
Before checking out Compass, I looked into Sass, and created .scss files for all my style sheets.
Now I realize that it may be better to use Compass than just Sass, because I will get all the default styles that come with it. However, I am a bit confused about how to start the refactoring process.
What would be the right process to refactor (in baby steps) an existing project which already has its styles defined, to get it to use Compass?
Much of the refactoring work is the same with or without Compass and you'll see the benefits that Sass offers sooner than those of Compass.
Compass creator Chris Eppstein did a write-up of how he went about refactoring digg's CSS. To sum up:
Extract partials. You're well on your way with this one, since you already have separate stylesheets for different functionality. Go further and pull out independent sets of rules to make them easier to manage and break down the refactoring project into smaller steps.
Analyze styles. Look for repeating patterns and inheritance relationships in your new partials. Wherever you have selector duplication could be a good place to start the next step.
Extract base classes. This is where you DRY up your CSS with #extend. Pull out duplicated declarations into a base class and extend.
Apply nesting. Nesting is a great Sass feature to make your stylesheets easier to read.
Extract mixin. If you found common styling patterns in step 2, this is the time to extract them into mixins.
Now you can really start taking advantage of Compass and its reusable patterns. Familiarity with the Compass documentation will help to identify which of the mixins are applicable to your project.
Hey, I'm developing a GWT app and now facing the CSS part. I read a lot about this topic at the official site but still have a few questions and hope someone can give me a hint.
When I'm using CSSResource the css styles will be compiled into the code - right? So it's not possible to change it without recompile the app. But what I wanna do is to have the styles be editable from "outside".
So what is this CSSResource for, since you can't just change a color or an image without compiling the app again?
Whats the best way to use CSS since there are a few ways (.css file, CSSResource, styles in ui.xml) to do this?
My thoughts are now, that I'm using only the normal CSS file to handle all my "changeable" stuff and add this file to the head, since I can't see the advantage of this CSSResource thing. Hopefully someone can help me with that. Thanks.
It all depends on the way you work with CSSes - if you need to apply some small changes, first test them "live", in Firebug/similar tool. During the designing phase (when you don't have a finalized view of how you want to style your application yet), you might want to work with normal CSS files, but as soon as the general style clarifies, you should switch to ClientBundle/CssResource.
Why? Let me answer, by writing up some thought about the goals listed on CssResource's documentation page:
Primary
Compatibility with non-GWT-aware CSS parsers (i.e. any extensions should be valid CSS syntax)
This does not imply that the stylesheet would necessarily make sense if you just displayed it in a browser - meaning, we want to only use valid CSS syntax, not some syntactic sugar that's gibberish to other parsers - might not be that important from your point of view (although, as a result, you don't need to change the syntax of your existing styles)
Syntax validation - very important point, IMHO. You get stuff like checking for missing (possibly misspelled) CSS classes, syntax errors, etc. - something that had to be (usually, painfully) tracked down via some browser specific developer tool (Firebug). Here, you get those errors early, during compile time (or even faster, with the help of the Google Eclipse Plugin).
Minification - this is not your run-of-the-mill minification, you get also selector and property merging. See the next point too.
Leverage GWT compiler - if a CSS class is not used (the GWT Compiler can make such a distinction, since it has the overview of the whole application), it is pruned and not included in the compiled code. How many times have you found CSS classes that were left there after some design changes? This takes care of that (see also the CSS modularization point)
Different CSS for different browsers, automatically - since the CSS generated this way is included with your JS code, it can (and is) optimized for the target browser - no need to include lengthy IE hacks in every permutation!
Static evaluation of content - already mentioned it before
Secondary
Basic CSS Modularization
Via dependency-injection API style - you can inject CssResources as needed (for example, to facilitate custom themes in your application)
Widgets can inject their own CSS only when it's needed - this is one of my favorite points, although at first I didn't see its significance - you divide your (usually) huge, monolithic CSS file into small modules, one for each Widget that uses UiBinder (which in turn uses CssResource internally) plus probably one global CssResource for application-wide styles. This results in a much cleaner, easier to maintain CSS styles (at least, in my experience). This also means, that if your code doesn't use that particular Widget (maybe because you've used ocde splitting and it hasn't been loaded yet), you won't download those styles.
BiDi (Janus-style?) - bidirectional text support, haven't used it but the docs look promising :)
CSS image strips - automagical image sprites generation - what more can I say? ;)
"Improve CSS"
Constants - I've always missed this feature in the CSS specification - when you change your primary colour, you have to find & replace it in the whole file (possibly leading to some errors, where you want to use the old colour in some places) - this makes it more intuitive, IMHO, by introducing constants (via valid CSS syntax and without any runtime penalty)
Simple expressions - you should skim through the docs to see the possibilities there, really cool stuff
Tertiary
Runtime manipulation (StyleElement.setEnabled() handles many cases) - on stylesheet injection (during runtime), some values are evaluated - this allows for skinning, etc.
Compile-time class-name checking (Java/CSS) - already mentioned the (obvious) benefits of this
Obfuscation - this one is really cool too, the GWT Compiler can safely obfuscate all the styles in CssResources, because it has the overview of the whole application - thus, name clashes are impossible. This means that you can use long (but not too long ;)), meaningful class names, without worrying how that will impact the size of the application - it will all get obfuscated to nifty, short (even 1-2 character long), random strings. This also enables you to define a .warning style in two Widgets and the compiler will understand that these two styles are in different namespaces (different Widgets) and thus should be treated differently (that is, obfuscated to different names).
About style injection
The class StyleInjector allows injecting styles at runtime. Additionally, the CssResource allows (at least according to the docs, I haven't tried it yet) for runtime substitution. For example, when you inject a CssResource containing the following:
#eval userBackground com.module.UserPreferences.getUserBackground();
div {
background: userBackground;
}
The userBackground will get evaluated and injected (as opposed to constants, which are resolved at runtime).
I am attempting to use lesscss to build a templating system where each template has 3 or 4 alternative colour schemes.
So for example, I could have a red.less stylesheet that looks like this:
#main_colour: #ff0000;
#import 'main.less';
So, I only have one main.less stylesheet to maintain which contains all the main styles, and uses the variables set for colour codes. I can then create a seperate colour.less file for each colour scheme.
Only problem is when I try to do this I get a Less::VariableNameError which indicates that LESS is parsing the #imports BEFORE it parses the variables.
Is there a workaround to this or any other way to achieve the same end result?
In reference to your tweet, yes, this would work as you expect in Sass. I'm actually kind of surprised that it doesn't work in Less.
I guess the Less guys wanted to keep the .Less file atomic and independent of external environmental settings. This was what I assumed, but I also didn't like it so our .NET port http://www.dotlesscss.com will allow you to do this by default.
Its not a big change to do in the original Less ruby version and if you fancy tinkering with the source I can point you in the right direction.
Out of interest, without been traitorous to the Less team I quite like the SASS syntax now and there are additional things such as conditional statements and loops that you cant (yet) do with Less.
#nex3 - you guys should stop competing and just work together.
Seems like this isn't a problem any more, or at least not for me using "dotless" for .net?
Seems to work fine now with latest LESS.