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
Turns CSS stylesheets into inline style="" attributes for HTML emails
npm install styliner
Typescript
Module System
Node Version
NPM Version
HTML (76.51%)
JavaScript (16.8%)
Less (5.63%)
CSS (0.84%)
Roff (0.22%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
125 Stars
180 Commits
20 Forks
7 Watchers
2 Branches
10 Contributors
Updated on Apr 12, 2025
Latest Version
1.1.0
Package Id
styliner@1.1.0
Unpacked Size
55.64 kB
Size
16.86 kB
File Count
9
NPM Version
6.13.4
Node Version
12.16.1
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
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
0 existing vulnerabilities detected
Reason
no binaries found in the repo
Reason
Found 5/19 approved changesets -- score normalized to 2
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
license file not detected
Details
Reason
project is not fuzzed
Details
Reason
security policy 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 2025-07-07
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