Gathering detailed insights and metrics for styliner
Gathering detailed insights and metrics for styliner
Gathering detailed insights and metrics for styliner
Gathering detailed insights and metrics for styliner
npm install styliner
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
124 Stars
180 Commits
20 Forks
8 Watching
2 Branches
10 Contributors
Updated on 16 Aug 2024
HTML (76.51%)
JavaScript (16.8%)
Less (5.63%)
CSS (0.84%)
Roff (0.22%)
Cumulative downloads
Total Downloads
Last day
71.3%
221
Compared to previous day
Last week
38%
900
Compared to previous week
Last month
-9.3%
3,272
Compared to previous month
Last year
-27.2%
50,664
Compared to previous year
Styliner is a Node.js library that reads CSS rules from external stylesheets and converts them to inline style=""
attributes in an HTML document.
Styliner is intended for use with HTML emails. With it, you can write regular CSS or LESS (with the Styliner-less package) stylesheets, then merge them into your HTML and create emails that work with Gmail (which drops all <style>
tags). Unfortunately, though, you'll still need to use <table>
s to get complex layout.
You can also use advanced features ("dynamic rules") like :hover
selectors or media queries, and Styliner will leave them in a <style>
tag. This way, you can build interactive emails that will light up when viewed in an email client that supports <style>
tags, while still maintaining Gmail support.
In effect, you get graceful degradation for your email designs.
Styliner uses the Q promise library.
1var styliner = new Styliner(baseDir, { options }); 2styliner.processHTML(htmlSource, directory) 3 .then(function(source) { ... }); 4//Pass filePath to processHTML 5styliner.parseFile(filePath) 6 .then(function(source) { ... });
The baseDir
parameter specifies the base directory for relative paths. When processing an HTML source file, you can optionally specify a directory for that source, and any relative paths within the file will be treated as relative to that directory (instead of relative to the Styliner
instance's baseDir
).
The processHTML
method returns a Q promise of the inlined HTML source.
You can pass an options hash as the second parameter to the Styliner
constructor with the following options: (all options default to false):
compact: true
noCSS: true
<style>
tags for rules that cannot be inlined. This option will completely drop any dynamic CSS rules. (such as media queries, pseudo-elements, or @font-face
s)keepRules: true
<style>
tags instead of inlining static rules into elements. This results in smaller files, but will not work with Gmail.fixYahooMQ: true
keepInvalid: true
urlPrefix: "dir/"
<a>
tags, <img>
tags, and stylesheets will have this path prepended. For greater flexibility, pass a url()
function instead.url: function(path, type)
background: red;
in one rule, and background: linear-gradient(...)
in a more specific rule, Styliner will replace the property from the first rule with the more specific one. This means that browsers that don't support linear-gradient()
won't see any background at all.margin
and padding
, shorthand inlined properties that are overridden by non-inlined non-shorthand counterparts will not be overridden correctly.
!important
in order to override the inlined static rule on the first element.!important
-ize the inline property in the second element, but that would leave an unfixable problem if there is another dynamic rule that should override that property on the second element.!important
to override the already-!important
-ized less-specific soft-dynamic rule. It is then impossible to make the more-specific soft-dynamic rule override the inlined property.important = true
after the first pass.!important1
, !important2
, etc), and changing Styliner to keep running additional passes and making overridden rules more and more important until it stabilizes.
Acid3 doesn't work because most of its rules need to be applied dynamically (for elements created in Javascript). I can fix this by adding .js
to those rules.
Acid2 has the following issues:
background: red pink
(which is an invalid value) incorrectly overrides the valid background: yellow
for .parser
, resulting in a white background.
This happens because parserlib does not validate the background
property at all. (this would be a complex validation rule to add)
width: 200
(which is an invalid value) incorrectly overrides the valid width: 2em
for .parser
, resulting in the element stretching to fit the browser.
This is fixed by parserlib#48, which has not been merged.
* html .parser
incorrectly matches .parser
, resulting in a gray background.
This is caused by CSSselect#8 and cheerio#162.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
0 existing vulnerabilities detected
Reason
Found 5/19 approved changesets -- score normalized to 2
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
license file not detected
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2024-11-25
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More