├── .github
    └── PULL_REQUEST_TEMPLATE.md
├── CONTRIBUTING.md
├── LICENSE.md
├── README.md
└── riotjs-style-guide.svg


/.github/PULL_REQUEST_TEMPLATE.md:
--------------------------------------------------------------------------------
 1 | ## Summary
 2 | 
 3 | Proposed changes:
 4 | 
 5 | * ..
 6 | * ..
 7 | 
 8 | Resolves # .
 9 | 
10 | ## Checklist
11 | 
12 | * [ ] The changes only affect or contain one style guide rule or section.
13 | * [ ] The changes are in [style guide format](https://github.com/voorhoede/riotjs-style-guide/blob/master/CONTRIBUTING.md#format).
14 | * [ ] The new style guide section has an entry in the [Table of Contents](https://github.com/voorhoede/riotjs-style-guide/blob/master/README.md#table-of-contents) (only if changes introduce new section).
15 | * [ ] The changes can be merged into the target branch without conflicts. 
16 | 


--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
 1 | # Contributing
 2 | 
 3 | For new additions or changes to the guide, create a branch and submit a Pull Request.
 4 | Only add/change 1 style guide rule per Pull Request.
 5 | The Pull Request serves as a place to discuss and refine the additions/changes.
 6 | 
 7 | ## Format
 8 | 
 9 | Use [Github Flavoured Markdown](https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown).
10 | 
11 | Use short and descriptive rule names as 2nd level heading:
12 | 
13 | ```markdown
14 | ## Keep expressions simple
15 | ```
16 |   
17 | Optionally add an short summary for the rule.
18 | 
19 | ```markdown
20 | RiotJS allows any type of JavaScript expression as inline expression (`{ expression }`).
21 | ```
22 | 
23 | Describe **why** the rule exists. What purpose does it serve?
24 | 
25 | ```markdown
26 | ### Why?
27 | 
28 | Keep inline expressions simple because:
29 | 
30 | * complex inline expressions are hard to read
31 | * inline expressions cant be reused
32 | ```
33 | 
34 | Describe **how** (and how not) to apply the rule.
35 | 
36 | ```markdown
37 | ### How?
38 | 
39 | If an expression becomes complex, move it to a tag property or method.
40 | ```
41 | 
42 | When using code snippets:
43 | * use <code>```html</code> for improved syntax highlighting of Riot tag elements. 
44 | * use <code>```javascript</code> for improved syntax highlighting when script only.
45 | * use `<!-- recommended -->` and `/* recommended */` or `<!-- avoid -->` and `/* avoid */` at the start of the snippet to indicate if it's a good or bad practice.
46 | 
47 | For example:
48 | 
49 | ```html
50 | <!-- recommended -->
51 | <datetime>{ this.timestamp() }</datetime>
52 | 
53 | <!-- avoid -->
54 | <datetime>
55 |     { ((new Date()).getUTCMonth()+1) + ' ' + (new Date()).getUTCFullYear() }
56 | </datetime>
57 | ```
58 | 
59 | Add a [↑ back to Table of Contents](README.md#table-of-contents) link at the end of each rule, so the reader can easily navigate back:
60 | 
61 | ```markdown
62 | [↑ back to Table of Contents](#table-of-contents)
63 | ```
64 | 


--------------------------------------------------------------------------------
/LICENSE.md:
--------------------------------------------------------------------------------
  1 | # CC0 1.0 Universal
  2 | 
  3 | ## Statement of Purpose
  4 | 
  5 | The laws of most jurisdictions throughout the world automatically confer
  6 | exclusive Copyright and Related Rights (defined below) upon the creator and
  7 | subsequent owner(s) (each and all, an "owner") of an original work of
  8 | authorship and/or a database (each, a "Work").
  9 | 
 10 | Certain owners wish to permanently relinquish those rights to a Work for the
 11 | purpose of contributing to a commons of creative, cultural and scientific
 12 | works ("Commons") that the public can reliably and without fear of later
 13 | claims of infringement build upon, modify, incorporate in other works, reuse
 14 | and redistribute as freely as possible in any form whatsoever and for any
 15 | purposes, including without limitation commercial purposes. These owners may
 16 | contribute to the Commons to promote the ideal of a free culture and the
 17 | further production of creative, cultural and scientific works, or to gain
 18 | reputation or greater distribution for their Work in part through the use and
 19 | efforts of others.
 20 | 
 21 | For these and/or other purposes and motivations, and without any expectation
 22 | of additional consideration or compensation, the person associating CC0 with a
 23 | Work (the "Affirmer"), to the extent that he or she is an owner of Copyright
 24 | and Related Rights in the Work, voluntarily elects to apply CC0 to the Work
 25 | and publicly distribute the Work under its terms, with knowledge of his or her
 26 | Copyright and Related Rights in the Work and the meaning and intended legal
 27 | effect of CC0 on those rights.
 28 | 
 29 | **1. Copyright and Related Rights.** A Work made available under CC0 may be
 30 | protected by copyright and related or neighboring rights ("Copyright and
 31 | Related Rights"). Copyright and Related Rights include, but are not limited
 32 | to, the following:
 33 | 
 34 |   i. the right to reproduce, adapt, distribute, perform, display, communicate,
 35 |   and translate a Work;
 36 | 
 37 |   ii. moral rights retained by the original author(s) and/or performer(s);
 38 | 
 39 |   iii. publicity and privacy rights pertaining to a person's image or likeness
 40 |   depicted in a Work;
 41 | 
 42 |   iv. rights protecting against unfair competition in regards to a Work,
 43 |   subject to the limitations in paragraph 4(a), below;
 44 | 
 45 |   v. rights protecting the extraction, dissemination, use and reuse of data in
 46 |   a Work;
 47 | 
 48 |   vi. database rights (such as those arising under Directive 96/9/EC of the
 49 |   European Parliament and of the Council of 11 March 1996 on the legal
 50 |   protection of databases, and under any national implementation thereof,
 51 |   including any amended or successor version of such directive); and
 52 | 
 53 |   vii. other similar, equivalent or corresponding rights throughout the world
 54 |   based on applicable law or treaty, and any national implementations thereof.
 55 | 
 56 | **2. Waiver.** To the greatest extent permitted by, but not in contravention of,
 57 | applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and
 58 | unconditionally waives, abandons, and surrenders all of Affirmer's Copyright
 59 | and Related Rights and associated claims and causes of action, whether now
 60 | known or unknown (including existing as well as future claims and causes of
 61 | action), in the Work (i) in all territories worldwide, (ii) for the maximum
 62 | duration provided by applicable law or treaty (including future time
 63 | extensions), (iii) in any current or future medium and for any number of
 64 | copies, and (iv) for any purpose whatsoever, including without limitation
 65 | commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes
 66 | the Waiver for the benefit of each member of the public at large and to the
 67 | detriment of Affirmer's heirs and successors, fully intending that such Waiver
 68 | shall not be subject to revocation, rescission, cancellation, termination, or
 69 | any other legal or equitable action to disrupt the quiet enjoyment of the Work
 70 | by the public as contemplated by Affirmer's express Statement of Purpose.
 71 | 
 72 | **3. Public License Fallback.** Should any part of the Waiver for any reason be
 73 | judged legally invalid or ineffective under applicable law, then the Waiver
 74 | shall be preserved to the maximum extent permitted taking into account
 75 | Affirmer's express Statement of Purpose. In addition, to the extent the Waiver
 76 | is so judged Affirmer hereby grants to each affected person a royalty-free,
 77 | non transferable, non sublicensable, non exclusive, irrevocable and
 78 | unconditional license to exercise Affirmer's Copyright and Related Rights in
 79 | the Work (i) in all territories worldwide, (ii) for the maximum duration
 80 | provided by applicable law or treaty (including future time extensions), (iii)
 81 | in any current or future medium and for any number of copies, and (iv) for any
 82 | purpose whatsoever, including without limitation commercial, advertising or
 83 | promotional purposes (the "License"). The License shall be deemed effective as
 84 | of the date CC0 was applied by Affirmer to the Work. Should any part of the
 85 | License for any reason be judged legally invalid or ineffective under
 86 | applicable law, such partial invalidity or ineffectiveness shall not
 87 | invalidate the remainder of the License, and in such case Affirmer hereby
 88 | affirms that he or she will not (i) exercise any of his or her remaining
 89 | Copyright and Related Rights in the Work or (ii) assert any associated claims
 90 | and causes of action with respect to the Work, in either case contrary to
 91 | Affirmer's express Statement of Purpose.
 92 | 
 93 | **4. Limitations and Disclaimers.**
 94 |   a. No trademark or patent rights held by Affirmer are waived, abandoned,
 95 |   surrendered, licensed or otherwise affected by this document.
 96 | 
 97 |   b. Affirmer offers the Work as-is and makes no representations or warranties
 98 |   of any kind concerning the Work, express, implied, statutory or otherwise,
 99 |   including without limitation warranties of title, merchantability, fitness
100 |   for a particular purpose, non infringement, or the absence of latent or
101 |   other defects, accuracy, or the present or absence of errors, whether or not
102 |   discoverable, all to the greatest extent permissible under applicable law.
103 | 
104 |   c. Affirmer disclaims responsibility for clearing rights of other persons
105 |   that may apply to the Work or any use thereof, including without limitation
106 |   any person's Copyright and Related Rights in the Work. Further, Affirmer
107 |   disclaims responsibility for obtaining any necessary consents, permissions
108 |   or other rights required for any use of the Work.
109 | 
110 |   d. Affirmer understands and acknowledges that Creative Commons is not a
111 |   party to this document and has no duty or obligation with respect to this
112 |   CC0 or use of the Work.
113 | 
114 | For more information, please see
115 | <http://creativecommons.org/publicdomain/zero/1.0/>
116 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
  1 | # RiotJS Style Guide
  2 | 
  3 | Opinionated *RiotJS Style Guide* for teams by [De Voorhoede](https://twitter.com/devoorhoede).
  4 | 
  5 | [![RiotJS Style Guide badge](https://cdn.rawgit.com/voorhoede/riotjs-style-guide/master/riotjs-style-guide.svg)](https://github.com/voorhoede/riotjs-style-guide)
  6 | 
  7 | 
  8 | ## Purpose
  9 | 
 10 | This guide provides a uniform way to structure your [RiotJS](http://riotjs.com/) code. Making it
 11 | 
 12 | * easier for developers / team members to understand and find things.
 13 | * easier for IDEs to interpret the code and provide assistance.
 14 | * easier to (re)use build tools you already use.
 15 | * easier to cache and serve bundles of code separately.
 16 | 
 17 | This guide is inspired by the [AngularJS Style Guide](https://github.com/johnpapa/angular-styleguide) by John Papa.
 18 | 
 19 | ## Demos
 20 | 
 21 | Our [RiotJS demos](https://github.com/voorhoede/riotjs-demos#riotjs-demos-) are a companion to this guide, illustrating the guidelines with practical examples.
 22 | 
 23 | ## Table of Contents
 24 | 
 25 | * [Module based development](#module-based-development)
 26 | * [Tag module names](#tag-module-names)
 27 | * [1 module = 1 directory](#1-module--1-directory)
 28 | * [Use `*.tag.html` extension](#use-taghtml-extension)
 29 | * [Use `<script>` inside tag](#use-script-inside-tag)
 30 | * [Keep tag expressions simple](#keep-tag-expressions-simple)
 31 | * [Keep tag options primitive](#keep-tag-options-primitive)
 32 | * [Harness your tag options](#harness-your-tag-options)
 33 | * [Assign `this` to `tag`](#assign-this-to-tag)
 34 | * [Put tag properties and methods on top](#put-tag-properties-and-methods-on-top)
 35 | * [Avoid fake ES6 syntax](#avoid-fake-es6-syntax)
 36 | * [Avoid `tag.parent`](#avoid-tagparent)
 37 | * [Use `each ... in` syntax](#use-each--in-syntax)
 38 | * [Put styles in external files](#put-styles-in-external-files)
 39 | * [Use tag name as style scope](#use-tag-name-as-style-scope)
 40 | * [Document your tag API](#document-your-tag-api)
 41 | * [Add a tag demo](#add-a-tag-demo)
 42 | * [Lint your tag files](#lint-your-tag-files)
 43 | * [Add badge to your project](#add-badge-to-your-project)
 44 | 
 45 | 
 46 | ## Module based development
 47 | 
 48 | Always construct your app out of small modules which do one thing and do it well. 
 49 | 
 50 | A module is a small self-contained part of an application. The RiotJS micro-framework is specifically designed to help you create *view-logic modules*, which Riot calls *tags*.
 51 | 
 52 | ### Why?
 53 | 
 54 | Small modules are easier to learn, understand, maintain, reuse and debug. Both by you and other developers.
 55 | 
 56 | ### How?
 57 | 
 58 | Each riot tag (like any module) must be [FIRST](https://addyosmani.com/first/): *Focused* ([single responsibility](http://en.wikipedia.org/wiki/Single_responsibility_principle)), *Independent*, *Reusable*, *Small* and *Testable*.
 59 | 
 60 | If your module does too much or gets too big, split it up into smaller modules which each do just one thing.
 61 | As a rule of thumb, try to keep each tag file less than 100 lines of code.
 62 | Also ensure your tag module works in isolation. For instance by adding a stand-alone demo.
 63 | 
 64 | **Tip**: If you use an [AMD](https://github.com/amdjs/amdjs-api/blob/master/AMD.md) or CommonJS module loader, you need to [compile your tags using the `--modular` (`-m`) flag](http://riotjs.com/guide/compiler/#amd-and-commonjs):
 65 | ```bash
 66 | # enable AMD and CommonJS
 67 | riot --modular
 68 | ```
 69 | 
 70 | [↑ back to Table of Contents](#table-of-contents)
 71 | 
 72 | 
 73 | ## Tag module names
 74 | 
 75 | A tag module is a specific type of module, containing a Riot tag. 
 76 | 
 77 | Each module name must be:
 78 | 
 79 | * **Meaningful**: not overspecific, not overly abstract.
 80 | * **Short**: 2 or 3 words.
 81 | * **Pronouncable**: we want to be able talk about them.
 82 | 
 83 | Tag module names must also be:
 84 | 
 85 | * **Custom element spec compliant**: [include a hyphen](https://html.spec.whatwg.org/multipage/custom-elements.html#valid-custom-element-name), don't use reserved names.
 86 | * **`app-` namespaced**: if very generic and otherwise 1 word, so that it can easily be reused in other projects.
 87 | 
 88 | ### Why?
 89 | 
 90 | * The name is used to communicate about the module. So it must be short, meaningful and pronouncable.
 91 | * The `tag` element is inserted into the DOM. As such, they need to adhere to the spec.
 92 | 
 93 | ### How?
 94 | 
 95 | ```html
 96 | <!-- recommended -->
 97 | <app-header />
 98 | <user-list />
 99 | <range-slider />
100 | 
101 | <!-- avoid -->
102 | <btn-group /> <!-- short, but unpronouncable. use `button-group` instead -->
103 | <ui-slider /> <!-- all tags are ui elements, so is meaningless -->
104 | <slider /> <!-- not custom element spec compliant -->
105 | ```
106 | 
107 | [↑ back to Table of Contents](#table-of-contents)
108 | 
109 | 
110 | ## 1 module = 1 directory
111 | 
112 | Bundle all files which construct a module into a single place.
113 | 
114 | ### Why?
115 | 
116 | Bundling module files (Riot tags, tests, assets, docs, etc.) makes them easy to find, move and reuse.
117 | 
118 | ### How?
119 | 
120 | Use the module name as directory name and file basename.
121 | The file extension depends on the purpose of the file.
122 | 
123 | ```
124 | modules/
125 | └── my-example/
126 |     ├── my-example.tag.html
127 |     ├── my-example.less
128 |     ├── ...
129 |     └── README.md
130 | ```
131 | 
132 | If your project uses nested structures, you can nest a module within a module.
133 | For example a generic `radio-group` module may be placed directly inside "modules/". While `search-filters` may only make sense inside a `search-form` and may therefore be nested:
134 | 
135 | ```
136 | modules/
137 | ├── radio-group/
138 | |   └── radio-group.tag.html
139 | └── search-form/
140 |     ├── search-form.tag.html
141 |     ├── ...
142 |     └── search-filters/
143 |         └── search-filters.tag.html
144 | ```            
145 | 
146 | [↑ back to Table of Contents](#table-of-contents)
147 | 
148 | 
149 | ## Use `*.tag.html` extension
150 | 
151 | Riot introduces a new concept called *tags*, and suggests to use a `*.tag` extension.
152 | However in essence these tags are simply custom elements containing markup. Therefore you should **use the `*.tag.html` extension**.
153 | 
154 | ### Why?
155 | 
156 | * Tells developers it's not just HTML, but a Riot tag element.
157 | * Improves IDE support (signals how to interpret).
158 | 
159 | ### How?
160 | 
161 | In case of [in-browser compilation](http://riotjs.com/guide/compiler/#in-browser-compilation):
162 | ```html
163 | <script src="path/to/modules/my-example/my-example.tag.html" type="riot/tag"></script>
164 | ```
165 | 
166 | In case of [pre-compilation](http://riotjs.com/guide/compiler/#pre-compilation), set the [custom extension](http://riotjs.com/guide/compiler/#custom-extension):
167 | ```bash
168 | riot --ext tag.html modules/ dist/tags.js
169 | ```
170 | 
171 | In case you're using the [Webpack tag loader](https://github.com/srackham/tag-loader), [configure the loader](http://webpack.github.io/docs/using-loaders.html#configuration) to match the extension:
172 | ```javascript
173 | { test: /\.tag.html$/, loader: 'tag' }
174 | ```
175 | 
176 | [↑ back to Table of Contents](#table-of-contents)
177 | 
178 | 
179 | ## Use `<script>` inside tag
180 | 
181 | While Riot supports writing JavaScript inside a tag element [without a `<script>`](http://riotjs.com/guide/#no-script-tag),
182 | you should **always use `<script>`** around scripting. This is closer to web standards and prevents confusing developers and IDEs. 
183 | 
184 | ### Why?
185 | 
186 | * Prevents markup being interpreted as script.
187 | * Improves IDE support (signals how to interpret).
188 | * Tells developers where markup stops and scripting starts.
189 | 
190 | ### How?
191 | 
192 | ```html
193 | <!-- recommended -->
194 | <my-example>
195 | 	<h1>The year is { this.year }</h1>
196 | 	
197 | 	<script>
198 | 		this.year = (new Date()).getUTCFullYear();
199 | 	</script>
200 | </my-example>
201 | 
202 | <!-- avoid -->
203 | <my-example>
204 | 	<h1>The year is { this.year }</h1>
205 | 	
206 | 	this.year = (new Date()).getUTCFullYear();
207 | </my-example>
208 | ```
209 | 
210 | [↑ back to Table of Contents](#table-of-contents)
211 | 
212 | 
213 | ## Keep tag expressions simple
214 | 
215 | Riot's inline [expressions](http://riotjs.com/guide/#expressions) are 100% Javascript. This makes them extemely powerful, but potentially also very complex. Therefore you should **keep tag expressions simple**.
216 | 
217 | ### Why?
218 | 
219 | * Complex inline expressions are hard to read.
220 | * Inline expressions can't be reused elsewehere. This can lead to code duplication and code rot.
221 | * IDEs typically don't have support for expression syntax, so your IDE can't autocomplete or validate.
222 | 
223 | ### How?
224 | 
225 | Move complex expressions to tag methods or tag properties. 
226 | 
227 | ```html
228 | <!-- recommended -->
229 | <my-example>
230 | 	{ year() + '-' + month() }
231 | 	
232 | 	<script>
233 | 		const twoDigits = (num) => ('0' + num).slice(-2);
234 | 		this.month = () => twoDigits((new Date()).getUTCMonth() +1);
235 | 		this.year  = () => (new Date()).getUTCFullYear();
236 | 	</script>
237 | </my-example>
238 | 
239 | <!-- avoid -->
240 | <my-example>
241 | 	{ (new Date()).getUTCFullYear() + '-' + ('0' + ((new Date()).getUTCMonth()+1)).slice(-2) }
242 | </my-example>
243 | ```
244 | 
245 | [↑ back to Table of Contents](#table-of-contents)
246 | 
247 | 
248 | ## Keep tag options primitive
249 | 
250 | Riot supports passing options to tag instances using attributes on tag elements. Inside the tag instance these options are available through `opts`. For example the value of `my-attr` on `<my-tag my-attr="{ value }" />` will be available inside `my-tag` via `opts.myAttr`. 
251 | 
252 | While Riot supports passing complex JavaScript objects via these attributes, you should try to **keep the tag options as primitive as possible**. Try to only use [JavaScript primitives](https://developer.mozilla.org/en-US/docs/Glossary/Primitive) (strings, numbers, booleans) and functions. Avoid complex objects.
253 | 
254 | Exceptions to this rule are situations which can only be solved using objects (eg. collections or recursive tags) or well-known objects inside your app (eg. a product in a web shop).
255 | 
256 | ### Why?
257 | 
258 | * By using an attribute for each option separately the tag has a clear and expressive API.
259 | * By using only primitives and functions as option values our tag APIs are similar to the APIs of native HTML(5) elements. Which makes our custom elements directly familiar.
260 | * By using an attribute for each option, other developers can easily understand what is passed to the tag instance.
261 | * When passing complex objects it's not apparent which properties and methods of the objects are actually being used by the custom tags. This makes it hard to refactor code and can lead to code rot.
262 | 
263 | ### How?
264 | 
265 | Use a tag attribute per option, with a primitive or function as value:
266 | 
267 | ```html
268 | <!-- recommended -->
269 | <range-slider
270 | 	values="[10, 20]"
271 | 	min="0"
272 | 	max="100"
273 | 	step="5"
274 | 	on-slide="{ updateInputs }"
275 | 	on-end="{ updateResults }"
276 | 	/>
277 | 	
278 | <!-- avoid -->
279 | <range-slider config="{ complexConfigObject }">
280 | ```
281 | ```html
282 | <!-- exception: recursive tag, like menu item -->
283 | <menu-item>
284 | 	<a href="{ opts.url }">{ opts.text }</a>
285 | 	<ul if="{ opts.items }">
286 | 		<li each="{ item in opts.items }">
287 | 			<menu-item 
288 | 				text="{ item.text }" 
289 | 				url="{ item.url }" 
290 | 				items="{ item.items }" />
291 | 		</li>
292 | 	</ul>
293 | </menu-item>
294 | ```
295 | 
296 | [↑ back to Table of Contents](#table-of-contents)
297 | 
298 | 
299 | ## Harness your tag options
300 | 
301 | In Riot your tag options are your API. A robust and predictable API makes your tags easy to use by other developers.
302 | 
303 | Tag options are passed via custom HTML attributes. The values of these attributes can be Riot expressions (`attr="{ var }"`) or plain strings (`attr="value"`) or missing entirely. You should **harness your tag options** to allow for these different cases.
304 | 
305 | ## Why?
306 | 
307 | Harnessing your tag options ensures your tag will always function (defensive programming). Even when other developers later use your tags in ways you haven't thought of yet.
308 | 
309 | ## How?
310 | 
311 | * Use defaults for option values.
312 | * Use type conversion to cast option values to expected type.
313 | * Check if option exists before using it.
314 | 
315 | For instance [Riot's `<todo>` example](http://riotjs.com/guide/#example) could be improved to also work if no `items` are provided, by using a default:
316 | 
317 | ```javascript
318 | this.items = opts.items || []; // default to empty list
319 | ```
320 | Ensuring different use cases all work:
321 | ```html
322 | <todo items="{ [{ title:'Apples' }, { title:'Oranges', done:true }] }"> <!-- uses given list -->
323 | <todo> <!-- uses empty list -->
324 | ```
325 | 
326 | The `<range-slider>` in [keep tag options primitive](https://github.com/voorhoede/riotjs-style-guide#keep-tag-options-primitive) expects numbers for `min`, `max` and `step`. Use type conversion: 
327 | 
328 | ```javascript
329 | // if step option is valid, use as number otherwise default to one. 
330 | this.step = !isNaN(Number(opts.step)) ? Number(opts.step) : 1;
331 | ```
332 | Ensuring different use cases all work:
333 | ```html
334 | <range-slider> <!-- uses default -->
335 | <range-slider step="5"> <!-- converts "5" to number 5 -->
336 | <range-slider step="{ x }"> <!-- tries to use `x` -->
337 | ```
338 | 
339 | The `<range-slider>` also supports *optional* `on-slide` and `on-end` callback. Check option exists and is in expected format before using it:
340 | 
341 | ```javascript
342 | slider.on('slide', (values, handle) => {
343 | 	if (typeof opts.onSlide === 'function') {
344 | 		opts.onSlide(values, handle);
345 | 	}
346 | }
347 | ```
348 | Ensuring different use cases all work:
349 | ```html
350 | <range-slider> <!-- does nothing -->
351 | <range-slider on-slide="{ updateInputs }"> <!-- calls updateInputs on slide -->
352 | <range-slider on-slide="invalid option"> <!-- does nothing -->
353 | ```
354 | 
355 | [↑ back to Table of Contents](#table-of-contents)
356 | 
357 | 
358 | ## Assign `this` to `tag`
359 | 
360 | Within the context of a Riot tag element, `this` is bound to the [tag instance](http://riotjs.com/api/#tag-instance).
361 | Therefore when you need to reference it in a different context, ensure `this` is available as `tag`.
362 | 
363 | ### Why?
364 | 
365 | * By assigning `this` to a variable named `tag` the variable tells developers it's bound to the [tag instance](http://riotjs.com/api/#tag-instance) wherever it's used.
366 | 
367 | ### How?
368 | 
369 | ```javascript
370 | /* recommended */
371 | // ES5: assign `this` to `tag` variable
372 | var tag = this;
373 | window.onresize = function() { 
374 |     tag.adjust();
375 | }
376 | 
377 | // ES6: assign `this` to `tag` constant
378 | const tag = this;
379 | window.onresize = function() { 
380 |     tag.adjust();
381 | }
382 | 
383 | // ES6: you can still use `this` with fat arrows
384 | window.onresize = () => {
385 |     this.adjust();
386 | }
387 | 
388 | /* avoid */
389 | var self = this;
390 | var _this = this;
391 | // etc
392 | ```
393 | 
394 | [↑ back to Table of Contents](#table-of-contents)
395 | 
396 | 
397 | ## Put tag properties and methods on top
398 | 
399 | Inside a Riot tag element you typically put its markup first, followed by its script.
400 | Properties and methods bound to the tag (`this`) in the script are directly available in the markup. You should put those tag properties and methods alphabetized at the top of the script. Tag methods longer than a one-liner should be linked to separate functions later in the script.
401 | 
402 | ### Why?
403 | 
404 | * Placing the tag properties and methods at the top of the script allows you to instantly identify which parts of the tag can be used in the markup.
405 | * Alphabetizing the properties and methods makes them easy to find.
406 | * By keeping each tag method or property declaration a one-liner you can get a full overview of the tag at a glance.
407 | * By moving the full functions behind the tag methods down, you initially hide implementation details.
408 | 
409 | ### How?
410 | 
411 | Put tag properties and methods on top:
412 | 
413 | ```javascript
414 | /* recommended: alphabetized properties then methods */
415 | var tag = this;
416 | tag.text = '';
417 | tag.todos = [];
418 | tag.add = add;
419 | tag.edit = edit;
420 | tag.toggle = toggle;
421 | 
422 | function add(event) {
423 |     /* ... */
424 | }
425 | 
426 | function edit(event) {
427 |     /* ... */
428 | }
429 | 
430 | function toggle(event) {
431 |     /* ... */
432 | }   
433 | 
434 | /* avoid: don't spread out tag properties and methods over script */
435 | var tag = this;
436 | 
437 | tag.todos = [];
438 | tag.add = function(event) {
439 |     /* ... */
440 | }
441 | 
442 | tag.text = '';
443 | tag.edit = function(event) {
444 |     /* ... */
445 | }
446 | 
447 | tag.toggle = function(event) {
448 |     /* ... */
449 | }
450 | ```
451 |     
452 | Also put mixins and observables up top:
453 | 
454 | ```javascript
455 | /* recommended */
456 | var tag = this;
457 | // alphabetized properties
458 | // alphabetized methods
459 | tag.mixin('someBehaviour');
460 | tag.on('mount', onMount);
461 | tag.on('update', onUpdate);
462 | // etc
463 | ```
464 | 
465 | [↑ back to Table of Contents](#table-of-contents)
466 | 
467 | 
468 | ## Avoid fake ES6 syntax
469 | 
470 | Riot supports a [shorthand *ES6 like* method syntax](http://riotjs.com/guide/#tag-syntax). Riot compiles the shorthand syntax `methodName() { }` into `this.methodName = function() {}.bind(this)`. Since this is non-standard you should **avoid fake ES6 method shorthand syntax**.
471 | 
472 | ### Why?
473 | 
474 | * The fake ES6 shorthand syntax is non-standard and can therefore confuse developers.
475 | * The tag scripts are not actual ES6 classes, so IDEs won't be able to interpret the fake ES6 class method syntax.
476 | * It should always be clear which methods are bound to the tag and thus available in the markup. The shorthand syntax obscures the principle of writing code which is transparent and easy to understand.
477 | 
478 | ### How? 
479 | 
480 | Use `tag.methodName =` instead of magic `methodName() { }` syntax:
481 | 
482 | ```javascript
483 | /* recommended */
484 | var tag = this;
485 | tag.todos = [];
486 | tag.add = add;
487 | 
488 | function add() {
489 |     if (tag.text) {
490 |         tag.todos.push({ title: tag.text });
491 |         tag.text = tag.input.value = '';
492 |     }
493 | }
494 | 
495 | /* avoid */
496 | todos = [];
497 | 
498 | add() {
499 |     if (this.text) {
500 |         this.todos.push({ title: this.text });
501 |         this.text = this.input.value = '';
502 |     }
503 | }
504 | ```
505 | 
506 | **Tip**: [Disable transformation of the fake ES6 syntax](http://riotjs.com/guide/compiler/#no-transformation) during pre-compilation by setting `type` to `none`:
507 | 
508 | ```bash
509 | riot --type none
510 | ```
511 | 
512 | [↑ back to Table of Contents](#table-of-contents)
513 | 
514 | 
515 | ## Avoid `tag.parent`
516 | 
517 | Riot supports [nested tags](http://riotjs.com/guide/#nested-tags) which have access to their parent context through `tag.parent`. Accessing context outside your tag module violates the [FIRST](https://addyosmani.com/first/) rule of [module based development](#module-based-development). Therefore you should **avoid using `tag.parent`**.
518 | 
519 | The exception to this rule are anonymous child tags in a [for each loop](http://riotjs.com/guide/#loops) as they are defined directly inside the tag module.
520 | 
521 | ### Why?
522 | 
523 | * A tag module, like any module, must work in isolation. If a tag needs to access its parent, this rule is broken.
524 | * If a tag needs access to its parent, it can no longer be reused in a different context. 
525 | * By accessing its parent a child tag can modify properties on its parent. This can lead to unexpected behaviour.
526 | 
527 | ### How?
528 | 
529 | * Pass values from the parent to the child tag using attribute expressions.
530 | * Pass methods defined on the parent tag to the child tag using callbacks in attribute expressions.
531 | 
532 | ```html
533 | <!-- recommended -->
534 | <parent-tag>
535 | 	<child-tag value="{ value }" /> <!-- pass parent value to child -->
536 | </parent-tag>
537 | 
538 | <child-tag>
539 | 	<span>{ opts.value }</span> <!-- use value passed by parent -->
540 | </child-tag>
541 | 
542 | <!-- avoid -->
543 | <parent-tag>
544 | 	<child-tag />
545 | </parent-tag>
546 | 
547 | <child-tag>
548 | 	<span>value: { parent.value }</span> <!-- don't do this -->
549 | </child-tag>
550 | ```
551 | ```html
552 | <!-- recommended -->
553 | <parent-tag>
554 | 	<child-tag on-event="{ methodToCallOnEvent }" /> <!-- use method as callback -->
555 | 	<script>this.methodToCallOnEvent = () => { /*...*/ };</script>
556 | <parent-tag>
557 | 
558 | <child-tag>
559 | 	<button onclick="{ opts.onEvent }"></button> <!-- call method passed by parent -->
560 | </child-tag>
561 | 
562 | <!-- avoid -->
563 | <parent-tag>
564 | 	<child-tag />
565 | 	<script>this.methodToCallOnEvent = () => { /*...*/ };</script>
566 | <parent-tag>
567 | 
568 | <child-tag>
569 | 	<button onclick="{ parent.methodToCallOnEvent }"></button> <!-- don't do this -->
570 | </child-tag>
571 | ```
572 | ```html
573 | <!-- allowed exception -->
574 | <parent-tag>
575 | 	<button each="{ item in items }"
576 | 		onclick="{ parent.onEvent }"> <!-- okay, because button is not a riot tag -->
577 | 		{ item.text }
578 | 	</button>
579 | 	<script>this.onEvent = (e) => { alert(e.item.text); }</script>
580 | </parent-tag>
581 | ```
582 | 
583 | [↑ back to Table of Contents](#table-of-contents)
584 | 
585 | 
586 | ## Use `each ... in` syntax
587 | 
588 | Riot supports multiple notations for [loops](http://riotjs.com/guide/#loops): item in array (`each="{ item in items }"`); key, value in object (`each="{ key, value in items }"`) and a shorthand (`each="{ items }"`) notation. This shorthand can lead to confusion. Therefore you should **use the `each ... in` syntax**.
589 | 
590 | ### Why?
591 | 
592 | Riot creates a new tag instance for each item the `each` directive loops through. When using the shorthand notation, the methods and properties of the current item are bound to the current tag instance (local `this`). This is not obvious when looking at the markup and may thus confuse other developers. Therefore you should **use the `each ... in` syntax**.
593 | 
594 | ### How?
595 | 
596 | Use `each="{ item in items }"` or `each="{ key, value in items }"` instead of `each="{ items }"` syntax:
597 | 
598 | ```html
599 | <!-- recommended: -->
600 | <ul>
601 |     <li each="{ item in items }">
602 |       	<label class="{ completed: item.done }">
603 | 			<input type="checkbox" checked="{ item.done }"> { item.title }
604 |       	</label>
605 |     </li>
606 | </ul>
607 | 
608 | <!-- recommended: -->
609 | <ul>
610 |     <li each="{ key, item in items }">
611 |       	<label class="{ completed: item.done }">
612 | 			<input type="checkbox" checked="{ item.done }"> { key }. { item.title }
613 |       	</label>
614 |     </li>
615 | </ul>
616 | 
617 | <!-- avoid: -->
618 | <ul>
619 |     <li each="{ items }">
620 |       	<label class="{ completed: done }">
621 | 			<input type="checkbox" checked="{ done }"> { title }
622 |       	</label>
623 |     </li>
624 | </ul>
625 | ```
626 | 
627 | [↑ back to Table of Contents](#table-of-contents)
628 | 
629 | 
630 | ## Put styles in external files
631 | 
632 | For developer convenience, Riot allows you to define a tag element's style in a [nested `<style>` tag](http://riotjs.com/guide/#tag-styling). While you can [scope](http://riotjs.com/guide/#scoped-css) these styles to the tag element, Riot does not provide true encapsulation. Instead Riot extracts these styles from the tags (JavaScript) and injects them into the document on runtime. Since Riot compiles nested styles to JavaScript and doesn't have true encapsulation, you should instead **put styles in external files**.
633 | 
634 | ### Why?
635 | 
636 | * External stylesheets can be handled by the browser independently of Riot and tag files. This means styles can be applied to initial markup even if JavaScript errors occur or isn't loaded (yet).
637 | * External stylesheets can be used in combination with pre-processors (Less, Sass, PostCSS, etc) and your own (existing) build tools.
638 | * External stylesheets can be minified, served and cached separately. This improves performance.
639 | * Riot expressions are not supported in nested `<style>`s so there's no added benefit in using them.
640 | 
641 | ### How?
642 | 
643 | Styles related to the tag and its markup, should be placed in a separate stylesheet file next to the tag file, inside its module directory:
644 | 
645 | ```
646 | my-example/
647 | ├── my-example.tag.html
648 | ├── my-example.(css|less|scss)    <-- external stylesheet next to tag file
649 | └── ...
650 | ```
651 | 
652 | [↑ back to Table of Contents](#table-of-contents)
653 | 
654 | 
655 | ## Use tag name as style scope
656 | 
657 | Riot tag elements are custom elements which can very well be used as style scope root.
658 | Alternatively the module name can be used as CSS class namespace.
659 | 
660 | ### Why?
661 | 
662 | * Scoping styles to a tag element improves predictability as its prevents styles leaking outside the tag element.
663 | * Using the same name for the module directory, the Riot tag and the style root makes it easy for developers to understand they belong together.
664 | 
665 | ### How?
666 | 
667 | Use the tag name as selector, as parent selector or as namespace prefix (depending on your CSS naming strategy).
668 | 
669 | ```css
670 | /* recommended */
671 | my-example { }
672 | my-example li { }
673 | .my-example__item { }
674 | 
675 | /* avoid */
676 | .my-alternative { } /* not scoped to tag or module name */
677 | .my-parent .my-example { } /* .my-parent is outside scope, so should not be used in this file */
678 | ```
679 | 
680 | note: If you're using [`data-is=`](http://riotjs.com/guide/#html-elements-as-tags) (introduced in [v2.3.17](http://riotjs.com/release-notes/#march-9-2016)) to initiate Riot tags, you can use `[data-is="my-example"]` as CSS selector instead of `.my-example`.
681 | 
682 | 
683 | [↑ back to Table of Contents](#table-of-contents)
684 | 
685 | 
686 | ## Document your tag API
687 | 
688 | A Riot tag instance is created by using the tag element inside your application. The instance is configured through its custom attributes. For the tag to be used by other developers, these custom attributes - the tag's API - should be documented in a `README.md` file.
689 | 
690 | ### Why?
691 | 
692 | * Documentation provides developers with a high level overview to a module, without the need to go through all its code. This makes a module more accessible and easier to use.
693 | * A tag's API is the set of custom attributes through which its configured. Therefore these are especially of interest to other developers which only want to consume (and not develop) the tag.
694 | * Documentation formalises the API and tells developers which functionality to keep backwards compatible when modifying the tag's code.
695 | * `README.md` is the de facto standard filename for documentation to be read first. Code repository hosting services (Github, Bitbucket, Gitlab etc) display the contents of the the README's, directly when browsing through source directories. This applies to our module directories as well.
696 |   
697 | ### How?
698 | 
699 | Add a `README.md` file to the tag's module directory:
700 | 
701 | ```
702 | range-slider/
703 | ├── range-slider.tag.html
704 | ├── range-slider.less
705 | └── README.md
706 | ```
707 | 	
708 | Within the README file, describe the functionality and the usage of the module. For a tag module its most useful to describe the custom attributes it supports as those are its API:
709 | 
710 | ```markdown
711 | # Range slider
712 | 
713 | ## Functionality
714 | 
715 | The range slider lets the user to set a numeric range by dragging a handle on a slider rail for both the start and end value.
716 | 
717 | This module uses the [noUiSlider](http://refreshless.com/nouislider/) for cross browser and touch support.
718 | 
719 | ## Usage
720 | 
721 | `<range-slider>` supports the following custom tag attributes:
722 | 
723 | | attribute | type | description
724 | | --- | --- | ---
725 | | `min` | Number | number where range starts (lower limit).
726 | | `max` | Number | Number where range ends (upper limit).
727 | | `values` | Number[] *optional* | Array containing start and end value.  E.g. `values="[10, 20]"`. Defaults to `[opts.min, opts.max]`.
728 | | `step` | Number *optional* | Number to increment / decrement values by. Defaults to 1.
729 | | `on-slide` | Function *optional* | Function called with `(values, HANDLE)` while a user drags the start (`HANDLE == 0`) or end (`HANDLE == 1`) handle. E.g. `on-slide={ updateInputs }`, with `tag.updateInputs = (values, HANDLE) => { const value = values[HANDLE]; }`.
730 | | `on-end` | Function *optional* | Function called with `(values, HANDLE)` when user stops dragging a handle.
731 | 
732 | For customising the slider appearance see the [Styling section in the noUiSlider docs](http://refreshless.com/nouislider/more/#section-styling).
733 | ```
734 | 
735 | [↑ back to Table of Contents](#table-of-contents)
736 | 
737 | 
738 | ## Add a tag demo
739 | 
740 | Add a `*.demo.html` file with demos of the tag with different configurations, showing how the tag can be used.
741 | 
742 | ### Why?
743 | 
744 | * A tag demo proves the module works in isolation.
745 | * A tag demo gives developers a preview before having to dig into the documentation or code.
746 | * Demos can illustrate all the possible configurations and variations a tag can be used in. 
747 | 
748 | ### How?
749 | 
750 | Add a `*.demo.html` file to your module directory:
751 | 
752 | ```
753 | city-map/
754 | ├── city-map.tag.html
755 | ├── city-map.demo.html
756 | ├── city-map.css
757 | └── ...
758 | ```
759 | 
760 | Inside the demo file:
761 | 
762 | * Include `riot+compiler.min.js` to also compile during runtime.
763 | * Include the tag file (e.g. `./city-map.tag.html`).
764 | * Create a `demo` tag (`<yield/>`) to embed your demos in (otherwise option attributes are not supported).
765 | * Write demos inside the `<demo>` tags.
766 | * As a bonus add `aria-label`s to the `<demo>` tags and style those as title bars.
767 | * Initialise using `riot.mount('demo', {})`.
768 | 
769 | Example demo file in `city-tag` module:
770 | 
771 | ```html
772 | <!-- modules/city-map/city-map.demo.html: -->
773 | <body>
774 |     <h1>city-map demos</h1>
775 |     
776 |     <demo aria-label="City map of London">
777 |         <city-map location="London" />    
778 |     </demo>
779 |     
780 |     <demo aria-label="City map of Paris">
781 |         <city-map location="Paris" />    
782 |     </demo>
783 |     
784 |     <link rel="stylesheet" href="./city-map.css">
785 |     
786 |     <script src="path/to/riot+compiler.min.js"></script>
787 |     <script type="riot/tag" src="./city-map.tag.html"></script> 
788 |     <script>
789 |         riot.tag('demo','<yield/>');
790 |         riot.mount('demo', {});
791 |     </script>
792 |     
793 |     <style>
794 |     	/* add a grey bar with the `aria-label` as demo title */
795 |     	demo:before {
796 |         	content: "Demo: " attr(aria-label);
797 | 	        display: block;
798 |         	background: #F3F5F5;
799 |         	padding: .5em;
800 |         	clear: both;
801 |         }
802 |     </style>
803 | </body>
804 | ```
805 | Note: this is a working concept, but could be much cleaner using build scripts.
806 | 
807 | [↑ back to Table of Contents](#table-of-contents)
808 | 
809 | 
810 | ## Lint your tag files
811 | 
812 | Linters improve code consistency and help trace syntax errors. With some extra configuration Riot tag files can also be linted.
813 | 
814 | ### Why?
815 | 
816 | * Linting tag files ensures all developers use the same code style.
817 | * Linting tag files helps you trace syntax errors before it's too late.
818 | 
819 | ### How?
820 | 
821 | To allow linters to extract the scripts from your `*.tag.html` files, [put script inside a `<script>` tag](#use-script-inside-tag) and [keep tag expressions simple](#keep-tag-expressions-simple) (as linters don't understand those). Configure your linter to allow global variables `riot` and tag `opts`.
822 | 
823 | #### ESLint
824 | 
825 | [ESLint](http://eslint.org/) requires an extra [ESLint HTML plugin](https://github.com/BenoitZugmeyer/eslint-plugin-html#eslint-plugin-html) to extract the script from the tag files.
826 | 
827 | Configure ESLint in `modules/.eslintrc` (so IDEs can interpret it as well):
828 | ```json
829 | {
830 | 	"extends": "eslint:recommended",
831 | 	"plugins": ["html"],
832 | 	"env": {
833 | 		"browser": true
834 | 	},
835 | 	"globals": {
836 | 		"opts": true,
837 | 		"riot": true
838 | 	}
839 | }
840 | ```
841 | 
842 | Run ESLint
843 | ```bash
844 | eslint modules/**/*.tag.html
845 | ```
846 | 
847 | #### JSHint
848 | 
849 | [JSHint](http://jshint.com/) can parse HTML (using `--extra-ext`) and extract script (using `--extract=auto`). 
850 | 
851 | Configure JSHint in `modules/.jshintrc` (so IDEs can interpret it as well):
852 | ```json
853 | {
854 | 	"browser": true,
855 | 	"predef": ["opts", "riot"]
856 | }
857 | ```
858 | 
859 | Run JSHint
860 | ```bash
861 | jshint --config modules/.jshintrc --extra-ext=html --extract=auto modules/
862 | ```
863 | Note: JSHint does not accept `tag.html` as extension, but only `html`.
864 | 
865 | [↑ back to Table of Contents](#table-of-contents)
866 | 
867 | 
868 | ## Add badge to your project
869 | 
870 | You can use the *RiotJS Style Guide badge* to link to this guide:
871 | 
872 | [![RiotJS Style Guide badge](https://cdn.rawgit.com/voorhoede/riotjs-style-guide/master/riotjs-style-guide.svg)](https://github.com/voorhoede/riotjs-style-guide)
873 | 
874 | ### Why?
875 | 
876 | Inform other developers your project is following the RiotJS Style Guide. And let them know where they can find this guide.
877 | 
878 | ### How?
879 | 
880 | Include the badge in your project. In markdown:
881 | 
882 | ```markdown
883 | [![RiotJS Style Guide badge](https://cdn.rawgit.com/voorhoede/riotjs-style-guide/master/riotjs-style-guide.svg)](https://github.com/voorhoede/riotjs-style-guide)
884 | ```
885 | 
886 | Or html:
887 | 
888 | ```html
889 | <a href="https://github.com/voorhoede/riotjs-style-guide">
890 |     <img alt="RiotJS Style Guide badge"
891 |     	 src="https://cdn.rawgit.com/voorhoede/riotjs-style-guide/master/riotjs-style-guide.svg">
892 | </a>
893 | ```
894 | 
895 | [↑ back to Table of Contents](#table-of-contents)
896 | 
897 | ---
898 | 
899 | ## License
900 | 
901 | [![CC0](http://mirrors.creativecommons.org/presskit/buttons/88x31/svg/cc-zero.svg)](https://creativecommons.org/publicdomain/zero/1.0/)
902 | 
903 | [De Voorhoede](https://twitter.com/devoorhoede) waives all rights to this work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
904 | 
905 | You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.
906 | 


--------------------------------------------------------------------------------
/riotjs-style-guide.svg:
--------------------------------------------------------------------------------
1 | <svg xmlns="http://www.w3.org/2000/svg" width="128" height="20" viewBox="0 0 128 20">
2 |   <title>RiotJS Style Guide</title>
3 |   <path fill="#F04" d="M0 5c0-2.76 2.24-5 5-5h40v20H5c-2.76 0-5-2.23-5-5V5z"/><path fill="#E0E0E0" d="M128 15c0 2.77-2.24 5-5 5H45V0h78c2.76 0 5 2.24 5 5v10z"/><path fill="#FFF" d="M11.7 5.42H7.6v9.43h2.42v-3.3h1.12l1.57 3.3h2.8l-1.8-3.63c.6-.26 1.68-1.1 1.68-2.66 0-1.83-1.2-3.14-3.55-3.14zm-1.67 4.42v-2.6h1.3c.75 0 1.37.45 1.37 1.32 0 .86-.58 1.28-1.4 1.28h-1.28zm9.4 5v-9.4h-2.48v9.4h2.48zm4.25-5.23c0-1.5.7-2.3 1.75-2.3s1.75.8 1.75 2.4v1.1c0 1.58-.7 2.3-1.75 2.3-1.06 0-1.75-.8-1.75-2.3V9.6zm-2.53 1.1c0 2.7 1.55 4.4 4.28 4.4 2.73 0 4.28-1.63 4.28-4.3V9.7c0-2.66-1.5-4.38-4.2-4.38S21.2 7 21.2 9.67v1.04zm14.45 4.2V7.5h2.55v-2h-7.5v2h2.52v7.4h2.47z"/><path d="M51.4 9.16c0 1.45 1.1 1.82 2.46 2.1 1 .18 1.84.3 1.84 1.08 0 .6-.45 1.06-1.55 1.06-.98 0-1.42-.4-1.5-.98h-1.38c0 1.3 1.12 2.1 2.8 2.1 1.83 0 3-.86 3-2.35 0-1.4-1.1-1.82-2.46-2.06-.8-.1-1.8-.2-1.8-1 0-.6.6-1 1.4-1 1 0 1.4.56 1.5 1H57C57 7.8 55.9 7 54.3 7c-1.46 0-2.8.67-2.8 2.26zm8.12-2.1h-1.14v1.2h1.12v4.06c0 1.47.43 2.12 2.2 2.12.32 0 .83-.04.94-.07V13.2c-.1.02-.4.03-.6.03-.84 0-1.14-.22-1.14-1.03V8.27h1.66v-1.2H60.9V5.23h-1.38v1.83zm11.04-.04h-1.5L67.22 13h-.05L65.3 7.02h-1.56l2.66 7.43-.1.33c-.18.7-.52 1.1-1.4 1.1-.2 0-.45-.03-.57-.06v1.15c.2.03.52.07.84.07 1.64 0 2.2-1.02 2.64-2.23l.2-.5 2.6-7.2zm1.74 7.37h1.4V4.3h-1.4v10.1zm6.7.1c1.92 0 2.8-1.2 2.9-2.1h-1.4c-.1.4-.68.8-1.52.8-1.14 0-1.8-.8-1.8-1.9V11H82v-.86c0-2.02-1.3-3.3-3.1-3.3-1.78 0-3.1 1.22-3.1 3.3v1c0 2.08 1.2 3.3 3.2 3.3zM77.2 10v-.1c0-1.13.68-1.88 1.7-1.88 1.04 0 1.72.74 1.72 1.87v.1H77.2zm12.77 5.87c-.92 0-1.5-.38-1.6-.88h-1.4c.1 1.1.98 2 2.95 2 1.9 0 3.3-.8 3.3-2.9V7h-1.35v1.1h-.07c-.24-.6-1.03-1.2-2.13-1.2-1.62 0-2.86 1.17-2.86 3.17v1c0 2 1.3 3.15 2.9 3.15 1.1 0 1.8-.5 2.1-1.15h.1v1.1c0 1.1-.6 1.74-1.8 1.74zm.1-7.78c1.1 0 1.75.9 1.75 1.9v1c0 1.02-.62 1.92-1.73 1.92-1.1 0-1.9-.85-1.9-2.13v-.64c0-1.3.7-2.14 1.8-2.14zM101.6 7h-1.4v4.58c0 .9-.8 1.63-1.8 1.63-.83 0-1.53-.3-1.53-1.5V7.1h-1.4v5.05c0 1.7 1.02 2.43 2.5 2.43 1.28 0 1.95-.72 2.16-1.3h.08v1.22h1.4V7zm2.57 7.38h1.4V7h-1.4v7.37zm-.25-9.6c0 .54.4.93.95.93.57 0 .98-.4.98-.9s-.4-.9-.98-.9c-.56 0-.95.4-.95 1zm6.72 2.1c-1.73 0-2.83 1.24-2.83 3.16v1.3c0 1.94 1.2 3.13 2.8 3.13 1.3-.02 2-.65 2.2-1.3h.1v1.2h1.4v-10h-1.4V8.1h-.1c-.2-.63-.9-1.2-2.1-1.2zm.33 1.27c1.1 0 1.86.77 1.86 1.9v1.15c0 1.26-.72 2.02-1.82 2.02-1 0-1.7-.75-1.7-2.12v-.83c0-1.36.7-2.13 1.8-2.13zm8.54 6.34c2 0 2.9-1.2 3-2.1h-1.4c-.1.4-.7.8-1.5.8-1.13 0-1.8-.8-1.8-1.9V11h4.85v-.86c0-2.02-1.3-3.3-3.1-3.3s-3.1 1.22-3.1 3.3v1c0 2.08 1.2 3.3 3.2 3.3zm-1.8-4.5v-.1c0-1.2.7-1.9 1.8-1.9s1.7.7 1.7 1.82v.1h-3.4z"/>
4 | </svg>
5 | 


--------------------------------------------------------------------------------