kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity
gitlab-org--gitlab-foss/app/assets/stylesheets/mailers/highlighted_diff_email.scss

208 lines
5.5 KiB
SCSS
Raw Normal View History

Syntax-highlight diffs in push emails Based on: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/151
2016-05-12 11:06:14 -04:00
@import "framework/variables";
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
// This file is largely copied from `highlight/white.scss`, but modified to
// avoid all descendant selectors (`table td`). This is because the CSS inlining
// we use performs dramatically worse on descendant selectors than the
// alternatives.
// <https://gitlab.com/gitlab-org/gitlab-ee/issues/490#note_12283632>
//
// DO NOT ADD ANY DESCENDANT SELECTORS TO THIS FILE. Instead, use (in order of
// preference): plain class selectors, type (element name) selectors, or
// explicit child selectors.
Enable ColorVariable in scss-lint
2016-11-30 08:25:25 -05:00
/*
* Highlighted Diff Email Syntax Colors
*/
$highlighted-highlight-word: #fafe3d;
$highlighted-hll-bg: #f8f8f8;
$highlighted-c: #998;
$highlighted-err: #a61717;
$highlighted-err-bg: #e3d2d2;
$highlighted-cm: #998;
$highlighted-cp: #999;
$highlighted-c1: #998;
$highlighted-cs: #999;
$highlighted-gd: #000;
$highlighted-gd-bg: #fdd;
$highlighted-gd-x: #000;
$highlighted-gd-x-bg: #faa;
$highlighted-gr: #a00;
$highlighted-gh: #999;
$highlighted-gi: #000;
$highlighted-gi-bg: #dfd;
$highlighted-gi-x: #000;
$highlighted-gi-x-bg: #afa;
$highlighted-go: #888;
$highlighted-gp: #555;
$highlighted-gu: #800080;
$highlighted-gt: #a00;
$highlighted-kt: #458;
$highlighted-m: #099;
$highlighted-s: #d14;
$highlighted-n: #333;
$highlighted-na: teal;
$highlighted-nb: #0086b3;
$highlighted-nc: #458;
$highlighted-no: teal;
$highlighted-ni: purple;
$highlighted-ne: #900;
$highlighted-nf: #900;
$highlighted-nn: #555;
$highlighted-nt: navy;
$highlighted-nv: teal;
$highlighted-w: #bbb;
$highlighted-mf: #099;
$highlighted-mh: #099;
$highlighted-mi: #099;
$highlighted-mo: #099;
$highlighted-sb: #d14;
$highlighted-sc: #d14;
$highlighted-sd: #d14;
$highlighted-s2: #d14;
$highlighted-se: #d14;
$highlighted-sh: #d14;
$highlighted-si: #d14;
$highlighted-sx: #d14;
$highlighted-sr: #009926;
$highlighted-s1: #d14;
$highlighted-ss: #990073;
$highlighted-bp: #999;
$highlighted-vc: teal;
$highlighted-vg: teal;
$highlighted-vi: teal;
$highlighted-il: #099;
$highlighted-gc: #999;
$highlighted-gc-bg: #eaf2f5;
Changed CSS for emails to be mostly single class selectors
2016-07-13 11:31:32 -04:00
.code {
Enable ColorVariable in scss-lint
2016-11-30 08:25:25 -05:00
background-color: $white-light;
Syntax-highlight diffs in push emails Based on: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/151
2016-05-12 11:06:14 -04:00
font-family: monospace;
Reduced diff email CSS
2016-07-12 06:33:10 -04:00
font-size: $code_font_size;
Syntax-highlight diffs in push emails Based on: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/151
2016-05-12 11:06:14 -04:00
-premailer-cellpadding: 0;
-premailer-cellspacing: 0;
-premailer-width: 100%;
Changed tr to be direct descendant
2016-07-21 06:18:40 -04:00
> tr {
Syntax-highlight diffs in push emails Based on: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/151
2016-05-12 11:06:14 -04:00
line-height: $code_line_height;
Reduced diff email CSS
2016-07-12 06:33:10 -04:00
}
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
}
Changed CSS for emails to be mostly single class selectors
2016-07-13 11:31:32 -04:00
.diff-line-num {
padding: 0 5px;
text-align: right;
width: 35px;
Finish refactoring grays
2016-12-12 17:26:21 -05:00
background-color: $gray-light;
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
color: $black-transparent;
Finish refactoring grays
2016-12-12 17:26:21 -05:00
border-right: 1px solid $white-normal;
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
&.old {
background-color: $line-number-old;
Reduced diff email CSS
2016-07-12 06:33:10 -04:00
border-right-color: $line-removed-dark;
Syntax-highlight diffs in push emails Based on: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/151
2016-05-12 11:06:14 -04:00
}
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
&.new {
background-color: $line-number-new;
Reduced diff email CSS
2016-07-12 06:33:10 -04:00
border-right-color: $line-added-dark;
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
}
}
.line_content {
Fixed padding on line content
2016-07-20 12:53:37 -04:00
padding-left: 0.5em;
padding-right: 0.5em;
Reduced diff email CSS
2016-07-12 06:33:10 -04:00
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
&.old {
background-color: $line-removed;
Changed CSS for emails to be mostly single class selectors
2016-07-13 11:31:32 -04:00
> .line > span.idiff,
> .line > span > span.idiff {
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
background-color: $line-removed-dark;
}
}
&.new {
background-color: $line-added;
Changed CSS for emails to be mostly single class selectors
2016-07-13 11:31:32 -04:00
> .line > span.idiff,
> .line > span > span.idiff {
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
background-color: $line-added-dark;
}
}
&.match {
color: $black-transparent;
Finish refactoring grays
2016-12-12 17:26:21 -05:00
background-color: $gray-light;
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
}
}
Fix email line-height in Outlook Outlook seems to handle `white-space: pre` weirdly, so just use `pre` elements (but only for emails!).
2016-08-17 09:16:29 -04:00
pre {
margin: 0;
}
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
span.highlight_word {
Enable ColorVariable in scss-lint
2016-11-30 08:25:25 -05:00
background-color: $highlighted-highlight-word !important;
Syntax-highlight diffs in push emails Based on: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/151
2016-05-12 11:06:14 -04:00
}
Enable ColorVariable in scss-lint
2016-11-30 08:25:25 -05:00
.hll { background-color: $highlighted-hll-bg; }
.c { color: $highlighted-c; font-style: italic; }
.err { color: $highlighted-err; background-color: $highlighted-err-bg; }
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
.k { font-weight: bold; }
.o { font-weight: bold; }
Enable ColorVariable in scss-lint
2016-11-30 08:25:25 -05:00
.cm { color: $highlighted-cm; font-style: italic; }
.cp { color: $highlighted-cp; font-weight: bold; }
.c1 { color: $highlighted-c1; font-style: italic; }
.cs { color: $highlighted-cs; font-weight: bold; font-style: italic; }
.gd { color: $highlighted-gd; background-color: $highlighted-gd-bg; }
.gd .x { color: $highlighted-gd; background-color: $highlighted-gd-x-bg; }
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
.ge { font-style: italic; }
Enable ColorVariable in scss-lint
2016-11-30 08:25:25 -05:00
.gr { color: $highlighted-gr; }
.gh { color: $highlighted-gh; }
.gi { color: $highlighted-gi; background-color: $highlighted-gi-bg; }
.gi .x { color: $highlighted-gi; background-color: $highlighted-gi-x-bg; }
.go { color: $highlighted-go; }
.gp { color: $highlighted-gp; }
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
.gs { font-weight: bold; }
Enable ColorVariable in scss-lint
2016-11-30 08:25:25 -05:00
.gu { color: $highlighted-gu; font-weight: bold; }
.gt { color: $highlighted-gt; }
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
.kc { font-weight: bold; }
.kd { font-weight: bold; }
.kn { font-weight: bold; }
.kp { font-weight: bold; }
.kr { font-weight: bold; }
Enable ColorVariable in scss-lint
2016-11-30 08:25:25 -05:00
.kt { color: $highlighted-kt; font-weight: bold; }
.m { color: $highlighted-m; }
.s { color: $highlighted-s; }
.n { color: $highlighted-n; }
.na { color: $highlighted-na; }
.nb { color: $highlighted-nb; }
.nc { color: $highlighted-nc; font-weight: bold; }
.no { color: $highlighted-no; }
.ni { color: $highlighted-ni; }
.ne { color: $highlighted-ne; font-weight: bold; }
.nf { color: $highlighted-nf; font-weight: bold; }
.nn { color: $highlighted-nn; }
.nt { color: $highlighted-nt; }
.nv { color: $highlighted-nv; }
Optimise email CSS for speed with Premailer Remove all descendant selectors from the push email styling, to drastically reduce CPU time when inlining the CSS for syntax-highlighted diffs. Background: Premailer is a Ruby gem that inlines CSS styles from an external stylesheet before emails are sent, so that they are compatible with Gmail. At a high level, it parses the CSS files it finds, and parses the email body with Nokogiri. It then loops through the selectors in the CSS, using Nokogiri to find matching elements, and adds inline styles. (It does more than this, like merging styles applied to the same element, but that's not relevant to this issue.) Nokogiri converts CSS selectors to XPath first, like so: Nokogiri::CSS.xpath_for('foo bar') # => ["//foo//bar"] On documents with high node counts (say, a syntax-highlighted copy of jQuery), having both descendant selectors is very expensive. Both `//foo/bar` and `//bar` will be much more efficient, although neither are directly equivalent. An example, on a document containing two syntax-highlighted copies of jQuery: Benchmark.realtime { p doc.search('.o').count } # 9476 # => 0.3462457580026239 Benchmark.realtime { p doc.search('.code.white .o').count } # 9476 # => 85.51952634402551 The performance is similar for selectors which _don't_ match any elements, and as Premailer loops through all the available selectors, we want to avoid all descendant selectors in push emails. Because of the theming support in the web UI, all syntax highlighting selectors are descendant selectors of classes like `.code.white` or `.code.monokai`. There are over 60 CSS classes for syntax highlighting styles alone, all of which are expressed in the inefficient form above. In emails we always use the white theme, and were reusing the same CSS file. But in emails, we don't need to descend from `.code.white` as that will always be the theme, and we can also remove some other selectors that are only applicable to the web UI. For the remaining descendant selectors, we can convert them to child selectors, type selectors, or class selectors as appropriate. As in the example above, having no descendant selectors at all in the push email CSS can provide a drastic (and surprising) performance improvement.
2016-06-06 10:14:36 -04:00
.ow { font-weight: bold; }
Enable ColorVariable in scss-lint
2016-11-30 08:25:25 -05:00
.w { color: $highlighted-w; }
.mf { color: $highlighted-mf; }
.mh { color: $highlighted-mh; }
.mi { color: $highlighted-mi; }
.mo { color: $highlighted-mo; }
.sb { color: $highlighted-sb; }
.sc { color: $highlighted-sc; }
.sd { color: $highlighted-sd; }
.s2 { color: $highlighted-s2; }
.se { color: $highlighted-se; }
.sh { color: $highlighted-sh; }
.si { color: $highlighted-si; }
.sx { color: $highlighted-sx; }
.sr { color: $highlighted-sr; }
.s1 { color: $highlighted-s1; }
.ss { color: $highlighted-ss; }
.bp { color: $highlighted-bp; }
.vc { color: $highlighted-vc; }
.vg { color: $highlighted-vg; }
.vi { color: $highlighted-vi; }
.il { color: $highlighted-il; }
.gc { color: $highlighted-gc; background-color: $highlighted-gc-bg; }
Copy permalink