Note: I'm open to other solutions if this is the wrong approach
I want to used https://github.com/twitter/css-flip for rtl support on
my project
The documentation is sparse and seems to make a lot of assumptions. I can successfully run the CLI against a .css file but not a scss file as I suspected.
I was thinking about adding a step that ran the css-flip on the compiled styles like so:
css-flip app/assets/stylesheets/application.css > app/assets/stylesheets/application.rtl.css
One, I'm not sure this is the best approach, and Two, if it is reasonable, how could I run the css-flip command on the assets after they've been compiled?
I'm not sure if this is the right approach, but I'd say you can use css-flip to generate your css files, and afterwards, I see 2 different solutions. (In the case you don't want to use Pete suggestion about the direction property, but I assume you may want some custom style depending of the orientation of the language.)
1 - depending on the version of your site, you change the asset being loaded.
2 - Or, I'd say you concat your two css files generated to put both behind a class (probably with the help of a preprocessor such as sass), and you put this class on your body, and change it whenever the user changes their language settings.
solution 1 creates lighter css file, but your user need to reload the page when they change language, whereas solution 2 creates bigger css file, but user won't need to reload their page when they change language.
Hope this helps.
Related
I've built a library that will be used by several Angular applications (multiple teams and no monorepo). This library includes a scss-theme. This theme uses two SVG-files. However, I can't get it to work. The path is always incorrect.
My theme scss:
.test::before {
content: url('/test.svg');
}
I've written a Schematic that can be used by the library consumers to store the images inside a subdirectory of the assets folder of the application (e.g. src/assets/test-path). The Schematic does work as expected.
It does work when I add the following style inside the client's scss:
#import "test-company/test-lib/theme";
.a-client-test::before {
// This is just an example and assumes that the test image is located at this path.
background-image: url('../../assets/test-path/test.svg');
}
But as soon as I remove the line above (that actually uses the image from the assets folder and is not required at all). The path won't work anymore.
I've tested the following paths inside the library: ./test.svg, ~/test.svg, /test.svg. Only the latter does work but only with additional styles like the one above (that wouldn't be used) on app side. That's something I want to avoid as maybe we provide 50 icons on the library-side and it would be tedious to add these classes only to use the assets.
Some additional information:
I've added node_modules to the predecessor options in angular.json.
All other styles are working correctly. Only the image doesn't work.
I know that I can use ccsUrl: "inline" option inside the ng-package.json. However, I think this option only works (as far as I know) on styles that are used by components. But I actually copy the theme styles over after the build process. Additionally, the number of icons that are used inline shouldn't be too big, otherwise, the bundle size will increase and is therefore not an option for me.
I also don't know what is best practice for a scenario like that. I just couldn't figure out a proper way so far. But I assume writing a Schematic that copies over files is also not the best approach. Maybe there is a better way (e.g. a way to reference assets from the library but keep in mind I have the styles inside my library and the path is, therefore, complicated to figure out for all modules).
Just to make it clear again: My library has a scss file that uses an image. That image path is clear at the built time but doesn't work when used by an app. I can copy over the images, but that only helps when those images are used by the app somewhere in the styles. Then the path /image.svg works. The image as well as the scss that makes use of it are provided by my application.
Thanks for your help!
I have a website which uses 1 css file, it is called body.css and it consists of 841 lines. Should it be sorted in different files (header.css, footer.css page1.css, etc...), is it better in just 1 file or does it not matter?
The only thing I know for sure is sorting it in more files is a lot more readable.
Also if someone answers this I'd be most grateful for a little explanation.
My opinion would be one of two things.
1) If you know that your CSS will NEVER change once you've built it, I'd build multiple CSS files in the development stage (for readability), and then manually combine them before going live (to reduce http requests)
2) If you know that you're going to change your CSS once in a while, and need to keep it readable, I would build separate files and use code (providing you're using some sort of programming language) to combine them at runtime build time (runtime minification/combination is a resource pig).
With either option I would highly recommend caching on the client side in order to further reduce http requests.
So, there are good reasons in both cases...
A solution that would allow you to get the best of both ideas would be :
To develop using several small CSS files
i.e. easier to develop
To have a build process for your application, that "combines" those files into one
That build process could also minify that big file, btw
It obviously means that your application must have some
configuration stuff that allows it to swith from "multi-files mode" to "mono-file mode".
And to use, in production, only the big file i.e. Single CSS
Result : faster loading pages
maybe this will help you..
For optimal performance it is better to have only one css file.
But for readability it would be better to have different files for different parts.
Take a look at tools like SASS, which help do that without sacrifice performance. Additionally it has features to make your files even more readable by introducing variables, function and much more.
Using more files means more requests. It will take more time to load and make unnecessary requests to the server. I'd stay with one file.
The only good reason to have other css files would be if you have third-party components, to keep them separated and be able to update them easily.
The order matters: Rules loaded later will override rules with the same name loaded before (this is valid even for rules in the same file).
What do you mean that your website uses one CSS file? Normally you'd write your style definitions in multiple files, and they are concatenated (or not) into one file. My point is, what you are working on in your development environment should stay modular, readable, it shouldn't be influenced by what you have in production.
As for the order of the CSS files, yes, it matters, as you can overwrite your previous definitions.
For optimal caching I'd recommend you to build all the vendor CSS in one file, and your CSS in another file, versioned, so that if you change something in your code, only that file has to be updated by the browser.
But these things depend on the infrastructure. As the browsers are able now to send multiple requests simultaneously, having multiple files can lead to faster page load than only one. But I'm not sure about this.
you might want to take a look at gulp to automatically optimize, and minify your CSS code.
All css in one file is OK.
But it's free : you can make as many css file as you want.
However usually this is how it is:
1 global css file for the entire page. You put the common css in here that is useful for every page on your site. You can call it app.css or style.css or mywebsite.css or any name you want.
1 specific css file for a specific page when you want to specially separate this css from the global css file. Because it will contains css only useful for a few pages. For example you have a special component made by your own or a special functionnality. Example : you have made a spcial javascript code working with some html for uploading some file and you want to have your code js/css separate.
Usually, you can also have one css page for each page, but always one global css file for the entire site.
Note : Same question is also valid for javascript
Note 2 : You can also think about using a framework to minify your javascript and css into one single css / js file at the end. At work our technical boss use wro4j which works for java but it should exists many more other frameworks as you can search on google.
I am making a website with concrete 5.7. and to edit some things i have copied the Elemental theme and created my theme. But there are two things i don't know how to edit:
1)Is there a way to define how the elements are going to be disposed in mobile version or at least at which size the autonav is going to be changed by the menu button?Also in small screens the logo becomes really small and all the elements appear disordered.(attached file shows those problems)
2) When i change the colors of my website,(settings->design->customize) where does this changes store, because for me it would be easier to use a text editor rather than doing it with the tool. I don't want to create a new color preset, only to know where these changes are stored.
Thanks for everything.!
Photo: https://plus.google.com/photos/109724001772064952270/albums/6114581190555851105 The first one is the original and the other is the mobile version.
That's actually a bit complex. In the elemental folder, there's a css folder. Inside that folder there's a bootstrap-modified.css file that is responsible for many things including the grid. As the name suggests, it is minified so hard to read and modify.
You also have a file called main.less and several folders containing a lot of other less files.
main.less gets processed and compiled into a css file on the fly, meaning when the site is visited and the css file was not generated yet or when less files were modified.
Anything you want modified you should modify in the less files.
Look for media queries "#media" to find styles specific to certain screen sizes.
how elements are disposed in mobile version is really something you need to deal with through the use of CSS. It is not really something Concrete5 has control over.
The changes to design made through settings->design->customize are saved in the database.
BUT the things you can modify are defined in the site's css file. You could simply modify the css file directly using any text editor instead of customizing design through the dashboard.
I recently setup django-grappelli on my first django app. While I like the way it looks I want to customize the colors, and other CSS.
From my research, it looks like I will have to use Compass but I've never used Compass before and want to double check that this is the best method before I embark on that path!
Is Django-grapelli even the right choice for some one that wants to customize the color theme?
Things I tried
Modify the CSS in the Grappelli stylesheets but they are formatted in a way that makes it tedious.
Extend the style sheet but I am not sure where to do this for the admin.
Create a custom.css but could not figure out where to put the path
Thanks for your advice!
It seems to me like Compass is just a tool to write CSS. I've never used it, but at the moment I don't see how it could make modding the admin interface any easier than doing it manually!
Whenever I make changes to the admin (I've made changes to Grappelli, like you're trying to do), I always use what you've listed as number 2. I've never had any troubles! I can try to help you out, if you'd like to try again.
What I do first is go to my Python install directory and copy the Grappelli source from Lib/site-packages. I put this code in my project directory as a project-level app. So, if you're using Django 1.4, you'll have a folder that has your project folder as well as manage.py in it. Put the code there.
Then, using your favorite web developer tools (I prefer Chrome's), figure out which stylesheet you need to modify and which css file it's in. I do this by right-clicking the element and selecting Inspect Element. This brings up the dev tools, and at the right it tells you the css file its referenced from as well as which line its on. If you open up that css file in your favorite text editor and make changes to it, it should work!
Let me know if you're having any trouble with this. I can try to help you out further.
(and, P.S., I wasn't trying to be pedantic with a basic overview of the use of Chrome's developer tools. I was just trying to be helpful by not assuming anything. I hope you don't take it as an insult.)
I'm considering using less in an upcoming project but have been trying to figure out the best way to work with it while in development.
Usually when developing a site I'll write my html and css then start testing it in the browser, see how it looks, refine, reload, and repeat the whole process until I'm happy with how everything looks.
A crucial part of the process is using the Inspect Element feature in the browser to identify the piece of CSS I need to change. Usually just by looking at the line number I know exactly where to go in my CSS file.
But if I use Less (or any other method of combining/compressing my CSS) it makes the line numbers useless. I know I could use Find to search for the section of code but line numbers are much faster.
This is especially true when working on a project that involves other developers or large CSS files.
I just wondered how others deal with this, or maybe there's a better process?
Minified CSS really should only be going out to the production version of your site. When you're performing tests/changes etc, this should all be done in some test or development version of your site in a secondary server area where you can have the line-numbers version of css available. The same would go for JavaScript. On the production viewable copy, you want it minified. In development, you don't.
In any event, you should always have 2 copies of your css. The first copy is the primary source copy that is your development copy. It has all of your properly formatted styles with line-breaks in it. The other is the very latest minified version of your css that went to production. This will allow you to switch between the 2 files rapidly in the event that you need to work something out, assuming your site uses some sort of templated delivery (layout pages, master pages, or whatever).
The minified version will only be useful in the final delivery. All other needs should use the master copy. It might not be a bad idea to put a configuration in server-side portion of your site that determines what style sheet to use. That way you can simply change a configuration setting and go into a "debug" mode.
I agree with Joel - that's how I handle it. A build script minifies the CSS (and JS) before each release is FTP'ed to production. I just have a switch in PHP like:
if ($config->prod()) {
// incldue the minfied css
} else {
// include all the original files
}
Personnaly, I use an ant build script to make a production version:
it "condense" multiple css files in one
then it minify them with YUI compressor
same for scripts
(page recomposition to point to the newly generated files)
this way you divide your http request for those files, and gain some bandwith from 30% to 70% i'd say. depends on gzip also.
in my case, the dev version have:
18 css weighting 178ko
reduced down to 1 css at 96ko in the production version
I personally use tools to minify and inject the CSS into the browser each time i save my Less file. So i see each change immediately. This way it's pretty clear what just happened. I don't need the referencing line numbers that much any more.
I recently started using source maps, to see the correct file and line numbers (of my less files) when inspecting CSS in the browser again. I think that is what you are looking for. I personally don't need this extra fanciness that much.