Article about this journal's infrastructure #3

Closed
fnmain wants to merge 11 commits from how_to_infra into master
14 changed files with 2986 additions and 0 deletions

2
.gitattributes vendored Normal file
View file

@ -0,0 +1,2 @@
assets/ filter=lfs diff=lfs merge=lfs -text
templates/images/ filter=lfs diff=lfs merge=lfs -text

7
.woodpecker.yml Normal file
View file

@ -0,0 +1,7 @@
steps:
- name: build
image: journal
commands:
- bruin-journal-gen
volumes:
- /var/woodpecker:/var/woodpecker

BIN
assets/giga_chad.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.7 KiB

4
assets/the_pipeline.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 201 KiB

View file

@ -0,0 +1,93 @@
# How to Run a Journal
Hi! I'm Isaac Mills, I'm the guy managing the infrastructure behind Compute! In this article, I'd like to talk about just that: the infra behind this journal, how it all works, and why it is the way it is.
## Plain text
Plain text is kind of insane. It's capable of being anything, and can also be transmuted into anything. It's infinite extensibility makes it a powerful tool that every developer should have in their arsenal. For this journal, we use a lot of plain text. In fact, the article you're reading right now is written in plain text, _not with some web UI_. A while back, I found a markup language called [djot](https://djot.net). It was created by the same person who created CommonMark, a flavor of markdown, to be easier to parse and more featureful. Below is some example djot
```djot
# Heading
paragraph
*bold* _italic_ _*bold italic*_ {-strikethorugh-} {+underline+}
- list
- list
1. list
2. list
```
The benefit of using djot is that it compiles directly to HTML, thus the jorunalists who have joined Compute don't need to learn HTML to write articles. They also don't need to learn a clunky slow website editor like Wix or Squarespace.
This is another superpower of plain text, if we used Wix for our website, our journalists would need to learn how to use the Wix UI, and how to write articles _for_ that UI. If we needed to change our tooling at any time, they would need to re-learn everything for _that_ tool. Not only that, but we would need to port the entire journal (_every_ article), to use that new tooling. This is not so with plain text, if things change in the pipeline, or even if you're just joining the journal, there's no need to re-learn how to write text. At worst, you just need to convert the plain text to another format of plain text (djot to HTML for example). All our journalists need to know how to do is write their articles in djot, and submit it to the team via the pipeline
## The Pipeline
![A flowchart of the pipeline](assets/the_pipeline.svg)
Pictured above is the full pipeline that articles go through in order to reach you readers at home, it goes like this
1. Articles are written by our journalists in a plain text format (djot in our case)
2. Once an article is done, the journalist who wrote the article opens a pull request on our git repository with their new article and associated assets
3. The article can be reviewed by the team and edits can be made by them.
4. Once the article has been edited, the pull request gets merged into the main branch of our git repository, which is where the articles you see live
5. From there, the article goes through CI and gets deployed (we'll get into that in more detail later)
Basically, this is just the workflow you would use for code, but adapted for journalism. In other words, no learning curve for our journalists! And if they do need to learn it, then this is information that they *should* know _anyway_. The workflow you see above has been in the making since git was created in 2005, with the sole purpose of efficiently moving code from development, into production. The more efficiently we can accomplish that, and the more bad code we can filter out of production, the better. If this workflow has worked for nearly 2 decades for a pathologically huge project like the Linux kernel (which git was tailor-made to handle), the better.
## CI
Consider the following: If I'm accepting untrusted code from the public into my open source project, and I need that code to be production ready, how can I ensure that the code I accept _is_ actually production ready. The answer is with _continuous integration_, or _CI_. The idea is that every piece of code submitted to an open source project would undergo automated testing, linting, and checking to ensure that nothing will break upon merging the code into the production code base. For a project like [`egui`](https://lib.rs/crates/egui), their CI pipeline contains 19 checks.
Their pipeline checks if the library with your new code compiles to every platform it's compatible with, with every feature enabled. It also makes sure that your code is well-formatted, contains no conflicts of license, uses no libraries banned by the project, and contains no security advisories. The _only_ way this many checks can be done on every git commit, is through CI, GitHub Actions in egui's case.
If you're making an open source project, and it becomes big enough to pull in contributions from a lot of developers, CI can not only serve as a means to filter bugs out of pull requests, but also as a way to communicate to open source developers _what a project wants_ out of their code. Instead of having to read a big `CONTRIBUTORS.md` file to get an idea of that, developers can know that their code is good quality if it just passes CI.
Fortunately, the level of CI I've described above is not required for journalism. Our CI simply compiles our journalists' unreviewed articles, and serves them on an un-indexed (not visible on production) web page so that they and the team can preview their work before merging it. Our CI is also responsible for indexing and publishing finished articles onto our production website. We could get the CI to do an automated grammar check, but there are too many tech-terms that the checker would need to know in order for it to pass consistently.
## Deployment
Deployment is the most complex part of our pipeline; getting the written, production ready articles, onto the website _you_ are reading this on. As I said earlier in the article, we use CI to compile and index finished articles. The CI tool we use is called [Woodpecker CI](https://woodpecker-ci.org/), a self-hosted docker-based CI tool. Self-hosted basically means that we can run the CI tool on the same server we use to serve our website, making deployment to there as easy as moving the generated files into the directory that our web server is serving (NGINX in our case). What's important to know is that when a pull request is opened on this journal's git repository, and when a pull request is merged into production, Woodpecker CI will run a custom program that I wrote in Rust to...
- Compile djot articles to HTML
- Minify and compress compiled HTML
- Index articles with our search engine
Because our CI tool is running this code, we can know which articles need compilation, who wrote those articles, and if any articles need to be deleted. Our CI tools will put our code in the working directory of our git repo. And via environment variables, the CI tool will tell us which files have changed, how the pipeline was triggered (via pull request, code push, etc.), as well as which git branch production resides in, and which branch our code is currently in. Our code can then use this information to...
- Stat the changed files, which is how we know which files need to be compiled, and which files have been deleted
- Run a blame on new articles, which is how we figure out who wrote them
- See if we are we have changed the production branch, and index new articles if so
In our case, what CI allows us to do is keep as much of our pipeline as automated as possible. Our journalists should only need to focus on writing good articles, not wrestling with tooling. Coming back to the benefits of plain text, git is an extremely powerful tool for working with plain text.
- It allows us to separate the WIP and the finished articles
- It allows us to keep an accurate and automated reference of who wrote and edited each article
- It allows a copy of the entire journal to be stored in many different places as backups.
- It allows us to easily sync new articles and changes to any git-compatible software forge of our choice (we use [forgejo](https://forgejo.org/))
By and large, with the power of git, plain text can fill more use cases than you could possibly imagine.
## Our webpages (and staying based)
![An image of the giga-chad](assets/giga_chad.jpg)
The modern web sucks. Most webpages are not only bloated with ads, cookie banners, autoplaying BS, popups and the like; most webpages are also inundated with copious amounts of JavaScript. We only use JavaScript in 2 places
1. On our homepage to power the search bar and display articles
2. Our web design tool, Webflow, bundles a small amount of JavaScript in every page (more on that later)
Other than that, the actual article pages, such as this one, depend on nothing but the JavaScript that Webflow bundles in. And for our homepage, it's built and optimized so it can be served statically with it's _one_ dependency. Basically, I wanted to make our website as [suckless](https://suckless.org/philosophy/) (as lightweight, and as free from bloat) as possible. I say _I_ wanted to because our founder wanted to use Wix originally, yuck.
Instead of _that_, I used [Webflow](https://webflow.com/) to design our webpages. For a one-time fee of $24, you can have access to the Webflow editor for 1 month, and then export your web pages to HTML/CSS/JS. Webflow is very different from your average Wix/Squarespace, those editors are designed for non-programmers who don't know and don't want to know HTML or CSS. Webflow is an editor for _developers_ that know what they're doing. It gives you the full power of HTML and CSS in a responsive, visual editor; making it an incredibly flexible tool capable of generating very based and performant webpages. Unlike the latter tools which generate bloated and obfuscated garbage.
## Search engine
I was expecting to have to put most of the effort of getting our website ready into getting a search bar working. Instead, I found [Meilisearch](https://www.meilisearch.com/), and I fell in love immediately. Not only is it incredibly easy to deploy _and_ use, but it's also much more than just a search engine. You can basically use it as a way to index and display pages on your website. And by using [instantsearch-meilisearch](https://github.com/meilisearch/meilisearch-js-plugins/tree/main/packages/instant-meilisearch) (that one dependency that our homepage uses), we can just make an article browser and search experience, _incredibly_ easily. It's not just easy on the front-end, the [meilisearch-sdk](https://lib.rs/crates/meilisearch-sdk) is also incredibly easy to use to index articles. Meilisearch, despite being a complex full-text search engine, is incredibly simple to use. Just initialize a search index, and send documents to it in a structured JSON format. On the front end, you can get that JSON back with a simple HTTP request containing the search query and field constraints (sorting, only sending snippets of big fields, etc.). All in all, Meilisearch's unexpected simplicity suprised me in a big way, and it made my job so _sooo_ much easier!
## In conclusion
Computers have an inconcievable amount of potential, but they're only as smart as their programmer. When you're building something with a computer, it's often much better to do more with less, than less with more. Don't use 17 different JavaScript frameworks with your hypervisor GPU WEB2.0 interface-driven scripting framework to drive your map/reduce-aware proxy-oriented software API. Just start simple, build simple, and if you need complexity, build it with more simple. Often times in computer software, plain text is the simplest place to start. From there, you can add complexity by processing the plain text in some way (hell, I made a whole ass [PowerPoint clone](https://github.com/StratusFearMe21/grezi-next) centered around plain text). If you need more than plain text, try the terminal. And if you need more than that, try [wxWidgets](https://www.wxwidgets.org/). The point I'm trying to make here is that bloat is your enemy, and it's often better for you, your team, and your users to just KISS (Keep it simple, stupid!)

70
templates/article.html Normal file
View file

@ -0,0 +1,70 @@
<!DOCTYPE html><!-- This site was created in Webflow. https://www.webflow.com -->
<!-- Last Published: Fri Apr 05 2024 16:19:10 GMT+0000 (Coordinated Universal Time) -->
<html data-wf-page="66101585e19be8199060db0a" data-wf-site="66007382143b5f99deb20223">
<head>
<meta charset="utf-8">
<title>{{title}}</title>
<meta content="{{title}}" property="og:title">
<meta content="article" property="og:type">
<meta content="/images/logo-z.png" property="og:image">
<meta content="/images/logo-z.png" property="twitter:image">
<meta property="og:image:width" content="310">
<meta property="og:image:height" content="310">
<meta property="og:image:alt" content="The Compute logo">
<meta content="{{published_og}}" property="og:article:published_time">
<meta content="{{modified_og}}" property="og:article:modified_time">
{% for author in authors %}
<meta content="{{ author.full_name | split(pat=' ') | nth(n=0) }}" property="og:article:author:first_name">
<meta content="{{ author.full_name | split(pat=' ') | nth(n=1) }}" property="og:article:author:last_name">
<meta content="{{author.username}}" property="og:article:author:username">
{% endfor %}
<meta content="Compute: Lake Braddock's Comp-sci journal" property="og:site_name">
<meta content="{{title}}" property="twitter:title">
<meta content="width=device-width, initial-scale=1" name="viewport">
<meta content="Webflow" name="generator">
<link href="/css/normalize.css" rel="stylesheet" type="text/css">
<link href="/css/webflow.css" rel="stylesheet" type="text/css">
<link href="/css/compute-c23f91.webflow.css" rel="stylesheet" type="text/css">
<script
type="text/javascript">!function (o, c) {var n = c.documentElement, t = " w-mod-"; n.className += t + "js", ("ontouchstart" in o || o.DocumentTouch && c instanceof DocumentTouch) && (n.className += t + "touch")}(window, document);</script>
<link href="/images/favicon.ico" rel="shortcut icon" type="image/x-icon">
<link href="/images/webclip.png" rel="apple-touch-icon">
</head>
<body>
<div data-animation="default" data-collapse="medium" data-duration="400" data-easing="ease" data-easing2="ease"
role="banner" class="w-nav">
<div class="container-2 w-container">
<a href="/" class="w-nav-brand"><img src="/images/logo-z.svg" loading="lazy" alt="Compute Logo" height="64"></a>
<nav role="navigation" class="w-nav-menu">
<a href="/" class="w-nav-link">Home</a>
</nav>
<div class="w-nav-button">
<div class="w-icon-nav-menu"></div>
</div>
</div>
</div>
<div class="w-layout-vflex flex-block-2 purple" style="align-items: flex-start;">
<h1 class="heading-8" style="font-size: 72px; margin-top: 20px;">{{title}}</h1>
<div class="w-layout-hflex flex-block-3" style="margin-bottom: 10px;">
{% for author in authors %}
<img src="{{author.avatar_url}}" loading="lazy" width="32" height="32" alt="{{author.full_name}}'s Avatar"
class="image">
<div class="text-block-2">{{author.full_name}}</div>
{% endfor %}
</div>
<p style="margin-left: 20px;color: white;font-size: 16px">{{published}}</p>
</div>
<article>{{body}}</article>
<hr>
<a href="/">
<h3 style="margin-left: 20px;min-height:200px">Read more from Compute</h3>
</a>
<script src="https://d3e54v103j8qbb.cloudfront.net/js/jquery-3.5.1.min.dc5e7f18c8.js?site=66007382143b5f99deb20223"
type="text/javascript" integrity="sha256-9/aliU8dGd2tb6OSsuzixeV4y/faTqgFtohetphbbj0="
crossorigin="anonymous"></script>
<script src="/js/webflow.js" type="text/javascript"></script>
</body>
</html>

1
templates/assets Symbolic link
View file

@ -0,0 +1 @@
../assets/

View file

@ -0,0 +1,276 @@
:root {
--white: white;
--black: black;
}
.w-layout-vflex {
flex-direction: column;
align-items: flex-start;
display: flex;
}
.w-layout-blockcontainer {
max-width: 940px;
margin-left: auto;
margin-right: auto;
display: block;
}
.w-layout-grid {
grid-row-gap: 16px;
grid-column-gap: 16px;
grid-template-rows: auto auto;
grid-template-columns: 1fr 1fr;
grid-auto-columns: 1fr;
display: grid;
}
.w-layout-hflex {
flex-direction: row;
align-items: flex-start;
display: flex;
}
@media screen and (max-width: 991px) {
.w-layout-blockcontainer {
max-width: 728px;
}
}
@media screen and (max-width: 767px) {
.w-layout-blockcontainer {
max-width: none;
}
}
article {
margin: 20px;
}
h1 {
margin-top: auto;
font-size: 128px;
font-weight: 700;
}
p {
margin-bottom: 10px;
margin-top: 10px;
font-size: 18px;
}
li {
font-size: 18px;
}
.utility-page-wrap {
justify-content: center;
align-items: center;
width: 100vw;
max-width: 100%;
height: 100vh;
max-height: 100%;
display: flex;
}
.utility-page-content {
text-align: center;
flex-direction: column;
width: 260px;
display: flex;
}
.utility-page-form {
flex-direction: column;
align-items: stretch;
display: flex;
}
.container-2 {
padding-top: 8px;
padding-bottom: 8px;
}
.flex-block-2 {
justify-content: center;
align-items: center;
}
.flex-block-2.purple {
color: #333;
background-color: #552a85;
flex-flow: column;
justify-content: space-around;
padding-top: 0;
display: flex;
overflow-x: hidden;
}
.heading-3 {
color: #f6c415;
font-size: 22vw;
overflow-x: hidden;
}
.heading-3.wrapped-compute {
display: none;
}
.heading-3.unwrapped-compute.compute-gradiant {
-webkit-text-fill-color: transparent;
background-image: linear-gradient(90deg, #f6c415, #f6c41533);
-webkit-background-clip: text;
background-clip: text;
margin-bottom: 20px;
}
.text-block {
color: #fff;
text-align: left;
margin-left: 20px;
margin-right: 20px;
font-size: 18px;
}
.container-3 {
height: 20vh;
margin-top: 8px;
margin-bottom: 8px;
padding-left: 16px;
padding-right: 16px;
}
.heading-4 {
margin-top: 0;
margin-bottom: 0;
font-size: 5vw;
}
.heading-5 {
margin-top: 0;
margin-bottom: 0;
}
.heading-6 {
margin-top: 0;
margin-bottom: 0;
font-size: 64px;
}
.paragraph {
font-size: 24px;
}
.heading-7 {
font-size: 64px;
}
.grid {
padding-left: 16px;
padding-right: 16px;
}
.heading-8 {
color: #f6c415;
text-align: left;
-webkit-text-fill-color: transparent;
background-image: linear-gradient(90deg, #f6c415, rgba(246, 196, 21, .3));
-webkit-background-clip: text;
background-clip: text;
margin-bottom: 20px;
margin-left: 20px;
margin-right: 20px;
}
.image {
-webkit-text-fill-color: inherit;
background-clip: border-box;
border-radius: 50%;
margin-bottom: 0;
margin-left: 20px;
margin-right: 10px;
}
.flex-block-3 {
align-items: center;
margin-bottom: 20px;
}
.text-block-2 {
color: #fff;
font-size: 18px;
}
@media screen and (max-width: 991px) {
.heading-3.unwrapped-compute.compute-gradiant {
height: 22vw;
min-height: 0%;
}
.grid {
grid-template-columns: 1fr;
}
.heading-8 {
margin-bottom: 20px;
font-size: 64px;
}
}
@media screen and (max-width: 767px) {
.heading-3.wrapped-compute.compute-gradiant {
-webkit-text-fill-color: transparent;
background-image: linear-gradient(90deg, #f6c415, #f6c41533);
-webkit-background-clip: text;
background-clip: text;
margin-bottom: 20px;
display: block;
}
.ais-Hits-item {
margin-bottom: 1em;
width: calc(50% - 1rem);
}
.heading-3.unwrapped-compute.compute-gradiant {
display: none;
}
.heading-8 {
font-size: 64px;
}
}
@media screen and (max-width: 479px) {
.flex-block-2.purple {
flex-flow: column;
justify-content: space-around;
}
.heading-3 {
font-size: 48vw;
}
.heading-3.wrapped-compute {
display: block;
}
.heading-3.wrapped-compute.compute-gradiant {
-webkit-text-fill-color: transparent;
background-image: linear-gradient(90deg, #f6c415, #f6c41533);
-webkit-background-clip: text;
background-clip: text;
min-height: 48vw;
margin-top: 0;
margin-bottom: 10px;
overflow-y: hidden;
}
.heading-3.unwrapped-compute {
display: none;
}
.text-block {
font-size: 6vw;
}
}

355
templates/css/normalize.css vendored Normal file
View file

@ -0,0 +1,355 @@
/*! normalize.css v3.0.3 | MIT License | github.com/necolas/normalize.css */
/**
* 1. Set default font family to sans-serif.
* 2. Prevent iOS and IE text size adjust after device orientation change,
* without disabling user zoom.
*/
html {
font-family: sans-serif;
/* 1 */
-ms-text-size-adjust: 100%;
/* 2 */
-webkit-text-size-adjust: 100%;
/* 2 */
}
/**
* Remove default margin.
*/
body {
margin: 0;
}
/* HTML5 display definitions
========================================================================== */
/**
* Correct `block` display not defined for any HTML5 element in IE 8/9.
* Correct `block` display not defined for `details` or `summary` in IE 10/11
* and Firefox.
* Correct `block` display not defined for `main` in IE 11.
*/
article,
aside,
details,
figcaption,
figure,
footer,
header,
hgroup,
main,
menu,
nav,
section,
summary {
display: block;
}
/**
* 1. Correct `inline-block` display not defined in IE 8/9.
* 2. Normalize vertical alignment of `progress` in Chrome, Firefox, and Opera.
*/
audio,
canvas,
progress,
video {
display: inline-block;
/* 1 */
vertical-align: baseline;
/* 2 */
}
/**
* Prevent modern browsers from displaying `audio` without controls.
* Remove excess height in iOS 5 devices.
*/
audio:not([controls]) {
display: none;
height: 0;
}
/**
* Address `[hidden]` styling not present in IE 8/9/10.
* Hide the `template` element in IE 8/9/10/11, Safari, and Firefox < 22.
*/
[hidden],
template {
display: none;
}
/* Links
========================================================================== */
/**
* Remove the gray background color from active links in IE 10.
*/
a {
background-color: transparent;
}
/**
* Improve readability of focused elements when they are also in an
* active/hover state.
*/
a:active,
a:hover {
outline: 0;
}
/* Text-level semantics
========================================================================== */
/**
* Address styling not present in IE 8/9/10/11, Safari, and Chrome.
*/
abbr[title] {
border-bottom: 1px dotted;
}
/**
* Address style set to `bolder` in Firefox 4+, Safari, and Chrome.
*/
b,
strong {
font-weight: bold;
}
/**
* Address styling not present in Safari and Chrome.
*/
dfn {
font-style: italic;
}
/**
* Address variable `h1` font-size and margin within `section` and `article`
* contexts in Firefox 4+, Safari, and Chrome.
*/
h1 {
font-size: 2em;
margin: 0.67em 0;
}
/**
* Address styling not present in IE 8/9.
*/
mark {
background: #ff0;
color: #000;
}
/**
* Address inconsistent and variable font size in all browsers.
*/
small {
font-size: 80%;
}
/**
* Prevent `sub` and `sup` affecting `line-height` in all browsers.
*/
sub,
sup {
font-size: 75%;
line-height: 0;
position: relative;
vertical-align: baseline;
}
sup {
top: -0.5em;
}
sub {
bottom: -0.25em;
}
/* Embedded content
========================================================================== */
/**
* Remove border when inside `a` element in IE 8/9/10.
*/
img {
border: 0;
}
/**
* Correct overflow not hidden in IE 9/10/11.
*/
svg:not(:root) {
overflow: hidden;
}
/* Grouping content
========================================================================== */
/**
* Address margin not present in IE 8/9 and Safari.
*/
figure {
margin: 1em 40px;
}
/**
* Address differences between Firefox and other browsers.
*/
hr {
box-sizing: content-box;
height: 0;
}
/**
* Contain overflow in all browsers.
*/
pre {
overflow: auto;
}
/**
* Address odd `em`-unit font size rendering in all browsers.
*/
code,
kbd,
pre,
samp {
font-family: monospace, monospace;
font-size: 1em;
}
/* Forms
========================================================================== */
/**
* Known limitation: by default, Chrome and Safari on OS X allow very limited
* styling of `select`, unless a `border` property is set.
*/
/**
* 1. Correct color not being inherited.
* Known issue: affects color of disabled elements.
* 2. Correct font properties not being inherited.
* 3. Address margins set differently in Firefox 4+, Safari, and Chrome.
*/
button,
input,
optgroup,
select,
textarea {
color: inherit;
/* 1 */
font: inherit;
/* 2 */
margin: 0;
/* 3 */
}
/**
* Address `overflow` set to `hidden` in IE 8/9/10/11.
*/
button {
overflow: visible;
}
/**
* Address inconsistent `text-transform` inheritance for `button` and `select`.
* All other form control elements do not inherit `text-transform` values.
* Correct `button` style inheritance in Firefox, IE 8/9/10/11, and Opera.
* Correct `select` style inheritance in Firefox.
*/
button,
select {
text-transform: none;
}
/**
* 1. Avoid the WebKit bug in Android 4.0.* where (2) destroys native `audio`
* and `video` controls.
* 2. Correct inability to style clickable `input` types in iOS.
* 3. Improve usability and consistency of cursor style between image-type
* `input` and others.
* 4. CUSTOM FOR WEBFLOW: Removed the input[type="submit"] selector to reduce
* specificity and defer to the .w-button selector
*/
button,
html input[type="button"],
input[type="reset"] {
-webkit-appearance: button;
/* 2 */
cursor: pointer;
/* 3 */
}
/**
* Re-set default cursor for disabled elements.
*/
button[disabled],
html input[disabled] {
cursor: default;
}
/**
* Remove inner padding and border in Firefox 4+.
*/
button::-moz-focus-inner,
input::-moz-focus-inner {
border: 0;
padding: 0;
}
/**
* Address Firefox 4+ setting `line-height` on `input` using `!important` in
* the UA stylesheet.
*/
input {
line-height: normal;
}
/**
* It's recommended that you don't attempt to style these elements.
* Firefox's implementation doesn't respect box-sizing, padding, or width.
*
* 1. Address box sizing set to `content-box` in IE 8/9/10.
* 2. Remove excess padding in IE 8/9/10.
*/
input[type='checkbox'],
input[type='radio'] {
box-sizing: border-box;
/* 1 */
padding: 0;
/* 2 */
}
/**
* Fix the cursor style for Chrome's increment/decrement buttons. For certain
* `font-size` values of the `input`, it causes the cursor style of the
* decrement button to change from `default` to `text`.
*/
input[type='number']::-webkit-inner-spin-button,
input[type='number']::-webkit-outer-spin-button {
height: auto;
}
/**
* 1. CUSTOM FOR WEBFLOW: changed from `textfield` to `none` to normalize iOS rounded input
* 2. CUSTOM FOR WEBFLOW: box-sizing: content-box rule removed
* (similar to normalize.css >=4.0.0)
*/
input[type='search'] {
-webkit-appearance: none;
/* 1 */
}
/**
* Remove inner padding and search cancel button in Safari and Chrome on OS X.
* Safari (but not Chrome) clips the cancel button when the search input has
* padding (and `textfield` appearance).
*/
input[type='search']::-webkit-search-cancel-button,
input[type='search']::-webkit-search-decoration {
-webkit-appearance: none;
}
/**
* Define consistent border, margin, and padding.
*/
fieldset {
border: 1px solid #c0c0c0;
margin: 0 2px;
padding: 0.35em 0.625em 0.75em;
}
/**
* 1. Correct `color` not being inherited in IE 8/9/10/11.
* 2. Remove padding so people aren't caught out if they zero out fieldsets.
*/
legend {
border: 0;
/* 1 */
padding: 0;
/* 2 */
}
/**
* Remove default vertical scrollbar in IE 8/9/10/11.
*/
textarea {
overflow: auto;
}
/**
* Don't inherit the `font-weight` (applied by a rule above).
* NOTE: the default cannot safely be changed in Chrome and Safari on OS X.
*/
optgroup {
font-weight: bold;
}
/* Tables
========================================================================== */
/**
* Remove most spacing between table cells.
*/
table {
border-collapse: collapse;
border-spacing: 0;
}
td,
th {
padding: 0;
}

2141
templates/css/webflow.css Normal file

File diff suppressed because it is too large Load diff

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

View file

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" width="310" height="310"><path d="m185.078 57.813.274 84.386.115-.115 20.619 20.62-20.602 20.6.063 19.03h54.144l-53.94 53.941.265 47.532s5.331 3.357 10.125 3.172 46.038-18.011 54.388-24.368 32.647-29.674 37.282-36.22c4.634-6.547 21.424-62.616 20.916-71.278-.508-8.661-7.786-29.062-7.786-29.062s13.016-5.257 24.202-23.047c11.185-17.79 13.378-27.956 7.181-39.988-6.196-12.033-61.187.289-61.187.289s-47.064-25.492-86.059-25.492zm121.647 32.75c4.449-.054 8.763.277 12.363 1.253 14.398 3.906-25.717 41.653-25.717 41.653l-14.54-39.13s14.546-3.616 27.894-3.776zm-58.229 10.011 2.33 24.137-20.644 11.42-22.446-20.809zm-63.55-42.761.37 84.386-.117-.114-20.46 20.776 20.757 20.444.083 19.029-54.143.413 54.349 53.528.098 47.532s-5.305 3.398-10.1 3.25c-4.795-.15-46.175-17.66-54.573-23.953S88.338 253.68 83.654 247.17s-21.901-62.45-21.46-71.116c.443-8.665 7.564-29.121 7.564-29.121s-13.055-5.157-24.376-22.862c-11.32-17.705-13.59-27.853-7.486-39.932 6.105-12.08 61.188-.178 61.188-.178s46.868-25.85 85.862-26.147zM63.552 91.489c-4.449-.02-8.76.344-12.353 1.348-14.368 4.016 26.034 41.455 26.034 41.455l14.242-39.238s-14.574-3.506-27.923-3.565zm58.304 9.568-2.146 24.154 20.73 11.262 22.287-20.98z" style="fill:#572c84;stroke:#f6c318;stroke-width:5;stroke-linejoin:round" transform="rotate(.218 7364.703 -7830.871)"/></svg>

After

Width:  |  Height:  |  Size: 1.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.7 KiB

36
templates/js/webflow.js Normal file

File diff suppressed because one or more lines are too long