In SCSS, is there a way to output only styles that use certain variables?
I have color variables all in one file, but they are used all over the stylesheet. Now I want to add a different color theme without duplicating all the styles unrelated to color, is that possible?
It's not that easy (and quite error prone) to determine usage of certain variables for output. You could check if they are defined using #if($x) but that might not be what you're looking for.
But I don't think I fully understand what you're trying to achieve...
Is it:
white labeling your app/site (so 'overriding' the original values with new values)?
Having two separate 'themes' exist on their own (unique variables) but avoiding conflicts that might happen due to overlapping styles?
For:
Redefine the variables, given this line: $x = 1; $x = 2; z-index:$x; the z-index will be 2. So something like: #import 'base-theme'; #import 'client-theme' would override every existing variable with the value from client-theme which would mean zero rewrites of existing styles (and only one extra file with the new theme).
You will need to add logic for this, so rewriting styles will be a likely outcome. something like #if($hotpink) { color:$hotpink } #else { color:$original-pink} should work for those, but it will be cumbersome and quite hard to maintain.
My recommendation (for most use-cases): Go with option #1, it will save you a lot of work and debugging.
Hope that helps, feel free to ask if this seems unclear.
Related
When there are many variables that connect to each other, it is hard to tell their hierarchical relationships. Is there an edit to the launch.json file I can make to easily distinguish this? (I just want to change the color of variables depending on how they sit in the nested hierarchy).
The picture shows what I currently see, and what I am hoping to see.
(I'm also new to coding, so please feel free to be verbose)
https://i.stack.imgur.com/gWz8E.png
I wanted to know from someone with field experience, what the best practice of implementing a programm, with UI or CMD in multiple languages (letting the user choose e.g. between English, French, German) is.
If there already exists a discussion about this topic I would be grateful, if somebody could send me a link to it, the first few Google searches I only found things like how to choose a programming language
The first options that came to my mind where switch(globalStringLanguage) and #ifdef GERMAN #define PROGRESS Fortschritt... .
Would really like to know, if there is a best practice out there(and which one that would be) and how you guys implement it in your firm.
Thanks in advance for the replies,
1973ProgrammingDude
There are 4 'best practices / topics' that you can research:-
i18n - internationalisation
This is more about the way you design software. You design buttons etc. to 'lookup' the text they should contain from a dictionary file rather than hard coding them into your source code.
It also applies to things like dates and currency and allow them to be formatted differently depending on the language / locale.
If you design your product correctly you should be able to change all the text on buttons, links etc. and change the date format, currency formatting etc. with one language variable being changed.
Think of this part as designing your system to account for translation, local formatting and even right to left layouts for languages such as Arabic that are read from the right to the left
l10n - localisation
This is the process that follows on from designing your system under i18n. You would define formatting options so dates etc. are correct.
You would also define wording of buttons etc. so they are correct.
Finally you would also have a system so that content could be translated for the given locale.
Think of this part as the actual translation process.
l12y - Localisability
pretty much covers the process and considerations of l10n - just mentioned so you can research it for more complex scenarios and implementation ideas.
g11n - Globalisation
Encompasses all of the above standards, yet again just mentioned for reference as it occasionally throws up some different articles on Google when searching on how to solve a particular problem.
Quick sanity checks
When designing a system that supports glln it easier to have a couple of points to help make you think about decisions you are making.
If you enter ANY plain text within HTML tags / controls / whatever is applicable to your chosen programming language then you will likely have made a mistake. Every item of plain text should be programmatically inserted into a page.
Design a dictionary system - for every piece of plain text you want to add to the site add it to a dictionary. The dictionary can be a simple key:value list if you need with the key being the English translation and the Value being the translation for your locale. Make sure that you start with English:English translations so you can make sure you don't miss any. I would recommend JSON arrays as most translation companies will now understand how to use these nowadays without you needing to design a user interface for them.
When designing a widget / component consider implications of longer text - just because a layout works in English (i.e. a button group fits on one line) doesn't mean it will work in another. Some languages may be 3 times longer for the translation of a word so you must consider this when designing a layout.
Everything should be designed so it can easily be reversed. Right To Left versions of everything should be easy to implement so design your system so only a couple of variables need changing to create the RTL version. (i.e. if web based have a main CSS definition of a widget and then make sure a global CSS class applied to the body can switch the layout).
It isn't just text -> imagery needs to be different as different cultures will interpret an image differently. Also iconography should be internationalised as well as a dollar bill icon doesn't work well to represent money in the UK, never mind in other countries.
CSS Example but the principle applies to all languages / platforms
.widget{
//define general styles
}
.left-to-right .widget{
//add some formatting to adjust layout for left-to-right languages such as English when the 'left-to-right' global variable is set.
margin-left: 20px;
}
.right-to-left .widget{
//add some formatting to adjust layout for right-to-left languages such as Arabic when the 'right-to-left' global variable is set.
margin-right: 0px;
}
So I am on the fence about learning SASS. I still don't get it. Why bother if I can write CSS and understand it and it works.
Why learn to raise chickens if all I want is the egg?
It seems as though the SASS would take longer to figure out then just writing the css.
I can use variables in CSS3. I also don't understand why you would write .foo {padding: $width/2;}
I have to figure out what padding I want then figure out the mathematical equation to write it. I just want to write padding: 12px; and be done...
Please enlighten me on WHAT Makes SASS better? quicker? easier?
thanks -
Advantages are like this
You can separate your sass files into modular areas. For instance
SASS
1. tools (put bourbon or bitters here)
2. basics (body, links or common things)
3. modules (reuasable stuff. Boxes, cards, etc)
4. layouts (your containers, footers, headers etc)
In doing this you can easily find where the CSS is that you may want to change. There are several youtube videos that discuss how to make modular sass directorys.
You can use variables. Suppose you have a color that is used several times in a CSS file. SASS allows you to change one variable and that would change all instances of that usage. $red: #ff0000 is an example of a variable. When you use it, just use
color: $red
Mixins are functions that you can use and easily create a small amount of sass that will convert into large amounts of CSS.
I suggest watching videos on youtube to learn it. You wont be sorry. Especially learn modular usage like SMACSS
Here is a link to a vid that will help you
Sass is an extension of CSS that adds power and elegance to the basic language. It allows you to use variables, nested rules, mixins, inline imports, and more, all with a fully CSS-compatible syntax. Sass helps keep large stylesheets well-organized, and get small stylesheets up and running quickly, particularly with the help of the Compass style library.
If you choose to stick with CSS, there is nothing wrong with that. (My understanding is that) People like SASS because they can type is with variables and such and it will then be converted into regular CSS. So yes, it does basically the same thing, but the improvements come as writing it, which is faster and more efficient. People that use SASS like that they don't have to write the same or similar things, they can instead just use SASS and get it converted to CSS which is faster than writing it, now I am just a SASS beginner, so please don't read into my thoughts that much, some of this may be not 100% correct, but it is my understanding. In my opinion, you should look into SASS and maybe try it a little, if you find it is more efficient and you like it more, stick with it, but if you decide it just isn't for you, then just stick with CSS.
I've been searching through a large number of CKEditor posts and have yet to find a targeted answer to this question. I know CKEditor is very configurable (which I haven't leveraged yet.)
For every formatting action performed, CKEditor wraps it in a separate span tag. So if I 1) change the font to Arial 2) change the size to 36px 3) change the color, I end up with this HTML which seems unnecessarily verbose.
<p><span style="color:#DAA520"><span style="font-size:36px"><span style="font-family:arial,helvetica,sans-serif">Hi</span></span></span></p>
I would rather it just did something like <p style="..styles list">Hi</p>
My question: Is this configurable (and how), and/or is there a rationale for them doing it this way where I should just accept the behavior?
It certainly seems like a relatively clean means of implementation on CK Editor's part, and would help it avoid conflicting logic for different styles applied to dissimilar spans.
If you as the user want consistent differences with multiple variables like size, color, or font, you should really be using classes, I would think. A WYSIWYG editor like CK is designed to implement HTML code that is readable, not pretty. If you want more elegant code, you probably need to write it yourself.
Since other adaptations from WYSIWYG editors/ word processors generate obscene looking code, e.g. Microsoft Word/ Outlook, or Adobe's new CSS from layout feature, this span output isn't actually too bad.
Is there any way to include the color highlighting rules in the tmLanguage file itself?
For those who aren't familiar with it, Pro*C is sort of this mutant hybrid love-child of SQL and C, and both syntaxes are present in the file. However, there are a few Pro*C specific keyword which start or stop a big long block of SQL inside of one.
What I would like to do, is have the Pro*C keywords be different colors than the C/SQL keywords, and for the SQL blocks to have a different background color, so that they stand out. In none of the common themes are there appropriate scopes to use for this, not that I can tell. So I can't just call the Pro*C keywords "keyword.source.some-differently-colored language" (they should really be keyword.source.pro-c anyway) or the blocks "text.whatever.another-color" (using meta.block.pro-c right now).
It would be useful if I could just include the colors for these elements in the same plist that defines the syntax. Is this possible in Sublime? What's the correct way to do this?
As far as I understand it, you would have to modify the color scheme file to support what you want. Bundling the colors as part of the tmLanguage file doesn't make sense anyways. By doing that, you would basically be saying every user has to use your predefined colors, which I could imagine people wouldn't like. For example, let's say I have a white background, and you decide to make the text color white. It would look like there is nothing there.
I think the best route is to include sample "extension" of the color scheme file. Then allow the users to modify it themselves as they see fit. This would also let you use the standard naming conventions, so if they don't apply any new scopes, everything still looks okay. Of course, they can specify a more detailed scope in the scheme file to apply the proper text color/background.
What I think would be nice was if there was some way to simply extend a color scheme from a separate file, rather than needing to modify the original. Though that doesn't exist.