+ This is a package with preferences and syntax highlighter for cutting edge
+Python 3 (although Python 2 is well supported too). The syntax is compatible
+with Sublime Text and Atom.
+It is meant to be a drop-in replacement for the default Python package.
+
+The main motivation behind this package was the difficulty of using modern
+Python with other common syntax highlighters. They do a good job of the 90% of
+the language, but then fail on the nuances of some very useful, but often
+overlooked features. Function annotations tend to freak out the highlighters in
+various ways. Newly introduced keywords and magic methods are slow to be
+integrated. Another issue is string highlighting, where all raw strings are
+often assumed to be regular expressions or special markup used by .format is
+completely ignored. Bumping into all of these issues on daily basis eventually
+led to the creation of this package.
+
+
+Installation Instructions
+
+This is meant to be a drop-in replacement for the default Python package.
+
+In Atom, install the MagicPython package and disable the built-in
+language-python package.
+
+In Sublime Text, install MagicPython package via "Package Control" and
+disable the built-in Python package (using
+Package Control -> Disable Package, or directly by adding "Python" to
+"ignored_packages" in the settings file).
+
+Alternatively, the package can be installed manually in both editors:
+
+
+- copy the MagicPython package into the Sublime/Atom user packages directory;
+- disable Python package;
+- enjoy.
+
+
+
+Changes and Improvements
+
+Overall, the central idea is that it should be easy to notice something odd or
+special about the code. Odd or special doesn't necessarily mean incorrect, but
+certainly worth the explicit attention.
+
+
+Annotations
+
+Annotations should not break the highlighting. They should be no more difficult
+to read at a glance than other code or comments.
+
+A typical case is having a string annotation that spans several lines by using
+implicit string concatenation. Multi-line strings are suboptimal for use in
+annotations as it may be highly undesirable to have odd indentation and extra
+whitespace in the annotation string. Of course, there is no problem using line
+continuation or even having comments mixed in with implicit string
+concatenation. All of these will be highlighted as you'd expect in any other
+place in the code.
+
+def some_func(a, # nothing fancy here, yet
+
+ b: 'Annotation: ' # implicitly
+ '"foo" for Foo, ' # concatenated
+ '"bar" for Bar, ' # annotation
+ '"other" otherwise'='otherwise'):
A more advanced use case for annotations is to actually have complex expressions
+in them, such as lambda functions, tuples, lists, dicts, sets, comprehensions.
+Admittedly, all of these might be less frequently used, but when they are, you
+can rely on them being highlighted normally in all their glorious details.
+
+# no reason why this should cause the highlighter to break
+#
+def some_func(a:
+ # annotation starts here
+ lambda x=None:
+ {key: val
+ for key, val in
+ (x if x is not None else [])
+ }
+ # annotation ends here and below is the default for 'a'
+ =42):Result annotations are handled as any other expression would be. No reason to
+worry that the body of the function would look messed up.
+
+# no reason why this should cause the highlighter to break
+#
+def some_func() -> {
+ 'Some', # comments
+ 'valid', # are
+ 'expression' # good
+ }:
+Strings
+
+Strings are used in many different ways for processing and presenting data.
+Making the highlighter more friendly towards these uses can help you concentrate
+your efforts on what matters rather than visual parsing.
+
+Raw strings are often interpreted as regular expressions. This is a bit of a
+problem, because depending on the application this may actually not be the most
+common case. Raw strings can simply be the input to some other processor, in
+which case regexp-specific highlighting is really hindering the overall
+readability. MagicPython follows a convention that a lower-case r prefix means
+a regexp string, but an upper-case R prefix means just a raw string with no
+special regexp semantics. This convention holds true for all of the legal
+combinations of prefixes. As always the syntax is biased towards Python 3, thus
+it will mark Pyhton-2-only prefixes (i.e. variations of ur) as deprecated.
+
+String formatting is often only supported for '%-style formatting', however, the
+recommended and more readable syntax used by .format is ignored. The benefits
+of using simple and readable {key} replacement fields are hindered by the fact
+that in a complex or long string expression it may not be easily apparent what
+parameters will actually be needed by .format. This is why MagicPyhton
+highlights both kinds of string formatting syntax within the appropriate string
+types (bytes don't have a .format method in Python 3, so they don't get the
+special highlighting for it, raw and unicode strings do). Additionally, the
+highlighter also validates that the formatting is following the correct syntax.
+It can help noticing an error in complex formatting expressions early.
+
+
+Numeric literals
+
+Most numbers are just regular decimal constants, but any time that octal,
+binary, hexadecimal or complex numbers are used it's worth noting that they are
+of a special type. Highlighting of Python 2 'L' integers is also supported.
+
+
+Python 3.5 features
+
+New keywords async and await are properly highlighted. Currently, these
+keywords are new and are not yet reserved, so the Python interpreter will allow
+using them as variable names. However, async and await are not recommended
+to be used as variable, class, function or module names. Introduced by
+PEP 492 in Python 3.5, they will
+become proper keywords in Python 3.7. It is very important that the highlighter
+shows their proper status when they are used as function parameter names, as
+that could otherwise be unnoticed and lead to very messy debugging down the
+road.
+
+
+Built-ins and Magic Methods
+
+Various built-in types, classes, functions, as well as magic methods are all
+highlighted. Specifically, they are highlighted when they appear as names in
+user definitions. Although it is not an error to have classes and functions that
+mask the built-ins, it is certainly worth drawing attention to, so that masking
+becomes a deliberate rather than accidental act.
+
+Highlighting built-ins in class inheritance list makes it slightly more obvious
+where standard classes are extended. It is also easier to notice some typos
+(have you ever typed Excepiton?) a little earlier.
+
+
+Parameters and Arguments
+
+MagicPython highlights keywords when they are used as parameter/argument names.
+This was mentioned for the case of async and await, but it holds true for
+all other keywords. Although the Python interpreter will produce an appropriate
+error message when reserved keywords are used as identifier names, it's still
+worth showing them early, to spare even this small debugging effort.
+
+
+Development
+
+You need npm and node.js to work on MagicPython.
+
+
+- clone the repository
+- run
make to build the local development environment
+- run
make release to build the syntax packages for Sublime Text and Atom
+(running make test also generates the "release" packages)
+
+
+Please note that we have some unit tests for the syntax scoping. We will be
+expanding and updating our test corpus. This allows us to trust that tiny
+inconsistencies will not easily creep in as we update the syntax and fix bugs.
+Use make test to run the tests regularly while updating the syntax spec.
+Currently the test files have two parts to them, separated by 3 empty newlines:
+the code to be scoped and the spec that the result must match.
+
+If you intend to submit a pull request, please follow the following guidelines:
+
+
+
+
+
+
+
+
+
+
diff --git a/params.json b/params.json
new file mode 100644
index 00000000..4757fa1b
--- /dev/null
+++ b/params.json
@@ -0,0 +1 @@
+{"name":"MagicPython","tagline":"Syntax highlighter for cutting edge Python for Sublime Text and Atom.","body":"This is a package with preferences and syntax highlighter for cutting edge\r\nPython 3 (although Python 2 is well supported too). The syntax is compatible\r\nwith [Sublime Text](http://www.sublimetext.com) and [Atom](http://atom.io).\r\nIt is meant to be a drop-in replacement for the default Python package.\r\n\r\nThe main motivation behind this package was the difficulty of using modern\r\nPython with other common syntax highlighters. They do a good job of the 90% of\r\nthe language, but then fail on the nuances of some very useful, but often\r\noverlooked features. Function annotations tend to freak out the highlighters in\r\nvarious ways. Newly introduced keywords and magic methods are slow to be\r\nintegrated. Another issue is string highlighting, where all raw strings are\r\noften assumed to be regular expressions or special markup used by `.format` is\r\ncompletely ignored. Bumping into all of these issues on daily basis eventually\r\nled to the creation of this package.\r\n\r\n\r\n## Installation Instructions\r\n\r\nThis is meant to be a drop-in replacement for the default Python package.\r\n\r\nIn **Atom**, install the `MagicPython` package and disable the built-in\r\n`language-python` package.\r\n\r\nIn **Sublime Text**, install `MagicPython` package via \"Package Control\" and\r\ndisable the built-in `Python` package (using\r\n`Package Control -> Disable Package`, or directly by adding `\"Python\"` to\r\n`\"ignored_packages\"` in the settings file).\r\n\r\nAlternatively, the package can be installed manually in both editors:\r\n\r\n- copy the MagicPython package into the Sublime/Atom user packages directory;\r\n- disable Python package;\r\n- enjoy.\r\n\r\n\r\n## Changes and Improvements\r\n\r\nOverall, the central idea is that it should be easy to notice something odd or\r\nspecial about the code. Odd or special doesn't necessarily mean incorrect, but\r\ncertainly worth the explicit attention.\r\n\r\n\r\n### Annotations\r\n\r\nAnnotations should not break the highlighting. They should be no more difficult\r\nto read at a glance than other code or comments.\r\n\r\nA typical case is having a string annotation that spans several lines by using\r\nimplicit string concatenation. Multi-line strings are suboptimal for use in\r\nannotations as it may be highly undesirable to have odd indentation and extra\r\nwhitespace in the annotation string. Of course, there is no problem using line\r\ncontinuation or even having comments mixed in with implicit string\r\nconcatenation. All of these will be highlighted as you'd expect in any other\r\nplace in the code.\r\n\r\n```python\r\ndef some_func(a, # nothing fancy here, yet\r\n\r\n b: 'Annotation: ' # implicitly\r\n '\"foo\" for Foo, ' # concatenated\r\n '\"bar\" for Bar, ' # annotation\r\n '\"other\" otherwise'='otherwise'):\r\n```\r\n\r\nA more advanced use case for annotations is to actually have complex expressions\r\nin them, such as lambda functions, tuples, lists, dicts, sets, comprehensions.\r\nAdmittedly, all of these might be less frequently used, but when they are, you\r\ncan rely on them being highlighted normally in all their glorious details.\r\n\r\n```python\r\n# no reason why this should cause the highlighter to break\r\n#\r\ndef some_func(a:\r\n # annotation starts here\r\n lambda x=None:\r\n {key: val\r\n for key, val in\r\n (x if x is not None else [])\r\n }\r\n # annotation ends here and below is the default for 'a'\r\n =42):\r\n```\r\n\r\nResult annotations are handled as any other expression would be. No reason to\r\nworry that the body of the function would look messed up.\r\n\r\n```python\r\n# no reason why this should cause the highlighter to break\r\n#\r\ndef some_func() -> {\r\n 'Some', # comments\r\n 'valid', # are\r\n 'expression' # good\r\n }:\r\n```\r\n\r\n\r\n### Strings\r\n\r\nStrings are used in many different ways for processing and presenting data.\r\nMaking the highlighter more friendly towards these uses can help you concentrate\r\nyour efforts on what matters rather than visual parsing.\r\n\r\nRaw strings are often interpreted as regular expressions. This is a bit of a\r\nproblem, because depending on the application this may actually not be the most\r\ncommon case. Raw strings can simply be the input to some other processor, in\r\nwhich case regexp-specific highlighting is really hindering the overall\r\nreadability. MagicPython follows a convention that a lower-case `r` prefix means\r\na regexp string, but an upper-case `R` prefix means just a raw string with no\r\nspecial regexp semantics. This convention holds true for all of the legal\r\ncombinations of prefixes. As always the syntax is biased towards Python 3, thus\r\nit will mark Pyhton-2-only prefixes (i.e. variations of `ur`) as deprecated.\r\n\r\nString formatting is often only supported for '%-style formatting', however, the\r\nrecommended and more readable syntax used by `.format` is ignored. The benefits\r\nof using simple and readable `{key}` replacement fields are hindered by the fact\r\nthat in a complex or long string expression it may not be easily apparent what\r\nparameters will actually be needed by `.format`. This is why MagicPyhton\r\nhighlights both kinds of string formatting syntax within the appropriate string\r\ntypes (bytes don't have a `.format` method in Python 3, so they don't get the\r\nspecial highlighting for it, raw and unicode strings do). Additionally, the\r\nhighlighter also validates that the formatting is following the correct syntax.\r\nIt can help noticing an error in complex formatting expressions early.\r\n\r\n\r\n### Numeric literals\r\n\r\nMost numbers are just regular decimal constants, but any time that octal,\r\nbinary, hexadecimal or complex numbers are used it's worth noting that they are\r\nof a special type. Highlighting of Python 2 'L' integers is also supported.\r\n\r\n\r\n### Python 3.5 features\r\n\r\nNew keywords `async` and `await` are properly highlighted. Currently, these\r\nkeywords are new and are not yet reserved, so the Python interpreter will allow\r\nusing them as variable names. However, `async` and `await` are not recommended\r\nto be used as variable, class, function or module names. Introduced by\r\n[PEP 492](https://www.python.org/dev/peps/pep-0492/) in Python 3.5, they will\r\nbecome proper keywords in Python 3.7. It is very important that the highlighter\r\nshows their proper status when they are used as function parameter names, as\r\nthat could otherwise be unnoticed and lead to very messy debugging down the\r\nroad.\r\n\r\n\r\n### Built-ins and Magic Methods\r\n\r\nVarious built-in types, classes, functions, as well as magic methods are all\r\nhighlighted. Specifically, they are highlighted when they appear as names in\r\nuser definitions. Although it is not an error to have classes and functions that\r\nmask the built-ins, it is certainly worth drawing attention to, so that masking\r\nbecomes a deliberate rather than accidental act.\r\n\r\nHighlighting built-ins in class inheritance list makes it slightly more obvious\r\nwhere standard classes are extended. It is also easier to notice some typos\r\n(have you ever typed `Excepiton`?) a little earlier.\r\n\r\n\r\n### Parameters and Arguments\r\n\r\nMagicPython highlights keywords when they are used as parameter/argument names.\r\nThis was mentioned for the case of `async` and `await`, but it holds true for\r\nall other keywords. Although the Python interpreter will produce an appropriate\r\nerror message when reserved keywords are used as identifier names, it's still\r\nworth showing them early, to spare even this small debugging effort.\r\n\r\n## Development\r\n\r\nYou need `npm` and `node.js` to work on MagicPython.\r\n\r\n- clone the repository\r\n- run `make` to build the local development environment\r\n- run `make release` to build the syntax packages for Sublime Text and Atom\r\n (running `make test` also generates the \"release\" packages)\r\n\r\nPlease note that we have some unit tests for the syntax scoping. We will be\r\nexpanding and updating our test corpus. This allows us to trust that tiny\r\ninconsistencies will not easily creep in as we update the syntax and fix bugs.\r\nUse `make test` to run the tests regularly while updating the syntax spec.\r\nCurrently the test files have two parts to them, separated by 3 empty newlines:\r\nthe code to be scoped and the spec that the result must match.\r\n\r\nIf you intend to submit a pull request, please follow the following guidelines:\r\n\r\n- keep code lines under 80 characters in length, it improves readability\r\n- please _do_ use multi-line regular expressions for any non-trivial cases like:\r\n\r\n + the regexp contains a mix of escaped and unescaped braces/parentheses\r\n + the regexp has several `|` in it\r\n + the regexp has several pairs of parentheses, especially nested ones\r\n + or the regexp is simply longer than 35 characters\r\n\r\n- always run `make test` to ensure that your changes didn't have unexpected side\r\n effects\r\n- update unit tests and add new ones if needed, keeping the test cases short\r\n whenever possible\r\n","google":"","note":"Don't delete this file! It's used internally to help with page regeneration."}
\ No newline at end of file
diff --git a/stylesheets/github-light.css b/stylesheets/github-light.css
new file mode 100644
index 00000000..872a6f4b
--- /dev/null
+++ b/stylesheets/github-light.css
@@ -0,0 +1,116 @@
+/*
+ Copyright 2014 GitHub Inc.
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+
+*/
+
+.pl-c /* comment */ {
+ color: #969896;
+}
+
+.pl-c1 /* constant, markup.raw, meta.diff.header, meta.module-reference, meta.property-name, support, support.constant, support.variable, variable.other.constant */,
+.pl-s .pl-v /* string variable */ {
+ color: #0086b3;
+}
+
+.pl-e /* entity */,
+.pl-en /* entity.name */ {
+ color: #795da3;
+}
+
+.pl-s .pl-s1 /* string source */,
+.pl-smi /* storage.modifier.import, storage.modifier.package, storage.type.java, variable.other, variable.parameter.function */ {
+ color: #333;
+}
+
+.pl-ent /* entity.name.tag */ {
+ color: #63a35c;
+}
+
+.pl-k /* keyword, storage, storage.type */ {
+ color: #a71d5d;
+}
+
+.pl-pds /* punctuation.definition.string, string.regexp.character-class */,
+.pl-s /* string */,
+.pl-s .pl-pse .pl-s1 /* string punctuation.section.embedded source */,
+.pl-sr /* string.regexp */,
+.pl-sr .pl-cce /* string.regexp constant.character.escape */,
+.pl-sr .pl-sra /* string.regexp string.regexp.arbitrary-repitition */,
+.pl-sr .pl-sre /* string.regexp source.ruby.embedded */ {
+ color: #183691;
+}
+
+.pl-v /* variable */ {
+ color: #ed6a43;
+}
+
+.pl-id /* invalid.deprecated */ {
+ color: #b52a1d;
+}
+
+.pl-ii /* invalid.illegal */ {
+ background-color: #b52a1d;
+ color: #f8f8f8;
+}
+
+.pl-sr .pl-cce /* string.regexp constant.character.escape */ {
+ color: #63a35c;
+ font-weight: bold;
+}
+
+.pl-ml /* markup.list */ {
+ color: #693a17;
+}
+
+.pl-mh /* markup.heading */,
+.pl-mh .pl-en /* markup.heading entity.name */,
+.pl-ms /* meta.separator */ {
+ color: #1d3e81;
+ font-weight: bold;
+}
+
+.pl-mq /* markup.quote */ {
+ color: #008080;
+}
+
+.pl-mi /* markup.italic */ {
+ color: #333;
+ font-style: italic;
+}
+
+.pl-mb /* markup.bold */ {
+ color: #333;
+ font-weight: bold;
+}
+
+.pl-md /* markup.deleted, meta.diff.header.from-file */ {
+ background-color: #ffecec;
+ color: #bd2c00;
+}
+
+.pl-mi1 /* markup.inserted, meta.diff.header.to-file */ {
+ background-color: #eaffea;
+ color: #55a532;
+}
+
+.pl-mdr /* meta.diff.range */ {
+ color: #795da3;
+ font-weight: bold;
+}
+
+.pl-mo /* meta.output */ {
+ color: #1d3e81;
+}
+
diff --git a/stylesheets/normalize.css b/stylesheets/normalize.css
new file mode 100644
index 00000000..30366a6e
--- /dev/null
+++ b/stylesheets/normalize.css
@@ -0,0 +1,424 @@
+/*! normalize.css v3.0.2 | MIT License | git.io/normalize */
+
+/**
+ * 1. Set default font family to sans-serif.
+ * 2. Prevent iOS text size adjust after 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/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 when focused and also mouse hovered in all browsers.
+ */
+
+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.
+ */
+
+button,
+html input[type="button"], /* 1 */
+input[type="reset"],
+input[type="submit"] {
+ -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. Address `appearance` set to `searchfield` in Safari and Chrome.
+ * 2. Address `box-sizing` set to `border-box` in Safari and Chrome
+ * (include `-moz` to future-proof).
+ */
+
+input[type="search"] {
+ -webkit-appearance: textfield; /* 1 */ /* 2 */
+ box-sizing: content-box;
+}
+
+/**
+ * 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;
+}
diff --git a/stylesheets/stylesheet.css b/stylesheets/stylesheet.css
new file mode 100644
index 00000000..b5f20c23
--- /dev/null
+++ b/stylesheets/stylesheet.css
@@ -0,0 +1,245 @@
+* {
+ box-sizing: border-box; }
+
+body {
+ padding: 0;
+ margin: 0;
+ font-family: "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;
+ font-size: 16px;
+ line-height: 1.5;
+ color: #606c71; }
+
+a {
+ color: #1e6bb8;
+ text-decoration: none; }
+ a:hover {
+ text-decoration: underline; }
+
+.btn {
+ display: inline-block;
+ margin-bottom: 1rem;
+ color: rgba(255, 255, 255, 0.7);
+ background-color: rgba(255, 255, 255, 0.08);
+ border-color: rgba(255, 255, 255, 0.2);
+ border-style: solid;
+ border-width: 1px;
+ border-radius: 0.3rem;
+ transition: color 0.2s, background-color 0.2s, border-color 0.2s; }
+ .btn + .btn {
+ margin-left: 1rem; }
+
+.btn:hover {
+ color: rgba(255, 255, 255, 0.8);
+ text-decoration: none;
+ background-color: rgba(255, 255, 255, 0.2);
+ border-color: rgba(255, 255, 255, 0.3); }
+
+@media screen and (min-width: 64em) {
+ .btn {
+ padding: 0.75rem 1rem; } }
+
+@media screen and (min-width: 42em) and (max-width: 64em) {
+ .btn {
+ padding: 0.6rem 0.9rem;
+ font-size: 0.9rem; } }
+
+@media screen and (max-width: 42em) {
+ .btn {
+ display: block;
+ width: 100%;
+ padding: 0.75rem;
+ font-size: 0.9rem; }
+ .btn + .btn {
+ margin-top: 1rem;
+ margin-left: 0; } }
+
+.page-header {
+ color: #fff;
+ text-align: center;
+ background-color: #159957;
+ background-image: linear-gradient(120deg, #155799, #159957); }
+
+@media screen and (min-width: 64em) {
+ .page-header {
+ padding: 5rem 6rem; } }
+
+@media screen and (min-width: 42em) and (max-width: 64em) {
+ .page-header {
+ padding: 3rem 4rem; } }
+
+@media screen and (max-width: 42em) {
+ .page-header {
+ padding: 2rem 1rem; } }
+
+.project-name {
+ margin-top: 0;
+ margin-bottom: 0.1rem; }
+
+@media screen and (min-width: 64em) {
+ .project-name {
+ font-size: 3.25rem; } }
+
+@media screen and (min-width: 42em) and (max-width: 64em) {
+ .project-name {
+ font-size: 2.25rem; } }
+
+@media screen and (max-width: 42em) {
+ .project-name {
+ font-size: 1.75rem; } }
+
+.project-tagline {
+ margin-bottom: 2rem;
+ font-weight: normal;
+ opacity: 0.7; }
+
+@media screen and (min-width: 64em) {
+ .project-tagline {
+ font-size: 1.25rem; } }
+
+@media screen and (min-width: 42em) and (max-width: 64em) {
+ .project-tagline {
+ font-size: 1.15rem; } }
+
+@media screen and (max-width: 42em) {
+ .project-tagline {
+ font-size: 1rem; } }
+
+.main-content :first-child {
+ margin-top: 0; }
+.main-content img {
+ max-width: 100%; }
+.main-content h1, .main-content h2, .main-content h3, .main-content h4, .main-content h5, .main-content h6 {
+ margin-top: 2rem;
+ margin-bottom: 1rem;
+ font-weight: normal;
+ color: #159957; }
+.main-content p {
+ margin-bottom: 1em; }
+.main-content code {
+ padding: 2px 4px;
+ font-family: Consolas, "Liberation Mono", Menlo, Courier, monospace;
+ font-size: 0.9rem;
+ color: #383e41;
+ background-color: #f3f6fa;
+ border-radius: 0.3rem; }
+.main-content pre {
+ padding: 0.8rem;
+ margin-top: 0;
+ margin-bottom: 1rem;
+ font: 1rem Consolas, "Liberation Mono", Menlo, Courier, monospace;
+ color: #567482;
+ word-wrap: normal;
+ background-color: #f3f6fa;
+ border: solid 1px #dce6f0;
+ border-radius: 0.3rem; }
+ .main-content pre > code {
+ padding: 0;
+ margin: 0;
+ font-size: 0.9rem;
+ color: #567482;
+ word-break: normal;
+ white-space: pre;
+ background: transparent;
+ border: 0; }
+.main-content .highlight {
+ margin-bottom: 1rem; }
+ .main-content .highlight pre {
+ margin-bottom: 0;
+ word-break: normal; }
+.main-content .highlight pre, .main-content pre {
+ padding: 0.8rem;
+ overflow: auto;
+ font-size: 0.9rem;
+ line-height: 1.45;
+ border-radius: 0.3rem; }
+.main-content pre code, .main-content pre tt {
+ display: inline;
+ max-width: initial;
+ padding: 0;
+ margin: 0;
+ overflow: initial;
+ line-height: inherit;
+ word-wrap: normal;
+ background-color: transparent;
+ border: 0; }
+ .main-content pre code:before, .main-content pre code:after, .main-content pre tt:before, .main-content pre tt:after {
+ content: normal; }
+.main-content ul, .main-content ol {
+ margin-top: 0; }
+.main-content blockquote {
+ padding: 0 1rem;
+ margin-left: 0;
+ color: #819198;
+ border-left: 0.3rem solid #dce6f0; }
+ .main-content blockquote > :first-child {
+ margin-top: 0; }
+ .main-content blockquote > :last-child {
+ margin-bottom: 0; }
+.main-content table {
+ display: block;
+ width: 100%;
+ overflow: auto;
+ word-break: normal;
+ word-break: keep-all; }
+ .main-content table th {
+ font-weight: bold; }
+ .main-content table th, .main-content table td {
+ padding: 0.5rem 1rem;
+ border: 1px solid #e9ebec; }
+.main-content dl {
+ padding: 0; }
+ .main-content dl dt {
+ padding: 0;
+ margin-top: 1rem;
+ font-size: 1rem;
+ font-weight: bold; }
+ .main-content dl dd {
+ padding: 0;
+ margin-bottom: 1rem; }
+.main-content hr {
+ height: 2px;
+ padding: 0;
+ margin: 1rem 0;
+ background-color: #eff0f1;
+ border: 0; }
+
+@media screen and (min-width: 64em) {
+ .main-content {
+ max-width: 64rem;
+ padding: 2rem 6rem;
+ margin: 0 auto;
+ font-size: 1.1rem; } }
+
+@media screen and (min-width: 42em) and (max-width: 64em) {
+ .main-content {
+ padding: 2rem 4rem;
+ font-size: 1.1rem; } }
+
+@media screen and (max-width: 42em) {
+ .main-content {
+ padding: 2rem 1rem;
+ font-size: 1rem; } }
+
+.site-footer {
+ padding-top: 2rem;
+ margin-top: 2rem;
+ border-top: solid 1px #eff0f1; }
+
+.site-footer-owner {
+ display: block;
+ font-weight: bold; }
+
+.site-footer-credits {
+ color: #819198; }
+
+@media screen and (min-width: 64em) {
+ .site-footer {
+ font-size: 1rem; } }
+
+@media screen and (min-width: 42em) and (max-width: 64em) {
+ .site-footer {
+ font-size: 1rem; } }
+
+@media screen and (max-width: 42em) {
+ .site-footer {
+ font-size: 0.9rem; } }
From 3c8a40d921c996e90bb85684b268cad54b9a5666 Mon Sep 17 00:00:00 2001
From: Yury Selivanov