I'm testing stylus and I'm surprised that the compiler transforms almost everything I type like:
mivar = blackredgrenn
body
margin 0f
background-color #323242342332423123
werewers
color red
&:first-child
color mivar
whatever assa hj
into
body{margin:0 f;}
body background-color #323242342332423123 werewers{color:#f00;whatever:assa hj}
body background-color #323242342332423123 werewers:first-child{color:blackredgrenn}
Is this the way it should work? is there any option to make the compiler to stop and show error like in less? I'm compiling with grunt, is the common practice to run afterwards csslint to spot there the errors? what alternative do we have?
No, there is no option to show errors, as this code is not an error as Stylus sees it.
Stylus' syntax is very flexible now, and it is based on indents, this way you can't write some properties after other ones with an increased indent, as Stylus would interpret then the first part with lesser indent as a selector (that's what happens in your example), and as CSS could always get new properties, there is no list of “known” properies, so whatever is also printed as is.
If you're not sure you're writing a proper indented code, then the best option is either to use a linter to check CSS validity, or to write everything in CSS syntax using curly braces and semicolons.
Related
Here is example it's only forking in html and not in css
How to fix this problem?
It's dificult to find information on internet because i am the only one who have this problem
In your case, the image shows you are outside of a css ruleset so there are many fewer emmet abbreviations that will work there. Your image shows what happens with a prefix of pos - it suggests things like :placeholder-shown, etc. that do appear as part of a css selector. If you are expecting the rest of the emmet abbreviations, like bg for background-color, use it IN a ruleset.
There seems to be some confusion from commenters (some since deleted) that emmet does not work in a css file - it does and has for some time.
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 ...).
Using Stylus preprocessor, I'm looking to embed inline SVG code (not external files) in background-image properties in a manner that will allow me to set the fill attribute of the SVG in the CSS via a Stylus variable.
I've looked into Stylus' url and embedurl methods, but it seems to me that they only work on external files, and I don't know how I'd integrate my need to set the fill attribute with them.
Current (Working but Nasty) Attempt
I have a working solution, but it is ugly and I'm convinced there is an easier and cleaner way that I haven't been able to find.
My current efforts follow with the irrelevant parts of the encoded SVG removed.
myColorVariable = #FF0000
...
background-image 'url("[...]fill%3D%22%23%s%22[...]")' % unquote(slice(unquote(""+myColorVariable),1))
With a full SVG:
myColorVariable = #FF0000
...
background-image 'url("data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A//www.w3.org/2000/svg%22%20data-icon%3D%22thumb-up%22%20width%3D%2232%22%20height%3D%2232%22%20data-container-transform%3D%22scale%281%201%20%29%20translate%280%20%29%22%20viewBox%3D%220%200%2032%2032%22%20fill%3D%22%23%s%22%3E%3Cpath%20d%3D%22M17.688%200c-.4%200-.688.313-.688.813v2.78c0%203-2.912%206.32-4.813%208.22C11.287%2012.513%2010.2%2013%209%2013v17s2%201%205%201h11.187c.9%200%201.725-.605%202.125-1.405%200%200%203.8-10.494%204.5-13.594.1-.4.094-.61.094-.81.1-1.2-.92-2.19-2.22-2.19H22.5c-1.2%200-2.19-1.112-2.19-2.312C20.31%209.488%2022%207%2022%204V2.5C22%201.1%2020.9%200%2019.5%200h-1.814zM0%2013l2%2019h5V13H0zm5%2016c.6%200%201%20.4%201%201s-.4%201-1%201-1-.4-1-1%20.4-1%201-1z%22/%3E%3C/svg%3E")' % unquote(slice(unquote(""+myColorVariable),1))
Issues:
It only seems to work with latest versions of Stylus. For example, it doesn't work on Codepen, but it works in my setup with Grunt, and typing the following into the "Try Stylus Online" section of the Stylus website shows it outputting what is expected.
c = #FF0000
cString = "" + #FF0000
cMinusHash = slice(cString, 1)
cWithEncodedHash = "%23" + cMinusHash
unquote(cWithEncodedHash);
I have to have a series of string manipulation methods on my variable to try and cast it to a string and remove the hash tag of the hex color. I have to remove the hash tag of the hex color because the hash tag needs to be encoded and is thus included in the SVG string. The necessity for both of the unquote methods doesn't make sense to me, but it's what works. Also, the concatenation of an empty string with the color variable seems like a very hacky way to cast the color to a string, but I was unable to find a better way.
The SVG code has to have its quotes (double or single) encoded for the Stylus string interpolation to work, which is added hassle on top of the encoding that cross-browser compatibility requires.
In case it's helpful, here is my Codepen I made attempting to demonstrate my solution that works in my setup but not on Codepen.
Please forgive me if I omit necessary information or do something wrong; this is only my second question here. I'm happy to fix whatever I need to.
Thanks!
I'm trying to get my CSS to pass validation and I have a lot of style rules that look like this:
-ms-filter: "progid:DXImageTransform.Microsoft.AlphaImageLoader(
src='../../../public/images/circ_logo_trans_50.png',
sizingMethod='crop')";
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(
src='../../../public/images/circ_logo_trans_50.png',
sizingMethod='crop');
The validator seems to throw errors when the code is as you see it above. But when I remove the line breaks, it passes.
My understanding is that -ms-filter should be followed by a quoted string, whereas filter should not.
Is what I've said so far correct? Is there anything else about this syntax that is incorrect?
I stumbled upon this problem when trying to minify the CSS sass in.scss:out.css --style compact). When all the code is on a single line, styles at the end stop working because there is something invalid in front. I'm pretty sure it's connected to these filters.
Your understanding of the -ms-filter and filter properties is absolutely correct.
The important issue with your CSS lies in the syntax of your string. The spec explicitly states that a string cannot directly contain a newline. For the purpose of breaking a string over multiple lines in the source itself, simply add backslashes to the end of each line except the last (where the closing quote occurs):
-ms-filter: "progid:DXImageTransform.Microsoft.AlphaImageLoader(\
src='../../../public/images/circ_logo_trans_50.png',\
sizingMethod='crop')";
This will allow the validator to parse your CSS correctly without choking. It should not pose problems for IE as it attempts to parse the string for its own use; unfortunately however I can't say for certain that it won't. If it does have problems, then you might have to either
do away with the line breaks altogether, or
remove the backslashes and leave these declarations invalid. The next time you validate, comment these lines out to prevent the validator parser from choking.
Note that the unprefixed filter property will remain problematic for validation, as it's a non-standard property that does not bear a prefix (prefixes being the standard way of declaring non-standard properties, so to speak). That is something you don't have to worry about, of course, knowing that you are using a widely recognized non-standard form of the property.
When I write CSS in Notepad++, the color coding sometimes seems inconsistent. Normally, selectors are shown in light purple but sometimes they are black for 1 or more lines consecutively. I don't see anything wrong with such lines. Why are they black? What am I missing here?
i'm not sure why that happened to you!?
but you can add keywords to notepad++ :
Setting => Style Configurator ..
Select your language and Style.
Add your keyword like color and etc , separated by space :
Usually, that sort of coloring indicates that the CSS rule immediately preceding the affected one hasn't been closed. Here's an example where I remove the closing brace from a rule in normalize.css, which affects the one that immediately follows in exactly the same way (ignoring the comment and the lack of bold type, of course):
Presumably then, the reason why the "first" declaration after that selector is affected but the subsequent ones are not is because the semicolon from the first declaration tells the syntax coloring parser to terminate the nonsensical statement which is formed by the selector. But I'm just blindly guessing.
If you're sure that the preceding rule has been closed properly, then the syntax coloring parser may have been confused. Try simply highlighting the rule, deleting it, and undoing; that usually works for me.
Since Notepad++ recognizes color of codes based on the language type, you can't able to view multiple languages with color codes in a same file. Even though CSS is a part of web designing, it is still a unique language. If you want to display the CSS codings inside the HTML to color, just change the language type to CSS (only for temporarily purpose). But, don't forget to revert the language conversion back to HTML before saving the file.
Steps: Language -> C -> CSS