I am building a tool to minify and compile CSS files on-demand. The files can be in different folders, and I need them to be called from their original folder if they are referring to an external file (image, other css, font maybe?).
I wonder which strings I should look for. I only see url( and #import, but am pretty sure I am missing some.
I can think of proprietary CSS: behavior which loads .htc (.js on some servers) for that browser. Also exists as -ms-behavior.
EDIT: oops, behavior will use url() too, not behavior() as I previously wrote... My mistake. Ex:
.ie67 * {
behavior: url('htc/boxsizing.htc');
}
I don't think that filter / -ms-filter can load an external resource; it'll rather apply to images and such (somebody correct me if I'm wrong).
In CSS2.1, external resources are URIs so except #import (that must appear before anything else), I think your list is complete.
Related
I compiling my less files to one css file. But i saw on http://lesscss.org/ that you can include the less file instant on your webpage.
Client-side is the easiest way to get started and good for developing
with Less, but in production, when performance and reliability is
important, we recommend pre-compiling using node.js or one of the many
third party tools available.
To start off, link your .less stylesheets with the rel attribute set
to "stylesheet/less":
Next, download less.js and include it in a tag in
the element of your page:
What is the diffrents between compiling to css or just jusing the less file?
Compiling to CSS
Here compiling means to use a program to turn a .less file into a .css file.
For example, a less file:
.outerDiv {
.innerDiv {
color:green;
}
}
when you use a compiler on it that will generate a css file like:
.outerDiv .innerDiv {
color:green;
}
I use koala. It does not overwrite your file, it just generates a css file alongside it.
All you need to do is reference that css file in your head part, then upload to the server.
Advantages over less.js method
This is lighter (less data for the client to load) than sending over the less file (especially if you minify the css file, which koala will do for you too).
It also makes for faster loading without any "jump" for the user.
If instead you use the less.js method, then:
page loads and renders without your lovely .less styling
less.js then kicks in and restyles your page with you .less rules
If the user is on a slow connection they may see the old unstyled version for a second, then the page will suddenly reformat itself.
I see this html template, and inspect it using Chrome inspection tool.
I'm surprised to know that my browser can detect the scss files instead of the compiled css one.
Then, I push Ctrl+U to view the page source, try to find 'scss' but it gives nothing in result.
So, how does the browser know the scss files?
P.S. I'm new to scss/sass/css pre-processor things
You can read this article for more about Sourcemaps: https://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
This is mainly used for debugging and most of the times is stripted from production environments (in this case I guess they left it for people to check the actual source code and learn as you did :P)
What you are seeing is called Sourcemaps. Sourcemaps allow you to see the original source instead of the compiled CSS. This is usually used for debugging.
By default SASS looks at the filename and determines whether to make a css file out of it. I'm wondering if there is a way to prevent this from happening.
We're building a large website and lots of front-end developers are editing the css, but we only have one dev server. Sure some things you can see happen locally, but often you can only see the real rendered way on the server.
So, when I push my compiled css file to the server, my co-workers' css gets clobbered until s/he commits and I do an svn:update, etc, etc.
However, if we were working in different SASS file, and those css files were getting created, I would only have to push up, say, the forms.css file instead of the whole thing.
Then for Production, we'd put it back to the way SASS normally works.
The only other way I can figure to do this is to do a mass rename of files, which seem very messy.
Thanks in advance.
The entire point of partials is that they don't get compiled into files. If you want a sass file to be turned into a css file, remove the underscore.
Your real problem seems the be that you're putting compiled CSS in your version control. Don't do that. Only commit Sass, and compile it into CSS server-side with a post-receive hook or something.
for html, we have index.html, the file thats automatically loaded by the webserver if no filenames are specified. Is there an equivalent for css, either from the webserver point of view, or just by convention? surely it's not "index.css" right?
Thanks.
Update:
I guess I phrased my question a little poorly. I already knew that css files would not be loaded automatically. I was just wondering if there was a strong convention for default css files. Although there exists no strong convention, there are common names, as listed by the people who answered, some of which are:
default.css
main.css
web.css
style.css
site.css
Or you can name the css file with the same filename as the html file that uses it.
No.
There are common names for the main stylesheet for a site, e.g. site.css or main.css, but no strong (or useful) convention.
The name style.css starts to look odd as soon as you have more than one stylesheet. My 2 cents would be:
main.css or myappname.css (e.g. intranet.css) for the app
Something like global.css for a stylesheet shared between apps
For css for individual pages, create subdirectories named after the pages so that you can easily see which css are shared and which are only used on certain pages
If you can, I'd recommend keeping it short and all lowercase without underscores / hyphens as it is less prone to typos.
No there is no such thing. It probably is some "guidelines" to follow when designing templates for e.g. Joomla where you have "template.css" and so on. When I do not have such guidelines I normally name the default css "style.css", but this is a matter of taste.
Can't think of a better default than stylesheet.css to match the value of the rel attribute.
<link rel="stylesheet" type="text/css" href="stylesheet.css">
Since stylesheets can be loaded based on media attribute my file naming convention just follows the available options:
theme-media-all.css - used for all media type devices
theme-media-print.css - used for printers
theme-media-screen.css - used for computers screens, tablets, phones, etc.
theme-media-speech.css - used for screenreaders
You could omit the media- prefix but I like to be explicit both for myself years down the line or new developers coming to the project - plus you get filename grouping when sorted alphabetically.
There is no standard, because it's your HTML that decides which CSS file to reference rather than web server configuration.
With that said, it is a good idea to have a convention, so that your files are better organized.
For example, if you tie a CSS file with each file you might re-use the HTML file's name, but with the CSS extension. (e.g. index.html has index.css or index.html.css.)
You could apply the same concept to directories or URL paths if your code is organized that way. (e.g. /MyApp/MyFeature/MyFeature.css).
It's really up to you to decide, but it is important to be consistent, so others can understand your code more easily.
Hope this helps.
I came across a strange behavior while theming Drupal. I turned a few modules that added 5 to 10 link tags to the page. While these new stylesheets were added to the cascade in Firefox, in IE8, by adding these the browser discarded the earlier added CSS files from the hierarchy. In fact, the first files were the first to go, which completely screwed up the styling of the page and had me scratching my head for a while. Eventually I discovered the newly added modules had caused IE to pass some internal threshold where it could not add new includes anymore.
Has anyone seen this behavior before? I'm not sure if it's an issue with browser or with my setup.
Internet Explorer has a maximum limit of 32 CSS file links. Definitely a browser issue. You'll need to think about consolidating your css requests.
Generally you can do this by concatenating them if they're static files, but if you're generating them programatically, you might have to look at a solution to manipulate the response before it gets passed to the browser.
We had to get around this issue for our enterprise ASP.Net project and ended up writing a "Css Multiplexor" that examined the response, found the requested CSS links, generated a web resource for one big css file, and output a link to that instead.
I encountered this issue on our site.
IE8 only permits 32 CSS imports per file. That file could be an HTML file or a CSS file. (*) However, the import limit does not restrict you to 32 CSS files total. You can link to two CSS files in your HTML, each of which #imports 32 CSS files. Playing with tricks like that should get you as many as you need.
The specific workaround we use is to split the CSS files we need into two groups, and have two 'import' CSS files. The HTML page imports the first import CSS file, which imports the first group and the second import CSS file, which imports the second group.
This works fine, but results in lots of HTTP requests, so we only use this workaround on development systems. For our live sites we have a build step that compiles all the CSS into one file.
What Johannes has mentioned -- getting Drupal to aggregate your CSS -- sounds like the best bet.
(*) There's some fine print like: the 32 imports includes the CSS files that have already been imported in the chain from your HTML page. So if your HTML imports a CSS file, then that CSS file can only import 31 other second-tier CSS files, and each second-tier CSS file can only import 30 other third-tier CSS files. You really have to wonder what bizarre algorithm causes this limitation...
The limit is 31 - NOT 32!
While some would say "who cares, close enough, right?" --- With larger applications with hundreds of developers it can be very easy for the page to go over the limit, so you should really know the exact number of css stylesheets can be included on the page.
There are several ways to mitigate the problem:
Reduce the number of CSS files by consolidating into larger files - perhaps manually, or some run time grouping mechanism, or you can use an automated css compiler to combine and minimize all your CSS files
Use #import url(...) statements rather than <link href=""> but remember you can only have 31 #import (again, NOT 32...) statements in one stylesheet
Use #2 above with caution because:
You are only increasing the limit (to 961 css files) not removing it
The browser will be forced to download the CSS files in series rather than in parellel. Normally a browser can download more than 1 css file at a time (the count depends on if the files are in the same domain and which browser you are using) - This can have a significant impact on performance.
Each CSS file requires a round trip to the server adding extra time.