';
47 | }
48 | if (tag === 'h2' && firstBlock === true) {
49 | inner += 'Back to Top';
50 | }
51 | if (inner !== '') {
52 | hx[i].id = anchor;
53 | hx[i].innerHTML += inner;
54 | };
55 | if (tag === 'h2') {
56 | firstBlock = true;
57 | }
58 | }
59 | toc.innerHTML = toc_contents;
60 | toc.style.display = 'block';
61 | },
62 | // just hooking up back to top
63 | anchors: function() {
64 | var iso = ISOBAR.util;
65 |
66 | this.$body.on('click', '.back-anchor', function() {
67 | window.scrollTo(0, 0);
68 | window.location.hash = '';
69 | return false;
70 | });
71 | this.$body.on('click', '.js-here', function(e){
72 | if (iso.$body.hasClass('mob')) {
73 | ISOBAR.common.scrollNow(e);
74 | }
75 | });
76 | },
77 | toggleMenu: function(e){
78 | var iso = ISOBAR.util;
79 | iso.$body.toggleClass('menu-open');
80 |
81 | if (iso.$body.hasClass('mob')) {
82 | iso.$body.on('click', '#toc a', ISOBAR.common.scrollNow);
83 | };
84 | },
85 | scrollNow: function(e){
86 | e.preventDefault;
87 | var target = e.target.getAttribute('href');
88 | if (target[0] === '#') {
89 | $.scrollTo(target, { offset: -95, duration: 250 });
90 | };
91 | }
92 | },
93 | util: {
94 | $body : $('body'), // cache the body
95 | settings: {},
96 |
97 | fire: function(func, funcname, args) {
98 | var namespace = ISOBAR; // indicate your obj literal namespace here
99 | funcname = (typeof funcname === 'undefined') ? 'init' : funcname;
100 | if (func !== '' && namespace[func] && typeof namespace[func][funcname] == 'function') {
101 | namespace[func][funcname](args);
102 | }
103 | },
104 | loadEvents: function() {
105 | var iso = ISOBAR.util;
106 | iso.settings = ISOBAR.settings; // convenience
107 |
108 | $('html').removeClass('no-js');
109 |
110 | //Fire resize event and call setLayout(). Put onresize events in there.
111 | window.addEventListener('resize', iso.debounce(iso.setLayout, 50));
112 |
113 | // may want this to track the menu at some point (future)
114 | // window.addEventListener('scroll', iso.debounce(function(){
115 | // console.log('scroll');
116 | // }, 100))
117 |
118 | // enable pointer events for touch devices
119 | FastClick.attach(document.body);
120 |
121 | // hit up common first.
122 | iso.fire('common');
123 |
124 | iso.$body.on('click', '.menu-button', ISOBAR.common.toggleMenu);
125 | iso.setLayout();
126 | },
127 | debounce: function(func, wait, immediate) {
128 |
129 | var timeout;
130 |
131 | return function() {
132 | var context = this,
133 | args = arguments;
134 | var later = function() {
135 | timeout = null;
136 | if (!immediate) func.apply(context, args);
137 | };
138 | var callNow = immediate && !timeout;
139 | clearTimeout(timeout);
140 | timeout = setTimeout(later, wait);
141 | if (callNow) func.apply(context, args);
142 | };
143 | },
144 | setLayout: function() {
145 | var iso = ISOBAR.util;
146 |
147 | //Set classes on the body based on screen width.
148 | //Display the, 'hamburger' button & menu through css based on these classes added.
149 | var screenWidth = window.innerWidth;
150 | if (screenWidth > iso.settings.mobMenu) {
151 | iso.$body.removeClass('menu-open');
152 |
153 | if (iso.$body.hasClass('mob')) {
154 | iso.$body.removeClass('mob');
155 | iso.$body.off('click', ISOBAR.common.scrollNow);
156 | };
157 | } else {
158 | iso.$body.addClass('mob');
159 | iso.overlay();
160 | };
161 |
162 | },
163 | overlay: function() {
164 | if ($('.overlay').length == 0) {
165 | $('body').append('');
166 | $('.overlay').on('click', function(e) {
167 | $('body').toggleClass('menu-open');
168 | });
169 | }
170 | }
171 | }
172 | };
173 |
174 | // kick it all off here
175 | $(document).ready(ISOBAR.util.loadEvents);
176 |
177 |
--------------------------------------------------------------------------------
/src/content/en/general.md:
--------------------------------------------------------------------------------
1 | # Isobar Front-end Code Standards
2 |
3 | ## Introduction
4 |
5 | This document contains the guidelines and best practices for the front-end web development team at Isobar.
6 |
7 | Each item here represents either:
8 |
9 | 1. A reminder to follow existing standards or industry conventions,
10 | 1. guidance on what constitutes professional patterns and organization, or
11 | 1. a decision we've made favoring one method over its alternatives.
12 |
13 | What this document is _not_ is a series of explanations as to how front-end technologies work; a basic familiarity is assumed. It also does _not_ provide evaluations of the pros and cons of various alternatives unless there is common confusion about which option is best; when appropriate we pick what we consider to be the best solutions and present them. Issues that don't yet have a clear solution are considered flexible and may or may not be listed.
14 |
15 |
20 |
21 | ### Goals
22 |
23 | Our motivations in creating this document are to:
24 |
25 | 1. Foster code consistency across our projects.
26 | 1. Facilitate ease of maintenance.
27 | 1. Ensure we create professional quality Web sites.
28 | 1. Guide staff on-boarding or educate new developers.
29 |
30 | This document is not intended to replace common sense, conventions requested by particular clients, teams, or prevent expressive or creative solutions to problems. Team or project-specific agreements or client requests will always supersede this document's content.
31 |
32 | #### Professional Responsibility
33 |
34 | We are experts in our field creating solutions for our clients and their audiences, not for ourselves. Every technology and code choice needs to be measured against the benefits to the project versus the _cool factor_ or how _trendy_ a particular solution may be.
35 |
36 | Our industry is wrought with the flavor of the month, so please be deliberate.
37 |
38 | Always remember that **just because you can does not mean you should**. Some solutions are not reliable, may not perform well, or may be difficult to maintain over time or add more code to. Always remember your code may not be the last added to a project in that particular feature area.
39 |
40 | ### Getting Started
41 |
42 | At the outset of the project it is essential to **properly understand the goals of the project** and **identify the specific deliverables** expected of the front-end team. Where your responsibilities begin and end should not be taken for granted or assumed.
43 |
44 | It's important to understand how the development environment will work, what tools will be available, and what the differences between development, test, and production environments may ultimately be.
45 |
46 | Finally, all project teams should get a reasonable understanding of the what client's **browser and device requirements** are. Make no assumptions as to the technology available either from the client or their audience.
47 |
48 | #### Pillars of Front-end Development
49 |
50 | Whenever possible, the front-end technology solutions produced shall adhere to industry best practices honoring as strict a separation of concerns as possible between:
51 |
52 | - [Semantic][link-semantic] HyperText Markup Language (HTML) for structure
53 | - Cascading Style Sheets (CSS) for presentation
54 | - JavaScript (JS) for behavior and interaction
55 |
56 | When at all possible, we strive for a [progressive enhancement][link-progressive] strategy.
57 |
58 | ### General Standards
59 |
60 | For any project:
61 |
62 | - Consistency and conventions between team members is paramount.
63 | - Solutions should be as simple and clear as possible.
64 | - Solutions should serve a specific purpose.
65 | - Clever code does not mean good code; readability is **critical**
66 |
67 | A key hallmark of professional code includes a notion that while we are writing code that must reach a desired goal, we are also creating code that must be read and understood by others.
68 |
69 | #### Code Consistency
70 |
71 | Usage of the same patterns is critical between team members so as to never cause confusion.
72 |
73 | It's worth establishing conventions at the project start or enabling automatic settings in the build or editor environments that might enforce particular rules.
74 |
75 | #### Indentation
76 |
77 | Please consistently indent, nest, include braces, quotes, and new lines so that code is clear and can be read easily. New code that is added should never deviate from existing formatting conventions or change the indent levels.
78 |
79 | For all code languages, we recommend the **use soft tabs** comprised of four spaces per tab. Hitting the Tab key in your text editor should generate four space characters rather than one tab character. This results in our code appearing identical across platforms.
80 |
81 | If **tab stops** are favored by a team, simply **maintain consistency** for a project and it's deliverables so developers can make adjustments to their editing environments a **single** time.
82 |
83 | #### Readability
84 |
85 | We encourage liberal use of whitespace, comments, and descriptive variable names as appropriate for writing easy-to-read code.
86 |
87 | - There is no need to write code in an obfuscated or compressed way for the purpose of file-size savings.
88 | - We will use automated server-side or other build processes to optimize files.
89 | - This includes concatenating files, code minification, gzipping, and setting "Far Future Expires".
90 |
91 | The ability for another developer to read the code is paramount above other concerns, especially if optimization can be handled another way.
92 |
93 | #### Third-Party Libraries
94 |
95 | Un-minified libraries and third-party scripts should be leveraged in local development environments for easier debugging if available. The code should be committed to source control in an unmodified state, or simply referenced in dependency management components that resolve the files in a build. The final products will be compressed with the rest of the source for delivery.
96 |
97 | Likewise, third-party code and libraries should never be modified and their original source and the license must be documented and be appropriate for a project. Any changes to third party code must be agreed upon and must be for specific reasons. If changes are mandated by bug fixes then the appropriate upstream project should have the changes submitted (assuming the code is part of an open source repository).
98 |
99 | Library code should be treated as an external dependency and should be considered something that may need to be wholesale updated or replaced at a later time.
100 |
101 | Inclusion of any third-party code should be carefully considered and verified with the project team as the appropriate solution to a given problem. "Adding another plug-in" is not always the best solution. Finally, selection of third party libraries should be done carefully and not be out of alignment with the nature of the problem being addressed.
102 |
103 |
107 |
108 | To be blunt, **use the right tool for the right job**.
109 |
110 | ### Deliverables
111 |
112 | Quality deliverables are essential for professionals. Sloppy or messy deliverables are unprofessional and reflect poorly on the final product and the delivery team. Please remove legacy files, be certain the work is delivered in a clean file system, and in an orderly, logical structure that serves a clear purpose.
113 |
114 |
115 | [link-semantic]: http://www.bbc.co.uk/guidelines/futuremedia/technical/semantic_markup.shtml
116 | [link-progressive]: https://en.wikipedia.org/wiki/Progressive_enhancement
117 |
118 |
119 |
--------------------------------------------------------------------------------
/src/js/vendor/prism.js:
--------------------------------------------------------------------------------
1 | /* http://prismjs.com/download.html?themes=prism-twilight&languages=markup+css+clike+javascript&plugins=line-numbers */
2 | self="undefined"!=typeof window?window:"undefined"!=typeof WorkerGlobalScope&&self instanceof WorkerGlobalScope?self:{};var Prism=function(){var e=/\blang(?:uage)?-(?!\*)(\w+)\b/i,t=self.Prism={util:{encode:function(e){return e instanceof n?new n(e.type,t.util.encode(e.content),e.alias):"Array"===t.util.type(e)?e.map(t.util.encode):e.replace(/&/g,"&").replace(/e.length)break e;if(!(d instanceof a)){u.lastIndex=0;var m=u.exec(d);if(m){c&&(f=m[1].length);var y=m.index-1+f,m=m[0].slice(f),v=m.length,k=y+v,b=d.slice(0,y+1),w=d.slice(k+1),N=[p,1];b&&N.push(b);var O=new a(l,g?t.tokenize(m,g):m,h);N.push(O),w&&N.push(w),Array.prototype.splice.apply(r,N)}}}}}return r},hooks:{all:{},add:function(e,n){var a=t.hooks.all;a[e]=a[e]||[],a[e].push(n)},run:function(e,n){var a=t.hooks.all[e];if(a&&a.length)for(var r,i=0;r=a[i++];)r(n)}}},n=t.Token=function(e,t,n){this.type=e,this.content=t,this.alias=n};if(n.stringify=function(e,a,r){if("string"==typeof e)return e;if("Array"===t.util.type(e))return e.map(function(t){return n.stringify(t,a,e)}).join("");var i={type:e.type,content:n.stringify(e.content,a,r),tag:"span",classes:["token",e.type],attributes:{},language:a,parent:r};if("comment"==i.type&&(i.attributes.spellcheck="true"),e.alias){var l="Array"===t.util.type(e.alias)?e.alias:[e.alias];Array.prototype.push.apply(i.classes,l)}t.hooks.run("wrap",i);var s="";for(var o in i.attributes)s+=o+'="'+(i.attributes[o]||"")+'"';return"<"+i.tag+' class="'+i.classes.join(" ")+'" '+s+">"+i.content+""},!self.document)return self.addEventListener?(self.addEventListener("message",function(e){var n=JSON.parse(e.data),a=n.language,r=n.code;self.postMessage(JSON.stringify(t.util.encode(t.tokenize(r,t.languages[a])))),self.close()},!1),self.Prism):self.Prism;var a=document.getElementsByTagName("script");return a=a[a.length-1],a&&(t.filename=a.src,document.addEventListener&&!a.hasAttribute("data-manual")&&document.addEventListener("DOMContentLoaded",t.highlightAll)),self.Prism}();"undefined"!=typeof module&&module.exports&&(module.exports=Prism);;
3 | Prism.languages.markup={comment://,prolog:/<\?.+?\?>/,doctype://,cdata://i,tag:{pattern:/<\/?[\w:-]+\s*(?:\s+[\w:-]+(?:=(?:("|')(\\?[\w\W])*?\1|[^\s'">=]+))?\s*)*\/?>/i,inside:{tag:{pattern:/^<\/?[\w:-]+/i,inside:{punctuation:/^<\/?/,namespace:/^[\w-]+?:/}},"attr-value":{pattern:/=(?:('|")[\w\W]*?(\1)|[^\s>]+)/i,inside:{punctuation:/=|>|"/}},punctuation:/\/?>/,"attr-name":{pattern:/[\w:-]+/,inside:{namespace:/^[\w-]+?:/}}}},entity:/&#?[\da-z]{1,8};/i},Prism.hooks.add("wrap",function(t){"entity"===t.type&&(t.attributes.title=t.content.replace(/&/,"&"))});;
4 | Prism.languages.css={comment:/\/\*[\w\W]*?\*\//,atrule:{pattern:/@[\w-]+?.*?(;|(?=\s*\{))/i,inside:{punctuation:/[;:]/}},url:/url\((?:(["'])(\\\n|\\?.)*?\1|.*?)\)/i,selector:/[^\{\}\s][^\{\};]*(?=\s*\{)/,string:/("|')(\\\n|\\?.)*?\1/,property:/(\b|\B)[\w-]+(?=\s*:)/i,important:/\B!important\b/i,punctuation:/[\{\};:]/,"function":/[-a-z0-9]+(?=\()/i},Prism.languages.markup&&(Prism.languages.insertBefore("markup","tag",{style:{pattern:/[\w\W]*?<\/style>/i,inside:{tag:{pattern:/|<\/style>/i,inside:Prism.languages.markup.tag.inside},rest:Prism.languages.css},alias:"language-css"}}),Prism.languages.insertBefore("inside","attr-value",{"style-attr":{pattern:/\s*style=("|').*?\1/i,inside:{"attr-name":{pattern:/^\s*style/i,inside:Prism.languages.markup.tag.inside},punctuation:/^\s*=\s*['"]|['"]\s*$/,"attr-value":{pattern:/.+/i,inside:Prism.languages.css}},alias:"language-css"}},Prism.languages.markup.tag));;
5 | Prism.languages.clike={comment:[{pattern:/(^|[^\\])\/\*[\w\W]*?\*\//,lookbehind:!0},{pattern:/(^|[^\\:])\/\/.*/,lookbehind:!0}],string:/("|')(\\\n|\\?.)*?\1/,"class-name":{pattern:/((?:(?:class|interface|extends|implements|trait|instanceof|new)\s+)|(?:catch\s+\())[a-z0-9_\.\\]+/i,lookbehind:!0,inside:{punctuation:/(\.|\\)/}},keyword:/\b(if|else|while|do|for|return|in|instanceof|function|new|try|throw|catch|finally|null|break|continue)\b/,"boolean":/\b(true|false)\b/,"function":{pattern:/[a-z0-9_]+\(/i,inside:{punctuation:/\(/}},number:/\b-?(0x[\dA-Fa-f]+|\d*\.?\d+([Ee]-?\d+)?)\b/,operator:/[-+]{1,2}|!|<=?|>=?|={1,3}|&{1,2}|\|?\||\?|\*|\/|~|\^|%/,ignore:/&(lt|gt|amp);/i,punctuation:/[{}[\];(),.:]/};;
6 | Prism.languages.javascript=Prism.languages.extend("clike",{keyword:/\b(break|case|catch|class|const|continue|debugger|default|delete|do|else|enum|export|extends|false|finally|for|function|get|if|implements|import|in|instanceof|interface|let|new|null|package|private|protected|public|return|set|static|super|switch|this|throw|true|try|typeof|var|void|while|with|yield)\b/,number:/\b-?(0x[\dA-Fa-f]+|\d*\.?\d+([Ee][+-]?\d+)?|NaN|-?Infinity)\b/,"function":/(?!\d)[a-z0-9_$]+(?=\()/i}),Prism.languages.insertBefore("javascript","keyword",{regex:{pattern:/(^|[^/])\/(?!\/)(\[.+?]|\\.|[^/\r\n])+\/[gim]{0,3}(?=\s*($|[\r\n,.;})]))/,lookbehind:!0}}),Prism.languages.markup&&Prism.languages.insertBefore("markup","tag",{script:{pattern:/[\w\W]*?<\/script>/i,inside:{tag:{pattern:/|<\/script>/i,inside:Prism.languages.markup.tag.inside},rest:Prism.languages.javascript},alias:"language-javascript"}});;
7 | Prism.hooks.add("after-highlight",function(e){var t=e.element.parentNode,s=/\s*\bline-numbers\b\s*/;if(t&&/pre/i.test(t.nodeName)&&(s.test(t.className)||s.test(e.element.className))){s.test(e.element.className)&&(e.element.className=e.element.className.replace(s,"")),s.test(t.className)||(t.className+=" line-numbers");var a,n=1+e.code.split("\n").length,l=new Array(n);l=l.join(""),a=document.createElement("span"),a.className="line-numbers-rows",a.innerHTML=l,t.hasAttribute("data-start")&&(t.style.counterReset="linenumber "+(parseInt(t.getAttribute("data-start"),10)-1)),e.element.appendChild(a)}});;
8 |
--------------------------------------------------------------------------------
/src/content/en/html.md:
--------------------------------------------------------------------------------
1 | ## HTML
2 |
3 | HTML markup defines the content of a document and gives it a rudimentary structure such as section dividers, headers, paragraphs, lists, menus, and forms.
4 |
5 | ### Goals for Markup
6 |
7 | Please follow conventions established for a given project so all team members can have the same expectations around document structure and markup.
8 |
9 | Structural consistency is critical when talking about the types of pages being used on a site or in a Web app. The markup structure provides all the necessary hooks for scripting and behavior, so it's important that the appropriate hooks are in place.
10 |
11 | A clear, clean, and concise HTML structure is also necessary for semantics, flexibility, and a **reliable deployment environment**. Do **not** deviate from established templates or patterns without architect approval.
12 |
13 | Which markup is used does matter:
14 |
15 | - Use the most *meaningful* yet *minimal* markup required to present the styles and interaction required
16 | - Application-centric deliverables often have different types of requirements; please code accordingly
17 | - **Maintain a clear separation of concerns, avoid in-line styles and in-line JavaScript whenever possible**
18 | - Have reference implementations so that each team member knows what sorts of structures are appropriate, as well as where to add new code.
19 | - Build pages as a **library of components**, in such a way that blocks of code can be broken up and reused when implemented.
20 | - Be sure front-end code is compatible with destination environments and delivery platforms.
21 |
22 | The flexible nature of HTML markup and how loosely browsers interpret markup sometimes lends itself to inconsistencies not always being discovered immediately. This belies the care necessary in crafting a document's structure and in following established patterns.
23 |
24 | ### Getting Started on Markup
25 |
26 | When crafting the HTML for a website, environment or technical constraints may impact the type of markup that can be used. Please discuss the final delivery environment in depth with technical leads and clients so that pages are not structured or styled in some way that is not effective for the project solution.
27 |
28 | Discuss types of:
29 |
30 | - Templates and types of pages.
31 | - Which sections of pages (i.e. components) are reused or managed by software vs. by hand.
32 | - Frameworks, CSS grid systems (custom or otherwise).
33 | - Server-Side delivery platforms.
34 |
35 | *Note that it is vital to take into account how the site will ultimately be maintained and who will be doing that work.*
36 |
37 | ### HTML Markup Best Practices
38 |
39 | As noted these guidelines are flexible for projects as long as consensus or need determines a particular path, consistency is what matters most.
40 |
41 | #### Semantic Markup
42 |
43 | HTML provides a number of [semantic constructs][link-semantic] that allow automated tools like search engines and screen readers to make sense of the document and to understand relationships between pieces of content. Use *semantic* markup whenever possible — that is to say use elements with specific meanings for specific purposes to convey the spirit of the markup.
44 |
45 | A well-written HTML document will make appropriate use of these semantic elements and leave all responsibility for controlling the presentation of the document to the CSS style sheet.
46 |
47 | #### HTML Standards and Browser Support
48 |
49 | All markup will be written using the latest HTML5 markup specifications from the W3C, as implemented by browsers and devices that meet project requirements. When creating markup be sure that the target environments support the techniques being implemented, or that there is a fall-back plan.
50 |
51 | Please use a common [HTML5 polyfill][link-poly] or HTML5 Shiv to enable styling and recognition of HTML5 elements in older devices' browsers.
52 |
53 |
58 |
59 | #### Doctype
60 |
61 | Always include a proper doctype to trigger standards mode. Omitting the doctype [triggers quirks mode][link-quirks] and should always be avoided. The HTML5 doctype is simple and easy to remember.
62 |
63 | ```markup
64 |
65 | ```
66 |
67 | #### Character Encoding
68 |
69 | All markup should be delivered as UTF-8, since it has the best support for internationalization. The character encoding should be designated in both the HTTP header and the head of the document via a meta tag. If the server happens to omit the HTTP header, browsers can take a guess at the character encoding and begins parsing and rendering the markup in a particular way. If there are inconsistencies, the browser will re-parse and re-render, throwing away all that work and starting over if it encounters the meta tag and its guess was incorrect. As a best practice, we always put the meta tag as early in the `` tag as early as possible — however server-settings are ideal.
70 |
71 | ```markup
72 |
73 | ```
74 |
75 | #### Optional and Self-closing Tags
76 |
77 | While current standards designate certain closing elements and even document level elements as optional, use all open and closing elements nested in the correct ways to ensure maximum compatibility and clarity of document structure.
78 |
79 | Generally speaking, self-closing XML (i.e. XHTML, XML) style tags are not necessary.
80 |
81 | ```markup
82 |
83 |
84 |
85 |
86 |
Lorem ipsum dolor sit amet, consectetur adipisicing elit:
87 |
88 |
Vero sunt veritatis magni sit odit,
89 |
voluptatum ratione suscipit.
90 |
91 | ```
92 |
93 | Unusual markup (or indeed, invalid) can lead to bugs in page rendering, DOM interpretation, or even how styles are applied, so it should be avoided whenever possible.
94 |
95 |
99 |
100 | ##### Validation
101 |
102 | [Valid markup][link-valid] is a goal but not a mandate. However, be aware validation can be an excellent starting place while debugging a Web page — especially if the problems are unusual.
103 |
104 | If it becomes necessary, please have reasons for invalid markup — otherwise it is just sloppy code.
105 |
106 | #### Indentation in HTML
107 |
108 | Indent nested elements and tags with single indentation settings, whatever they may be, for each level in the hierarchy of the document.
109 |
110 | ```markup
111 |
112 |
Lorem ipsumLorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod.
113 |
114 |
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
115 |
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
116 | consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
117 |
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
118 |
proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
119 |
120 |
121 | ```
122 |
123 | #### HTML5 Elements
124 |
125 | To provide additional semantic value to our documents, make use of HTML5 elements such as ``, ``, and `` where appropriate. However, in cases where the HTML needs to be as backwards-compatible as possible, do not apply IDs or classes to them, since older browsers do not understand these elements by default and will not apply styling to them.
126 |
127 | ```markup
128 |
129 |
130 | ...
131 |
132 |
133 | ```
134 |
135 | #### Attribute Values
136 |
137 | Use quotes to surround all attribute values in HTML, despite quotes being optional in HTML5. This maintains consistency between attribute values that contain whitespace and those that don't.
138 |
139 | ```markup
140 |
84 |
85 |
86 |