I'm trying to verify the CSS used in a Stylesheet that utilizes custom csspropertys but they don't seem to be working. I can't tell if I'm writing it all correctly and I'd like to check to see what is actually being used. Is there a way to print out a Stylesheet?
Edit: To be clear, these are TornadoFX classes, not just plain CSS. I am trying to verify type-safe CSS, not trying to print a CSS file.
Moving my comment to an answer
To see the CSS that will be generated by a Stylesheet, instantiate it and call the its render() function:
class MyStyles : Stylesheet {
...
}
fun main() {
println(MyStyles().render())
}
Related
I have the following 3 scss files:
// component.scss
#use 'componentFunctions' as componentFunctions;
/** Adding a default color theme to the component **/
#include componentFunctions.addColorTheme(...);
// componentFunctions.scss
#mixin addColorTheme($param) {
... mixin that creates a color theme for the component
}
// main.scss
#use 'component' as componentName;
/** I would also like to use the createColorTheme mixin in this file, to add a new color theme for this component, in case this module is loaded, how can I achieve this? **/
What I am trying to achieve, is to access the function defined in componentFunction.scss, in the main.scss file. The only way I've managed to do this, is to manually redefine the function in the component.scss file, but surely there has to be a better way around for this.
Strangely, if I am not re-namespacing my imports, everything works automatically. There is a possibility that I misunderstood how the #use functionality works in SCSS, could someone elaborate on how could I achieve the desired effect?
According to Sass docs:
Any styles loaded this way will be included exactly once in the compiled CSS output, no matter how many times those styles are loaded.
So you can use #use again in your main.scss file as the code below:
#use 'component' as componentName;
#use 'componentFunctions' as componentFunctions;
$newVar: componentFunctions.myFunction();
In that way you don't need to redefine the function in the component.scss.
PrismJS syntax highlighting is broken when used together with Bulma.
Both PrismJS and Bulma use the number and tag classes. So, there is a conflict between PrismJS and Bulma.
Are there any workarounds?
There are at least 2 workarounds.
Workaround #1
PrismJS adds token class to all highlighted elements including number and tag unlike Bulma. It allows us to write a more specific CSS rule and resolve conflict with Bulma:
.token.number,
.token.tag {
all: inherit;
color: #905;
}
Just specify the correct color used in your chosen PrismJS theme.
Workaround #2
Use Custom Class Prism plugin.
It allows to prefix all Prism classes (e.g., with prism- prefix).
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.20.0/components/prism-core.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.20.0/plugins/autoloader/prism-autoloader.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.20.0/plugins/custom-class/prism-custom-class.min.js"></script>
<script>
Prism.plugins.customClass.prefix('prism-');
</script>
So number and tag become prism-number and prism-tag so the conflict with Bulma will be resolved.
But you also have to manually prefix classes in Prism CSS style-sheet, e.g.:
...
.prism-token.prism-class-name,
.prism-token.prism-function {
color: #dd4a68
}
...
I don't like this approach due to the need to manually edit Prism theme CSS file and then hosting it yourself.
Like Eugene Khyst mentioned in his answer, one way to do it is to use the Custom Class plugin for prismjs.
Instead of renaming every prism class you can selectively rename some of the classes. Which should be easier to maintain.
Prism.plugins.customClass.map({
number: 'prism-number',
tag: 'prism-tag'
});
This will rename only the number and tag classes.
I'm migrating a Stylus library to SCSS since Angular 12 has deprecated Stylus and I'm in that impacted 0.3%. I've run into something we were doing that I'm not sure how to convert to SCSS—maybe it's impossible.
Let me lay this out simply: I work on several projects that all use loads of the same styles, so we put those styles together into one style sheet in its own NPM package. We can then just grab #import '#company/design/styles'; and suddenly we've got all of our regular styles and variables and mixins available in the project, or we can import #import '#company/package/styles/common'; for just the variables and mixins.
The thing is, our projects might need to configure the library before we import it. Suppose the library contains this bit:
// #company/package/styles/_forms.scss
input:invalid {
background: url('/assets/input-error.svg') no-repeat center right;
}
Not every project will have /assets/input-error.svg at that exact location. Maybe one of my projects has to use /subfolder/static/input-error.svg.
I could include this then overwrite input:invalid { background-image: url(...) } to supply it with the correct location, but there may be many references to this particular file and many other assets on top of that to correct. So we instead, in our Stylus library, we introduced an $asset-input-error variable that points to /assets/input-error.svg by default and did something like this:
// #company/package/styles/_forms.scss
input:invalid {
background: url($asset-input-error) no-repeat center right;
}
// the local project
$asset-input-error: '/subfolder/static/input-error.svg';
#import '#company/package/styles';
The above is heavily simplified and isn't actually legitimate SCSS, but I hope it conveys what we're trying to do: we want to set up what are effectively environment variables in our SCSS, include the common style sheet, and have it use those variables.
The thing is, I'm not sure what the legitimate or idiomatic approach is to do this in SCSS. Unlike Stylus, which has a global scope for its variables, SCSS would have me #use '../config'; and reference config.$asset-input-error, and from outside the library there's no way I see to change the configuration to point that asset to a different location. I'm sure SCSS has a way for me to do this, but I'm not sure what it is. Do I convert the entire library into a giant mixin to which I pass optional configuration? Do I do something with global variables? Something else?
How can I provide variables to my SCSS style sheet to configure it as part of including it in a project?
Ultimately the end goal here is just to be able to say to the library things like: “the assets to reference are here” (very important) or “the error color is this in this particuilar project” (less important).
Using #import
You can use global variables declared before the #import as you stated.
SCSS Documentation for this method
#company/package/styles/_forms.scss
$asset-input-error: '/subfolder/static/input-error.svg' !default;
input:invalid {
background: url($asset-input-error) no-repeat center right;
}
#company/package/styles/styles.scss
#import 'forms';
local.scss
$asset-input-error: '/different/path/input-error.svg';
#import '#company/package/styles';
CodeSandbox Demo
Using #use [...] with
You can also hop aboard the #use train if you prefer to future-proof your library.
SCSS Documentation for this method
SCSS Documentation for using mixins
SCSS Documentation for configuring forwards
#company/package/styles/_forms.scss
$asset-input-error: '/subfolder/static/input-error.svg' !default;
input:invalid {
background: url($asset-input-error) no-repeat center right;
}
#company/package/styles/styles.scss
#forward 'forms';
local.scss
#use 'styles' with (
$asset-input-error: '/different/path/input-error.svg'
);
Sadly CodeSandbox and StackBlitz don't support dart-sass, so I don't have a live demo for this but I tested it on the latest version of sass from npm.
I have a document which contains some metadata in the form of small markdown snippets.
Inside of a layout, I want to grab them, render them from markdown to HTML, and then print out the results. (I’m using DocPad’s default template engine, “Eco”.)
Is this possible?
The following assumes you are using marked as your Markdown engine. If you are using RoboSkirt or something else, you can do something similar, just adapt to use their module instead.
First, make sure you have the marked node module in your top level project:
npm install --save marked
Then add a helper function to your docpad.coffee that makes the marked function available in templates:
docpadConfig = {
templateData:
# Specify some site properties
marked: require('marked')
}
Now you can use this in your .eco files:
<div>
<%- #marked(#document.someMetaProperty) %>
</div>
Another way to Erv's answer is to use the Docpad Api which let's you pass the text through its render workflow (this way you can use other installed template engines too)
var renderOpts = {
text: 'here is some **markdown**',
filename:'markdown',
renderSingleExtensions:true
};
docpadInstance.action('render', renderOpts, function(err,result){
console.log(result);
});
source for above snippet: http://docpad.org/docs/api#rendering-individual-files
How do you test if a div tag has a certain css style? I'm trying to test if it has display:none; or display:block.
I tried the following but its giving me an error:
it {should have_selector('signup_server_generic_errors', /display:\s*none/)}
I'd recommend that instead of trying to locate the css style, you instead write your tests to find the css class name.
This way you can change the underlying css styling while keeping the class the same and your tests will still pass.
Searching for the underlying style is brittle. Styles change frequently. Basing your rspecs on finding specific style elements makes your tests more brittle -- they'll be more likely to fail when all you do is change a div's look and feel.
Basing your tests on finding css classes makes the tests more robust. It allows them to ensure your code is working correctly while not requiring you to change them when you change page styling.
In this case specifically, one option may be to define a css class named .hidden that sets display:none; on an element to hide it.
Like this:
css:
.hidden {
display:none;
}
html:
<div class="hidden">HIDE ME!</div>
capybara:
it {should have_css('div.hidden') }
This capybara just looks for a div that has the hidden class -- you can make this matcher more sophisticated if you need.
But the main point is this -- attach styles to css class names, then tie your tests to the classes, not the styles.
You could use has_css? matcher. It can accept :visible options. For more details you can check docs: http://rdoc.info/github/jnicklas/capybara/Capybara/Node/Matchers#has_css%3F-instance_method
For example you can try:
it { should have_css('div.with-some-class', :visible => true) }
My way to ensure that element have a certain class:
let(:action_items) { page.find('div.action_items') }
it "action items displayed as buttons" do
action_items.all(:css, 'a').each do |ai|
expect(ai[:class]).to match(/btn/)
end
end
or smthing like this
expect(ai[:style]).to match(/color: red/)
I found it here: http://rubydoc.info/github/jnicklas/capybara/Capybara/Node/Element#%5B%5D-instance_method
You can use Capybara's assert_matches_style, or the Rspec HaveStyle matcher (which is using assert_matches_style underneath):
When you use assert_matches_style directly, it's:
find(".element").assert_matches_style("font-size" => "46px")
I'm not too familiar with Rspec syntax, but it should be something like this:
it { should match_style("font-size" => "46px") }