Doing well?

Today we will be talking about web standards.

This is my first time using a clicker so bear with me.

My name is Dom Farolino.

I am a senior at the University of Cincinnati.

I will doing a final internship in Japan and work on Chromium committer.

You can follow me on Twitter, check out my work on GitHub and feel free to e-mail me

any time after the talk if you have questions about the getting involved and the browser

stuff in general.

I want to talk about what this talk is.

I have three overarching goals I wanted to reach.

The first is provide a background and history into web standards and some of the organizations

that are responsible for their governance.

This could be its own talk but I will give a brief history on this.

Next I will talk about as a web developer how you can make use of a web standard.

A lot of us Google an API and figure out how it works but I want to talk about the technical

bits of the web standards and show how to make use of them and navigate that space.

Finally, I want to talk about how to get involved and share a bit about my own story of getting

involved with standards and working on the platform and, hopefully, encourage some of

you to do the same.

I would like to propose the idea we need a definition of a standard.

This largely depends on context if we define a new word.

I would like to propose my own definition for the purpose of this talk.

A document specifying observable effects of tech with multiple independent implementations.

Let's focus on the key points.

We care about the observable effects of technology.

If I run something, what does it do?

The last part multiple independent implementations -- I think this one is really important.

It is far from a new concept in technology.

You know, we have seen this with Unix operating system.

You can have your own and you get one and everybody has their own separate distribution

with sugar on top.

What I really care about is can I write application that works once everywhere and no matter what

operating system I am using that is in the Linux family of OSs it will work uniformly.

To make that environment conducive, we have a set of classic standards.

The same thing goes for web tech and this is primarily what I will talk about today.

I happen to know for a fact you can't go to the store and buy one HTTP.

It is just an idea and something you implement to make it compatible with other versions.

We can run JavaScript in a bunch of places.

It is like python.

We get it from the Python people.

I can run it in Chrome, Edge, Node and all kinds of different places.

The same goes for the star of the talk today which is web platform APIs.

I am no longer a Unix app developer but I am a web developer and I need to know the

same extensions will be there in Chrome and Firefox and more importantly work

the same.

Keynote is cool and has a bunch of symbols you can use.

Let's talk about where web APIs come from.

This is important.

We want to know where this stuff comes from and how we can make more of them.

I think the logical answer is probably JavaScript.

We use web APIs when using JavaScript.

Here is an example of a snapshot of the Chrome dev tools.

I can fetch super prominent sites on the internet and set timeout and stuff like that.

This stuff is part of the language but what is the language?

We know the big story of JavaScript being created in 10 days but it is a general purpose

programming language created for the purposes of the web.

It was plopped into an escape 2.0 and made it a candidate for standardization because

there was going to be multiple implementations of it.

We needed a group to come out and pick out this task of standardizing.

They have had success with the various engines.

There is a bunch of same implementations for this.

The standard looks like this.

It is big and hard to read and on GitHub under the TC39 page.

That stands for technical committee 39.

When we write a standard, how does it work?

We are predicting language so have to make it general.

We need a really strict separation of concern.

We need to be dealing with the language, syntax and semantics.

As a true scripting language, it should be able to be plopped into any hosting environment

but the language shouldn't have to know anything explicit about that environment.

We are used to using language in the browser and used to web APIs but the language doesn't

know about that.

They are effective mixed in and baked into the browsers and browsers can support a version

of this script and a bunch of web APIs that tag alongside this version that interplay

with it.

We have that coined -- TC39 is responsible for standardizing the JavaScript we know but

who is responsible for standardizing the web APIs?

Two big groups are primary responsible right now.

You have probably seen one of these logos.

We have the W3C and the WHATWG which stands for What Working Group and is the one I will

be talking about today.

The WHATWG stands for a long stream of text.

It was formed from branching off from the W3C.

They have an HTML language and it is the kitchen sink of the web platform.

They specify the interface we use to talk to the web and a lot of really cool things

like notifications and such.

But how are these things actually written?

If we are going to write a browser, we want to write ES, we start with this.

There is a lot of stuff and a bunch of exposed objects we get for free in JavaScript.

The array constructor and data array objects and weak maps and data structures that are

exposed.

We want our browser to be a little more powerful and have it be me, the DOM.

We can give it a query selector language and extend the language more.

The document is getting bigger but it is getting more powerful.

We would love to contact the network as well so we will give it network primitives like

fetch, request.

It would be really cool if we could do ourselves and give it a console method as well.

This is one way to write it it keep appending the text.

The WHATWG has standards for each idea that has separations of concerns and each standard

is responsible for the specifications of the web and JavaScript and things like that.

We get web APIs as a result alongside ES and JavaScript.

If we want to read the web APIs as web developers, and want to make use of them, we need to know

the anatomy of a standard and what is in these objects.

It is a mystical thing, kind of.

It is not too difficult to get involved.

It is all very open and happening right under our noses.

I was thinking about this for the talk and came to the conclusion there are two big parts

of standards to be aware of.

The first is algorithms.

I spend many evenings working on complete code and hacking and I like algorithms and

data structure stuff.

Algorithms are a set of steps to perform a task, really.

Let's look at an algorithm here.

There are five steps that run every time you invoke the console count.

You can see we are giving something called a label and basically the idea is if we have

seen this label before, when we called this, and then, you know, increment some number

we have associated with label otherwise we can set it to 1.

This is algorithm and this logger thing is abstract text for saying browser, show this

to the user in whatever way you see fit.

This algorithm answers questions like what is the initial value of a number associated

with a label and what happens when I call it?

The second important thing about specifying and using web APIs is understanding the look

and the feel.

I think that is really important.

What does it mean for an API to have a look and a feel?

I thought of this and I think it is kind of like, what does it mean to use the API as

a developer?

What is it called?

Hanging off a similar object?

Globally exposed?

Take anything?

Is there a bunch of parameters?

How many parameters?

Does it return anything?

A lot of us are using end to end and maybe Googling this stuff to find it but I want

to show you can show the standard.

Here is another part of the console standard.

A big scary block of text but let's focus on the bit that is complimentary to what we

were talking about before, the count method.

We have this that can tell you a little bit about it.

It is called count and exists under the console name space.

It's count type is void so I probably shouldn't expect to get anything from it.

It takes in a single parameter called label.

It is optional and its type is DOM string.

We don't know what DOM string is right now but let's assume it is a regular string.

It is pretty expressive but it isn't JavaScript because we care about types and it isn't C++

because we see other invalid things going on.

What exactly is this language?

It is walled web interface definition language and you will see it in a lot of specifications.

It forms a contract for the signature of web APIs you use.

When I go into the algorithm, I am running these steps, and I want to know what label

is.

I need to -- maybe I am making assumptions it is a string and operating on that accordingly

and that is really important for me to know.

I want to talk about how web IDL works in practice.

You will call console.count and give it whatever.

You can give it a symbol, object whatever.

But the second you do that the web IDL Sheriff comes in and says hold up!

You called console.counts and you can give it whatever you want, symbol if you wanted

to, give it a number, whatever, but I am making sure this contract is available.

I am going to make sure whatever you give me can pass as a DOM string.

If it does, we go to the algorithm and continue with a hopefully successful call.