-
Notifications
You must be signed in to change notification settings - Fork 5
/
articles.html
614 lines (552 loc) · 37.6 KB
/
articles.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
<!DOCTYPE html>
<!--
Interphase by TEMPLATED
templated.co @templatedco
Released for free under the Creative Commons Attribution 3.0 license (templated.co/license)
-->
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Sem Bakkum Everything Web</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<meta name="description" content="" />
<meta name="keywords" content="" />
<!--[if lte IE 8]><script src="css/ie/html5shiv.js"></script><![endif]-->
<script src="js/jquery.min.js"></script>
<script src="js/skel.min.js"></script>
<script src="js/skel-layers.min.js"></script>
<script src="js/init.js"></script>
<noscript>
<link rel="stylesheet" href="css/skel.css" />
<link rel="stylesheet" href="css/style.css" />
<link rel="stylesheet" href="css/style-xlarge.css" />
</noscript>
<!--[if lte IE 8]><link rel="stylesheet" href="css/ie/v8.css" /><![endif]-->
</head>
<body>
<!-- Header -->
<header id="header">
<h1><a href="index.html">Sem Bakkum</a></h1>
<nav id="nav">
<ul>
<li><a href="index.html">Home</a></li>
<li><a href="wafs.html">WAFS</a></li>
<li><a href="css.html">CSSTTR</a></li>
<li><a href="blog.html">Blog</a></li>
<li><a href="articles.html">Articles</a></li>
</ul>
</nav>
</header>
<section id="main" class="wrapper">
<div class="container">
<header>
<h1 id="nerd1">Taskmanagers</h1>
<p>Gulp</p>
</header>
<p><span class="image left"><img src="images/gulp.jpeg" alt="Gulp" /></span>
Taskmanagers are occuring more and more, but what are these taskmanagers or task runners and why should we use them? Task runners can do jobs that are to time consuming or to boring for developers to do. So now we have the abillity to automate these tasks for us through task runners and the setup is quite easy. Most of you have probably heard of Grunt or Gulp and maybe a lot more like Webpack, Broccoli or Cake, but the biggest ones are Grunt and Gulp. Gulp is picking up speed and becomming a good opponent for Grunt. So if you find yourself as a developer doing time consuming and boring tasks then a task runner could be the solution for you. For example task runners can do the following tasks for you:
<ul>
<li>Minification and concatenation of Javascript and CSS files</li>
<li>CSS preprocessing</li>
<li>Image optimisation</li>
<li>Unit testing and linting</li>
</ul>
In this article I will be focussing on one of these task runners named Gulp and guess what, setting up a task runner is like steeling candy from a baby. I have to mention that Gulp work on node so if you don't have that installed on your computer you can go to <a href="https://nodejs.org/en/" target="_blank">the node website</a> and install it from there.
</p>
<h2>Installing Gulp</h2>
<p>
Setting up Gulp is really easy. Open your terminal and as I mentioned above Gulp works on node, so if you're not sure if you have node or which version you're running you can type in the following commands:
<pre><code>node -v</code></pre>
If the terminal gives an output like command not found or something else you should need to install node from there website. Node works with the npm package manager, so if we want to install Gulp we will have to do that with npm. Installing Gulp is done with the following command:
<pre><code>npm install -g gulp</code></pre>
To install packages from npm you will always have to start your command with npm. It's possible that when your on an OSX or Linux system this command will not work. The fix is to use sudo. This lets the command know to run it as an administrator. Then the command will look like this:
<pre><code>sudo npm install -g gulp</code></pre>
The -g in the command means that we want to install the package globally.
To use gulp in your project you will have to go to your project folder via Terminal and install it there aswell. Make sure your project folder contains an package.json file. We need this file to write away the devDependencies. So installing Gulp can be achieved with the following command:
<pre><code>cd myprojectfolder</code></pre>
And then:
<pre><code>npm install gulp --save-dev</code></pre>
Same goes here for the sudo, if gulp won't install you will have to run the command as an administrator by adding sudo to it.
So now Gulp is installed to your project folder and saved in the devDependencies of the packages.json file.
</p>
<h2>Installing Gulp plugins</h2>
<p>Now that Gulp is installed lets start installing some plugins that we can use in our tasks. To find the plugins we need we can search Gulps plugin library <a href="http://gulpjs.com/plugins/" target="_blank">here</a>, but lets start with some easy to use plugins. To install these we have to go to our project folder via the terminal, but we're probable still in that folder. We are going to install plugins for the following tasks:
<ul>
<li>Minify CSS (gulp-clean-css)</li>
<li>CSS autoprefixer (gulp-autoprefixer)</li>
<li>Compress images (gulp-imagemin)</li>
<li>Live reload (gulp-livereload)</li>
<li>Uglify JavaScript (gulp-uglify)</li>
<li>JS hint (gulp-jshint)</li>
</ul>
We will be installing these plugins with the following commands:
<h3>Minify CSS</h3>
<pre><code>npm install gulp-clean-css --save-dev</code></pre>
<h3>CSS autoprefixer</h3>
<pre><code>npm install --save-dev gulp-autoprefixer</code></pre>
<h3>Compress images</h3>
<pre><code>npm install --save-dev gulp-imagemin</code></pre>
<h3>Live reload</h3>
<pre><code>npm install --save-dev gulp-livereload</code></pre>
<h3>Uglify JavaScript</h3>
<pre><code>npm install --save-dev gulp-uglify</code></pre>
<h3>JS hint</h3>
<pre><code>npm install jshint gulp-jshint --save-dev</code></pre>
</p>
<p>
<h2>Minify CSS</h2>
First we will start setting up our gulpfile.js in the root folder of our project. In this gulpfile we will start with first including gulp and then including our plugins. Our first piece of code will look like this:
<pre><code>// Include gulp
var gulp = require('gulp');</code></pre>
Now we can also include our minify CSS plugin as follows:
<pre><code>var gulp = require('gulp');
var cleanCSS = require('gulp-clean-css');
gulp.task('minify-css', function() {
return gulp.src('styles/*.css')
.pipe(cleanCSS({debug: true}, function(details) {
console.log(details.name + ': ' + details.stats.originalSize);
console.log(details.name + ': ' + details.stats.minifiedSize);
}))
.pipe(gulp.dest('dist'));
});</code></pre>
What we are doing here is telling Gulp to get all the files with a .css extension from the styles folder and minify these. We also want Gulp to debug the files if there should be any errors. When everyting is oké Gulp will log us the original file size and the new smaller file size. When all this is achieved Gulp wil put the new files in your dist folder. If you haven't made a dist folder Gulp will automaticly make one for you. Now lets extend the use of our Gulp file by adding the rest of the plugins.
</p>
<p>
<h2>CSS autoprefixer</h2>
<pre><code>var gulp = require('gulp');
var cleanCSS = require('gulp-clean-css');
var autoprefixer = require('gulp-autoprefixer');
gulp.task('minify-css', function() {
return gulp.src('styles/*.css')
.pipe(cleanCSS({debug: true}, function(details) {
console.log(details.name + ': ' + details.stats.originalSize);
console.log(details.name + ': ' + details.stats.minifiedSize);
}))
.pipe(gulp.dest('dist'));
});
gulp.task('prefix', function () {
return gulp.src('styles/*.css')
.pipe(autoprefixer({
browsers: ['last 2 versions']
}))
.pipe(gulp.dest('dist'));
});</code></pre>
Now we are telling gulp to also include autoprefixer and get all the files with the .css extension in the styles folder. With the option browsers: ['last 2 versions], we are telling the plugin to prefix the css for the last 2 versions of all major browsers. Eventually when this is done move the new files to the dist folder of our project.
</p>
<p>
<h2>Compress images</h2>
<pre><code>var gulp = require('gulp');
var cleanCSS = require('gulp-clean-css');
var autoprefixer = require('gulp-autoprefixer');
var imagemin = require('gulp-imagemin');
gulp.task('minify-css', function() {
return gulp.src('styles/*.css')
.pipe(cleanCSS({debug: true}, function(details) {
console.log(details.name + ': ' + details.stats.originalSize);
console.log(details.name + ': ' + details.stats.minifiedSize);
}))
.pipe(gulp.dest('dist'));
});
gulp.task('prefix', function () {
return gulp.src('styles/*.css')
.pipe(autoprefixer({
browsers: ['last 2 versions']
}))
.pipe(gulp.dest('dist'));
});
gulp.task('minify-img', () =>
gulp.src('src/images/*')
.pipe(imagemin())
.pipe(gulp.dest('dist/images'))
);
</code></pre>
Actually we are dping the same thing as we did before, we're tellng Gulp where to get the files, what to do with them and where to put the modified files when it's done. So now we're telling get all the files in the images folder, minify these and place them in the dist/images folder.
</p>
<p>
<h2>Live reload</h2>
Live reload is a great plugin, everytime Gulp sees a change or makes a change to the files it automatically reloads your webpage.
<pre><code>var gulp = require('gulp');
var cleanCSS = require('gulp-clean-css');
var autoprefixer = require('gulp-autoprefixer');
var imagemin = require('gulp-imagemin');
var livereload = require('gulp-livereload');
gulp.task('minify-css', function() {
return gulp.src('styles/*.css')
.pipe(cleanCSS({debug: true}, function(details) {
console.log(details.name + ': ' + details.stats.originalSize);
console.log(details.name + ': ' + details.stats.minifiedSize);
}))
.pipe(gulp.dest('dist'));
});
gulp.task('prefix', function () {
return gulp.src('styles/*.css')
.pipe(autoprefixer({
browsers: ['last 2 versions']
}))
.pipe(gulp.dest('dist'));
});
gulp.task('minify-img', () =>
gulp.src('src/images/*')
.pipe(imagemin())
.pipe(gulp.dest('dist/images'))
);
gulp.task('watch', function() {
livereload.listen();
gulp.watch('styles/*.css', ['prefix', 'minify-css']);
gulp.watch('src/images/*', ['minify-img']);
});
</code></pre>
We are telling live reload to keep track of changes in certain files, like our styles.css. If there are changes use prefix and minify-css to handle these changes. At that point these two tasks will take over. We will keep adding tasks to out live reload during the setup of our gulpfile.js.
</p>
<p>
<h2>Uglify JavaScript</h2>
<pre><code>var gulp = require('gulp');
var cleanCSS = require('gulp-clean-css');
var autoprefixer = require('gulp-autoprefixer');
var imagemin = require('gulp-imagemin');
var livereload = require('gulp-livereload');
var uglify = require('gulp-uglify');
var pump = require('pump');
gulp.task('minify-css', function() {
return gulp.src('styles/*.css')
.pipe(cleanCSS({debug: true}, function(details) {
console.log(details.name + ': ' + details.stats.originalSize);
console.log(details.name + ': ' + details.stats.minifiedSize);
}))
.pipe(gulp.dest('dist'));
});
gulp.task('prefix', function () {
return gulp.src('styles/*.css')
.pipe(autoprefixer({
browsers: ['last 2 versions']
}))
.pipe(gulp.dest('dist'));
});
gulp.task('minify-img', () =>
gulp.src('src/images/*')
.pipe(imagemin())
.pipe(gulp.dest('dist/images'))
);
gulp.task('compress', function (cb) {
pump([
gulp.src('lib/*.js'),
uglify(),
gulp.dest('dist')
],
cb
);
});
gulp.task('watch', function() {
livereload.listen();
gulp.watch('styles/*.css', ['prefix', 'minify-css']);
gulp.watch('src/images/*', ['minify-img']);
gulp.watch('lib/*.js', ['compress']);
});
</code></pre>
For this plugin we are including uglify and pump, we are using pump to properly handle error conditions with Node streams. What we are telling the task is get all the files with a .js extension in the lib folder and uglify these, when you're done put them in the dist folder. Now we have to add this one to our livereload and we are done with uglify.
</p>
<p>
<h2>JS hint</h2>
<pre><code>var gulp = require('gulp');
var cleanCSS = require('gulp-clean-css');
var autoprefixer = require('gulp-autoprefixer');
var imagemin = require('gulp-imagemin');
var livereload = require('gulp-livereload');
var uglify = require('gulp-uglify');
var pump = require('pump');
var jshint = require('gulp-jshint');
gulp.task('minify-css', function() {
return gulp.src('styles/*.css')
.pipe(cleanCSS({debug: true}, function(details) {
console.log(details.name + ': ' + details.stats.originalSize);
console.log(details.name + ': ' + details.stats.minifiedSize);
}))
.pipe(gulp.dest('dist'));
});
gulp.task('prefix', function () {
return gulp.src('styles/*.css')
.pipe(autoprefixer({
browsers: ['last 2 versions']
}))
.pipe(gulp.dest('dist'));
});
gulp.task('minify-img', () =>
gulp.src('src/images/*')
.pipe(imagemin())
.pipe(gulp.dest('dist/images'))
);
gulp.task('compress', function (cb) {
pump([
gulp.src('lib/*.js'),
uglify(),
gulp.dest('dist')
],
cb
);
});
gulp.task('lint', function() {
return gulp.src('lib/*.js')
.pipe(jshint())
.pipe(jshint.reporter('default'));
});
gulp.task('watch', function() {
livereload.listen();
gulp.watch('styles/*.css', ['prefix', 'minify-css']);
gulp.watch('src/images/*', ['minify-img']);
gulp.watch('lib/*.js', ['compress', 'lint']);
});
</code></pre>
Here we added the lint task. Each time there is a change in a .js file in the lib folder the lint task will run through that file and log the errors in our terminal, if there are any errors. These errors will consist of semantically errors in JavaScript. Eventually we also add this task to our livereload task.
</p>
<p>
<h2>The default task</h2>
At last we can make a default task, this task will run all the tasks that we have created just by using one command in our terminal.
The default task will look like this:
<pre><code>var gulp = require('gulp');
var cleanCSS = require('gulp-clean-css');
var autoprefixer = require('gulp-autoprefixer');
var imagemin = require('gulp-imagemin');
var livereload = require('gulp-livereload');
var uglify = require('gulp-uglify');
var pump = require('pump');
var jshint = require('gulp-jshint');
gulp.task('minify-css', function() {
return gulp.src('styles/*.css')
.pipe(cleanCSS({debug: true}, function(details) {
console.log(details.name + ': ' + details.stats.originalSize);
console.log(details.name + ': ' + details.stats.minifiedSize);
}))
.pipe(gulp.dest('dist'));
});
gulp.task('prefix', function () {
return gulp.src('styles/*.css')
.pipe(autoprefixer({
browsers: ['last 2 versions']
}))
.pipe(gulp.dest('dist'));
});
gulp.task('minify-img', () =>
gulp.src('src/images/*')
.pipe(imagemin())
.pipe(gulp.dest('dist/images'))
);
gulp.task('compress', function (cb) {
pump([
gulp.src('lib/*.js'),
uglify(),
gulp.dest('dist')
],
cb
);
});
gulp.task('lint', function() {
return gulp.src('lib/*.js')
.pipe(jshint())
.pipe(jshint.reporter('default'));
});
gulp.task('watch', function() {
livereload.listen();
gulp.watch('styles/*.css', ['prefix', 'minify-css']);
gulp.watch('src/images/*', ['minify-img']);
gulp.watch('lib/*.js', ['compress', 'lint']);
});
gulp.task('default', ['minify-css', 'prefix', 'minify-img', 'compress', 'lint', 'watch']);
</code></pre>
We can run this default task by typing the following command in our terminal:
<pre><code>gulp</code></pre>
</p>
<p>I hope this will be a good start for everyone that wants to try Gulp.</p>
<p>
<h2>Sources</h2>
<a href="http://andy-carter.com/blog/a-beginners-guide-to-the-task-runner-gulp">Source 1</a><br />
<a href="http://blog.cozycloud.cc/technic/2014/06/18/task-runners-comparison/">Source 2</a><br />
<a href="http://gulpjs.com/plugins/">Source 3</a><br />
<a href="https://www.npmjs.com/package/gulp-imagemin/">Source 4</a><br />
<a href="https://www.npmjs.com/package/gulp-clean-css/">Source 5</a><br />
<a href="https://www.npmjs.com/package/gulp-jshint/">Source 6</a><br />
<a href="https://www.npmjs.com/package/gulp-uglify/">Source 7</a><br />
<a href="https://markgoodyear.com/2014/01/getting-started-with-gulp/">Source 8</a><br />
<a href="https://github.com/vohof/gulp-livereload">Source 9</a><br />
<a href="https://scotch.io/tutorials/a-quick-guide-to-using-livereload-with-gulp">Source 10</a>
</p>
</div>
</section>
<section id="main" class="wrapper">
<div class="container">
<header>
<h1 id="nerd1">Github</h1>
<p>Workflow</p>
</header>
<p><span class="image right"><img src="images/github.png" alt="Github" /></span>
Git is a wonderfull tool for developers, but how do you actually have to use git or work with it. Many companies have their own way of working with github, but which workflow is the correct one? Let's start with explaining what github is.
<h2>What's Github</h2>
Some people call Github a publishing tool, a version control system or a collaboration platform. Well actually Github is all of these in one and this is how Github describes what Github is: <blockquote>GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere.</blockquote>
In Github you can make your own repository (Actually your own project) and host these repositories remote and local. The cool thing is that people can join these repositories and also work on them or even copy them to there own account. Copying these repositories is called making a fork, but why is Github so cool? Well you will find out in this article.
</p>
<p>
<h2>Creating a repository</h2>
The first thing we want to do is go to <a href="https://github.com/">Github</a> and create and account. When you have done that you can go to your profile, click repositories and you will see a green button that says new. By clicking on this button we will create a new repository. You can give your repositorie a name and a short description (like what the project/repo is about) and then select initialize this repository with a README.
<img alt="github create repository" src="images/create-new-repo.png" width="800px"> <br />
At last we click create repository and our repository is made.
</p>
<p>
<h2>Github branches</h2>
Github works with branches. In these branches you build your features or fixes. By default your repository has a branch called master. This is your main branch where all your features and fixes will be merged or pushed to. The main rule is that everything (so all the code) in master is always deployable. This is the point we start to handle the Github workflow, which is as follows:
<p>
<ul>
<li>Anything in the master branch is deployable</li>
<li>To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)</li>
<li>Commit to that branch locally and regularly push your work to the same named branch on the server</li>
<li>When you need feedback or help, or you think the branch is ready for merging, open a pull request</li>
<li>After someone else has reviewed and signed off on the feature, you can merge it into master</li>
<li>Once it is merged and pushed to ‘master’, you can and should deploy immediately</li>
</ul>
</p>
Now that we know these basic rules lets create our first branch off of master.
</p>
<p>
<h2>Creating a branch</h2>
When you are creating a branch you are actually making a copy of master which you work on locally. There are multiple options to create a branch, we can do it on the github website itself or create one via our terminal. When we make a new branch via our terminal we first have to navigate to the folder of our local Github repository and then type in the following command
<p><pre><code>git checkout -b your-new-branch-name</code></pre></p>
Git will automatically switch to your new branch, so from this point you can make changes to your code and these changes will be stored in your new branch. This code changes or new pieces of code can be a feature you are working on or a fix that you are making. When you are done you can push your new branch to the server (also called to remote).
</p>
<p>
<h2>Pushing a branch form local to remote</h2>
To push our new branch to the remote(server) we have to use a few commands. At first we have to add all our changes, we can do this by using the following command:
<p><pre><code>git add .</code></pre></p>
By using the . we are telling Git that it can add all the changes we made.
Next we need to commit our new feature and also tell what we have committed. We can do that with the following command:
<p><pre><code>git commit -am"Our commit message"</code></pre></p>
The last thing we have to do is push our new branch with a commit to our remote (server), we can do this with the following command:
<p><pre><code>git push origin your-new-branch-name</code></pre></p>
With this command our branch is pushed to the remote where it will wait for us to make a pull request.
</p>
<p>
<h2>Making a pull request</h2>
Follow these steps to make a pull request.
<table>
<thead>
<tr>
<th>Step</th>
<th>Screenshot</th>
</tr>
</thead>
<tbody>
<tr>
<td>Click the <span class="octicon octicon-git-pull-request"></span> <strong>Pull Request</strong> tab, then from the Pull Request page, click the green <strong>New pull request</strong> button.</td>
<td><img width="500px" src="images/pr-tab.gif" alt="pr-tab"></td>
</tr>
<tr>
<td>Select the branch you made, <code class="highlighter-rouge">readme-edits</code>, to compare with <code class="highlighter-rouge">master</code> (the original).</td>
<td><a href="pick-branch.png"><img width="500px"src="images/pick-branch.png" alt="branch"></a></td>
</tr>
<tr>
<td>Look over your changes in the diffs on the Compare page, make sure they’re what you want to submit.</td>
<td><a href="diff.png"><img width="500px" src="images/diff.png" alt="diff"></a></td>
</tr>
<tr>
<td>When you’re satisfied that these are the changes you want to submit, click the big green <strong>Create Pull Request</strong> button.</td>
<td><a href="create-pr.png"><img width="500px" src="images/create-pr.png" alt="create-pull"></a></td>
</tr>
<tr>
<td>Give your pull request a title and write a brief description of your changes.</td>
<td><img width="500px" src="images/pr-form.png" alt="pr-form"></td>
</tr>
</tbody>
</table>
When you have made a pull request other developers that are working on the same project can review the code you have made, when they also so the code is okay you can merge the code with master.
</p>
<p>
<h2>Merge your new branch</h2>
To merge your pull request with master just hit the merge pull request button. Git will automatically check if your pull request is mergeable with the master branch. If this isn't possible Git will let you know that there is a merge conflict. Git will provide you with the information and the steps you have to take to fix this merge conflict. If everything is found good Git will let you know the pull request is succesfully merged.
<img src="images/merge-button.png" alt="https://guides.github.com/activities/hello-world/" width="800px"> <br />
<img src="images/delete-button.png" alt="https://guides.github.com/activities/hello-world/" width="800px"> <br />
</p>
<p>
<h2>Sources</h2>
<a href="https://guides.github.com/activities/hello-world/">Source 1</a><br />
<a href="http://scottchacon.com/2011/08/31/github-flow.html">Source 2</a><br />
<a href="https://git-scm.com/docs/git-checkout-index">Source 3</a><br />
</p>
</div>
</section>
<section id="main" class="wrapper">
<div class="container">
<header>
<h1 id="nerd1">Accessibility</h1>
<p>HTML 5</p>
</header>
<p><span class="image left"><img src="images/html_table.png" alt="Accessibility" /></span>
Throughout the Minor web-development I saw that my interest went in the direction of accessibility, that's the reason of writing this article. During the minor I found myself making mistakes in the accessibility that were quite foolish. For example when to use a section or a div, or a new thing I learned called structured headings. So here is my new look on accessibility.
</p>
<p>
<h2>What is accessibility</h2>
Accessibility to me means that everything we make on the web is useable for everyone in every browser. So this means we don't only have to look at writing good semantic HTML, but also making sure that there are good fallbacks for new HTML 5 features. That covers the every browser part, but with everyone we should also look at people with disabilities. Based on numbers brought to us by the world health organization 15% of the worlds population lives with some form of disability. So approximately 1 billion persons on this planet have a disability and these disabilities can be categorized in to 4 groups:
<ul>
<li>Visual</li>
<li>Motor</li>
<li>Cognitive</li>
<li>Auditory</li>
</ul>
Most of these users, but not all of them, use assistive devices or software to browse the web and this can be on desktops, but also on mobile devices. The software or devices they use can be screenreaders, which read the contents of the page out loud, but also a braille display, which converts text on the screen to braille. The pitty of the web (but also the beauty) is that everyone can make everything on the web, but we don't always keep these 1 billion persons in mind that could also want to use our product on the web. For that accessibility is the most important thing we need to implement in to our everyday coding skills. Let's start with a little intro to writing semantic forms.
</p>
<p>
<h2>Semantic forms</h2>
Browsers already give us a lot of functionality for a form by just declaring the correct elements and writing the HTML semantically. That's a mistake I made during this minor. I went to JavaScript to quickly before realizing I didn't need JavaScript, or only just a little bit, to fullfill what I wanted to accomplish with the form. Here is a good tip:</p> <blockquote>Visit <a href="https://html.spec.whatwg.org/multipage/">whatwg.org</a></blockquote>
<p>Whatwg describes the form spec as follows: <i>"The form element represents a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing."</i>
So how do we write a form that is semantically correct, well let's just cut to the chase and show some code!</p>
<p><img src="images/form%20example.png" alt="Code example of a semantic form in HTML"><br /></p>
Because we have multiple inputs we make separate paragraphs for each input with their own label. We use labels to let people with screenreaders know what the input field is about. Now a days you see a lot of form which use the placeholder of the input as a label, but how should for example blind people now what the input is about since screenreaders don't read a placeholder text. As you can see the label has a "for" attribute. This attribute tells the user which type of input the label is for, but when the input, or thing we are labeling, is a descendant of the label there is no need to use the "for" attribute. So the semantic will look like this:</p>
<p><img src="images/formwithoutfor.png" alt="Form semanti without using the for attribute"><br /></p>
The only thing our form misses is a button, why a button and not an a tag? An a tag is used for links and not for actions we want to be done. We can give the button a type of submit which tells the browser to do something with the form based on the method we provided the form with. This method can be a post or a get method. Post meaning we want to send the filled in form to our server, or when it is a search form we maybe want to get information from our server by using the get method. Either way we also have to include the form with a action. The action contains the URI we want to send the form to or get information from. The type submit isn't the only attribute type we can give to a button. In total there are three types we can address to a button within a form:
<p>
<ul>
<li>A submit button sends the form's data to the web page defined by the action attribute of the <form> element.</li>
<li>A reset button resets all the form widgets to their default values immediately. From a user experience point of view, using these buttons is now considered bad practice and should be avoided; it makes it far too easy for the user to accidentally lose all their work.</li>
<li>An anonymous button has no inherent meaning; instead, you use JavaScript to give it a function.</li>
</ul>
</p>
For more information on semantic forms I recommend you to take a look at the following link: <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/How_to_structure_an_HTML_form">How to structure an HTML form</a>
</p>
<p>
<h2>Diviritus</h2>
When developers don't know which HTML element they should use they tend to use a <div> tag. Most of the times there is a tag that can be used instead of a div and when you use the div you end up using ARIA to describe what the tag actually is. What you see around the web is that many developers use div's when they can also use a <section> tag. I saw this problem in a project I was doing for the minor. So to get things clear, when should you use a div and when should you use a section? Well the answer is pretty simple, use a div tag when its purpose is purely for styling. Use a section tag when you know that it will contain a heading. This is how Mozilla Developers Network (MDN) described the div element:
<p><blockquote>The HTML <div> element (or HTML Document Division Element) is the generic container for flow content, which does not inherently represent anything. It can be used to group elements for styling purposes (using the class or id attributes), or because they share attribute values, such as lang. It should be used only when no other semantic element (such as <article> or <nav>) is appropriate.</blockquote></p>
And this is how whatwg.org describes the section tag:
<p><blockquote>The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.</blockquote></p>
So how should a semantically correct section look? Like this:
<p><img src="images/semanticsection.png" alt="code for an semantic use of the section tag"></p>
The way this piece of code is build up with the use of the headings brings me to the following, something called structured heading. I first heard of this during a talk I attended at the minor from a blind web-developer.
</p>
<p>
<h2>Structured headings</h2>
To make structured headings the first heading on the page must be a <h1>, this heading will contain what the page is about. So for the home page this could be the the name of the website in the header. W3C describes it as followed:
<p><blockquote>[I]n HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not “skip levels (e.g., H1 directly to H3).</blockquote></p>
The benefit of structered headings is that people that use screenreaders can skip through the content pretty fast. With there screenreader they can say give me all headeings on the page. So lets say our h1 is the name of our website, the first h2 is “what we do”, the second h2 is “our product” and the third h2 is “our partners”. Screenreader users will get a list that like this:
<p>
<ul>
<li>H1: Website name</li>
<li>H2: What we do</li>
<li>H2: Our product</li>
<li>H2: Our partners</li>
</ul>
</p>
In this way the users can read the page much quicker. If you wouldn’t have structured headings a user must either read the complete page or tab through the whole page if they would only want to know who your partners are.
<p>
To top it of here are a few checklists you can use to make sure you are writing HTML that is more semantic and better accessible.<br />
<a href="https://www.utexas.edu/learn/accessibility/samplehtml.html">Accessible HTML Samples</a><br />
<a href="http://accessibility.psu.edu/checklist/">Accessibility Checklist</a>
</p>
</p>
<p>
<h2>Sources</h2>
<a href="https://html.spec.whatwg.org/multipage/semantics.html#the-section-element">Source 1</a><br />
<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/div">Source 2</a><br />
<a href="https://html.spec.whatwg.org/multipage/forms.html#the-form-element">Source 3</a><br />
<a href="https://www.youtube.com/watch?v=8dr_IUGwsO0&list=PLNYkxOF6rcIAWWNR_Q6eLPhsyx6VvYjVb&index=13">Source 3</a><br />
<a href="http://www.clarissapeterson.com/2012/11/html5-accessibility/">Source 3</a><br />
</p>
</div>
</section>
</body>
</html>