Online Marketing

Hitchhikers Guide to Web Standards

This is my first time using a clicker, so bear with me here. The talk is called Hitchhiker’s Guide to web standards and to kick things off, I’d like to introduce myself, my name is DOM fairly. No, yes, I’m named after the platform that we all know and love, I’m a senior at the University of Cincinnati in Ohio, and previously I’ve held internships at Microsoft and Mozilla working out in Firefox, and I’m going to be doing a final internship at Google in Japan.

Actually, working on chromium in the web platform, so currently I’m a chromium committer, which is basically fancy speak for someone who has write access and you can approve certain stuff and I’m also what working group standards editor. So if you don’t know what that last one is, that’s that’s primarily we’re going to be talking about. Today. I said from that you can follow me on Twitter and check out my work on github and feel free to email.

Me anytime. You know, during or after the talk, Dom a crummy org, there’s any questions about getting involved in the web platform at web standards and browsers stuff in general. So I want to talk about what this talk actually is. I kind of have three overarching goals that I wanted to reach when working on this talk and the first one is just provide a background in history and to web standards and some of the organizations that are responsible for their governance and their authorship.

This could really be an its own talk, but I know we didn’t come here for a history lesson, so I’m just going to give a brief, a brief history on this to kind of set the stage. Next I want to talk about. You know as a web developer, how can you actually make use of a web standard right? A lot of us go to mdn or Google some API and figure out how it works. But I kind of want to talk about the technical bits of web standards and show how you can make use of them and how to read them and how to navigate that space.

Finally, I want to talk about how you can get involved. I want to share a bit about my own story of getting involved with web standards and working on the web platform and hopefully encourage some of you to do the same so to kind of set the stage for the talk I’d like to propose. You know the idea that we need a definition of a standard. Now largely this depends on context. If we’re going to define you know a new word, and so I’d like to propose my own definition for the purposes of this talk, it’s a little bit wordy so bear with me a document specifying observable effects of technology with multiple independent implementations.

Now it’s kind of wordy, like I said so, let’s just focus on some key points right we care about the observable effects of technology. What are the side effects of it? How if I run something, what does it do, how does it look and feel? How can I actually use it, and, and does it change depending on you know where I’m where I’m using it from, and this last part is multiple independent implementations technology with multiple independent implementations? I think this is really important and it’s it’s far from a new concept.

In technology you know, we’ve seen this with like UNIX operating systems, for example, I can kind of make my own version of you know my own of Linux distribution. You can have your own Linux, distribution and, and you get one and you get one and everybody can have their own. You know separate distribution with sugar on top of it, but what I really care about as a desktop app developer. If I were one is you know, can I write an application that works once everywhere and no matter what operating system I’m using for you know, that’s in the UNIX family of os is that it’s going to work uniformly so to kind of make that environment conducive To that you know: interoperable behavior among the different operating systems we’ve had the set of plastic standards developed to kind of unify this observable behavior.

The same thing goes for web tech, and this is primarily what I’m going to talk about today. Those these are not actually to scale, though, but I happen to know for a fact that you can’t go to the store and you buy one HTTP. You know it’s a protocol, it’s just it’s just an idea and it’s something that you can implement to kind of make it compatible with other versions of this. This protocol and the same basically goes for JavaScript as well right.

We can run JavaScript in a bunch of different places, unlike maybe Python, it’s kind of like we have one Python. We get from the Python people and that’s kind of it, but with JavaScript I can run it in chrome. I can run it in an edge on the chakra engine and I can run it a node in all kinds of different places and the same goes for kind of the star of the talk today, which is the web platform API.

So I’ve gone through a career change, I’m now no longer a UNIX app developer, but I’m a web developer. And so I need to know that the same api’s that exists in chrome also we’re going to be there in Firefox and, more importantly, that they’re all going to work the same and kind of function uniformly. That’s really important, probably the biggest thing I learned when making this slide is, though, that keynote is really cool and has a bunch of different goofy symbols that you can use.

So I thought that that little dude look like a face, so I dressed him up getting some underwear and a hat and stuff like that. So let’s talk about where web api’s come from right. This is important. We are. We are web developers and we kind of want know where the stuff comes from and how we can make more of them. I personally think the logical answer probably is JavaScript right. We use Web API when we’re using JavaScript.

For example, here’s a snapshot of the chrome dev tools and when I’m you know right, I can write things like a for loop and a while loop, but I can also fetch you know super prominent websites on the internet like that one and I can use set Timeout and all kinds of stuff like that, so it stands the reason that this kind of stuff is part of the language. Now we have to talk about what is the language or what does JavaScript I’m just going to fly through this slide, because we all know the big story of Brendan Eich and he created it in 10 days and whatever, but it’s just a general-purpose programming language.

That is created for the purposes of the web. I was plopped into netscape 2.0 and that made it a really interesting thing. It made it a candidate for Standardization because there was going to be multiple independent implementations of it, and so we needed some group that could come by and pick up. The task of standardizing and Ekman did this. They stand for the European computer Manufacturers Association and they created ACMA script and we’ve had some success with this with the various engines.

For example, there’s a bunch of different implementations of the same sort of technology, and you probably have seen this list or something similar to it before the standard looks something like this. It’s really big, it’s really hard to read, but it’s on github and it’s hosted under the tc39 s. Github page tc39 just stands for technical committee 39. So when we’re writing the standard writing atma script, how does it work right? What are we going to put in the standard we’re making a new language, so we have to make them make it really general.

So we need a really strict separation of concerns between all the contents in the standards in the standard. We just need to be dealing with the language syntax in the semantics and then some of the constructs and the primitives and that’s the true scripting language. It should be able to be plopped into any host environment, but the language itself shouldn’t actually have to know anything explicit about that environment.

Now we’re really used to using that language in a web browser, so we’re used to web api’s and stuff like that, but the language itself doesn’t actually know about those things. So web apos are not part of the ACMA script language or the jour JavaScript language they’re. Effectively, mix-ins and they’re baked into browsers and browsers, can support, basically, a version of echo script as their JavaScript engine and a bunch of web api is that we can use that kind of tag along alongside this version.

Rackham script, that kind of interplay with it, and so we have hakama right there responsible for and tc39 are responsible for standardizing ACMA script and javascript that we all know and love so who’s responsible for standardizing the web api. So we’ve kind of heard a little bit about this today from some of the talks. There’s two big groups right now that are responsible for this primarily you’ve, probably seen at least one of these logos before we have the w3c and the what working group and the what working group denoted by the question mark on the right is what I’m going to Be talking about primarily today, this is the organization.

I told you all that I was a part of at the beginning. So the what working group stands, it’s just an acronym. Unfortunately, so it stands for a long string of text that kind of summarizes what we do. It was formed in 2004 after a w3c workshop. Basically, they decided to kind of branch off from the w3c and create their own canonical standards that specified the web platform. So they have an HTML standard, which kind of defines HTML language and the parser and the event loop and a lot of the it’s.

Basically, the kitchen sink of the web platform is actually what it calls itself to, and they have. You know they specified the Dom API is the interface that we use to talk to the web and and some networking primitives like fetch and streams, and a lot of really cool things like notifications and primitives. But how are these things actually written right if we’re going to write a browser and we want to write ACMA script? You know we start with the JavaScript engine.

Okay. Now, if we read the ACMA scripts back, there’s a lot of stuff in there, but there’s also a bunch of exposed objects that would get for free and JavaScript. We get things like the array, constructor and you know date, objects and week, maps and all kinds of data structures that are natively exposed through ACMA scripts, but we want our browser to be a little more powerful. You know we want it to have me the Dom.

So we give it, you know a document object. We can add a couple more paragraphs onto the end and give it a query. Selector method and we’ve kind of extended our language a little bit more, the documents getting bigger, but it’s getting more powerful. So we also would love to to you know, contact the network as well, so we’ll give it some networking primitives things like fetch things like request and it’d, be really cool.

If we could do ourselves a good service and debug our code, so we’ll maybe give it a console object as well a bunch of methods. On top of that, this is one way to write. It just keep appending text onto the same to the same massive documents, but it’s going to get pretty lengthy and unmaintainable. So the what working group maintains separate standards for each of these kind of ideas that have a separation of concerns and each standard is responsible for talking about how they enter leave with the other specifications and the web as well as that can script and things like That and as a result, we get web api is alongside ACMA script and java script.

Now, if we want to read these web api’s as web developers as web developers, we want to make use of them. We need to kind of know the anatomy of a standard. We need to know what is actually in these documents, because it’s kind of a mystical thing in mystical process and and it’s actually really – you know not too difficult to get involved and it’s it’s all very open and happening right under right under our noses.

So I was thinking about this a lot for this talk, and I kind of came to the conclusion that there are two big parts of standards to kind of be aware of. The first is algorithms, so I don’t know about you guys. I love algorithms spend many. An evening as it were working on leet code and hacker ranked stuff – and I really like algorithms and data structures stuff, I think that kind of theory of computation is really really cool.

Algorithms are really just a set of steps to perform a task. So let’s go ahead and take a look at an algorithm inside a web standard right. We have the console standard and there’s a bunch of different methods on there. If you haven’t heard of it, there’s one called console dot count and here’s the algorithm specified in the standard. There’s five steps that run every time you invoke console dot, count, there’s a couple that we really care about.

For the purposes of this talk, though, you can see we’re given something called a label, and basically the idea of this algorithm is, if we’ve seen this label before, when we’ve called this in this function, then you know increment some number that we have that we have Associated with label, otherwise we can set it to one. This is the algorithm and then eventually we want to just print it to the screen.

This logger thing is just abstract text for saying, hey browser, you know show this to the user in whatever way you see fit. This is nice because I kiss a web developer. I could come in here check out the algorithm and it answers a couple questions for me. Like you know, what is the initial value of the number that is associated with a label and what happens every time? I call it and what can I expect, and so we can read the algorithm and kind of understand what’s going on now.

The second important thing about specifying and using web api is understanding the look in the so I think that’s really important. What’s it mean for an API to have a look and feel so I thought of this, and I think it’s kind of like you know: what’s it mean to to use the API as a developer? What’s it called? Where is it hanging off of some other object? Is it just globally exposed? Does it take anything? These are you know a bunch of parameters? How many parameters does it return? Anything? This stuff is really important for us to know, and a lot of us here are used to going to mdn and then maybe googling.

This kind of stuff to find it, but I also want to show that you can just go to the standard. So here’s another part of the console standard that the what working group maintains it’s a big scary block of text. But let’s focus on the bit. That’s complementary to what we were talking about before the count method, so we have this right. This kind of can tell you a little bit about it right, okay, so it’s called count.

It exists under the console, namespace, so console that count that kind of make sense. How I would use it it’s of type void, so I probably shouldn’t expect to get anything from it, just not going to really return anything, but I might do stuff and it takes in a single parameter called label it’s optional and its type is Dom string. So we don’t know what Dom string is right now, but let’s just assume it’s just a regular string.

That gives us some some cool information. It’s pretty expressive, but it’s not JavaScript, because we care about types and and it’s not C++, because we see other invalid things going on around here. So what exactly is this language? It’s called web IDL in a sense for web interface. Definition, language and you’ll see it in a lot of specifications and it kind of forms a contract for this. Basically, the signature of web api is that you use and that contract protects the algorithm, because when I go into the algorithm and I’m running these steps, I want to be able to know what label is I need to you know, maybe I’m making some assumptions that It’s a string and I’m operating it on on that accordingly, and that’s really important for me to know – and so I want to talk about how web IDL actually works in practice.

Okay, so you’re a while ejs dev, you got your Viking hat on and you really care about types right, so you’re going to call you’re going to mash in your keyboard and called console count and you’re going to just give it whatever you want. You can give it a symbol right, you can give it an object, seeing it whatever, but the second you do that the web IDL Sheriff is going to stick in it’s going to come in and it’s basically going to be like hold up.

Hold up, hold up. Hold up, you called console dot count and you could give it whatever you want right symbol if you wanted to be so inclined to do so, you give it a number whatever, but I’m going to make sure that you know this contract is obeyed, I’m expecting a Dom string and I’m going to make sure that whatever you give me can pass as a Dom string and if it does that’s cool, we go to the algorithm, continue with a hopefully successful call and and keep going, but just like a sheriff can throw someone in Jail, the web, buddy el sheriff so to speak, can throw a type error, resulting you in with you in code jail, it’s probably the worst place to be right, you’re staring at the terminal or sorry the dev tools, and you got all this red scary text around You don’t know what’s going on, so we want to stay away from that now.

Real sheriffs in the real world know who to arrest who not to arrest stuff like that. That’s that’s really important something part of their job, so they kind of basically have a rule book of things to follow here and just like they’re the real sheriffs of a rule book the web, IDL sheriff has a rule book in the form of the web. Idl standard and it basically defines a lot of the stuff that that it’s supposed to be enforcing, so we saw an example of conversion.

Here’s a snippet from the web IDL standard that basically is responsible for converting a Tekamah script value to what is called a Dom string, something that the web IDL has defined. Basically, the meat of this algorithm is just to kind of delegate to step two and call this two string thing. This is an abstract operation defined in the ACMA script standard, so we’re just kind of passing through right to the ActionScript spec, and we could of course, write to string everywhere we needed to instead of using web IDL but yeah.

This is really nice, because it’s pretty expressive, it tells us tells us how things should work in a really normative clear way, and if your techs are algorithms, when I get to here, I can know that I’m working on a string and that things have been accepted And the sheriff is okay with it. So why are we using this thing called web IDL anyways right? What exactly is it? So it’s it’s just an abstraction of arachno script text, as you saw all step two was we just kind of delegate to the echo script standard? It’s two string thing.

It does a lot of things for us, so it helps us write a lot with just a few words. Potentially, it takes care of a lot of like type conversions. We saw a really simple example of a type conversion, but you can imagine, perhaps potentially a much more complicated one and we would want to repeat all those steps to you know. It’s convert things and then kind of make our assumptions everywhere, where you need it to.

In the spec, so we can use web be able to kind of just abstract that stuff away. It also takes care of things like property initialization for us and other stuff, like that. It also helps us define where our interfaces are exposed in a really expressive way. It like we like we saw, but I think the most important thing about web IDL personally, is that you don’t actually have to use it. It’s as line1 suggests just an abstraction over action scripts over the ACMA script text and that’s really important, because we have some standards that are written without web IDL and that’s totally valid.

It just kind of speaks within the same language of the echo script. A standard space in that uses the same verbage and the same sort of stuff, but web by DL is just a nice way to be succinct and kind of foster interoperability on the platform, so you can always feel free to you know, hopefully that that little foray Into web by DL makes you a little bit more comfortable reading some of the standards that they that they come with in.

So. Finally, I want to talk about how I got involved in this and how and how you can do the same and hopefully motivate you to do the same as well. So who knows this logo? Let’s it raise show of hands right, hey a lot of people cool, so this is the angular logo, this flat designer believe this is new since angular 2 and basically, a couple years ago, I was like yeah, I’m going to start like giving more stuff with web Applications so I better learn a big heavy framework that can bog me down and figure out how to write all this stuff, and so angular 2 at the time was an alpha.

There’s a basically mess right. Things were always moving around and I would always hear people say yeah, you know, angular angular is getting uh, you know a new, router or angular is getting a new object or new this kind of stuff, and it was really easy to track the progress of this. It was happening on github. I knew some of the people working on it, so you could always just kind of dig around. At the same time, I heard another camp of people kind of talking about JavaScript there they were saying you know, hey javascript is getting.

You know async iterators or you know, did you know about custom elements? Can you figure out how to use this, and I was like? Well, that’s interesting, cuz! That’s not really angular specific, so I was really interested in digging around figuring out who’s deciding this stuff because, like like, how does this work? I want kind of wan na be a part of it seems pretty cool we’re evolving the platform.

So eventually it came across this guy’s profile. His name is Dominic Nicola and I just learned recently that he was actually a speaker at the first Cascadia j/s in 2012. It’s true that we both have the same name, that’s pretty cool, and so I reached out to him. I was like hey. I see you, you know you’re working on, you know the what working groups bit standards and all a lot of stuff like that big contributor to the tc39 proposals, and so I had reached out.

I was like hey. What do you do really, and how can I do it? It seems kind of cool. Are you actually paid to work on this stuff? It’s it’s pretty cool, and so he was basically like hey. You know. We both have the same name, we’re both Dom’s right and then working on the platform. So I’ll. Let you in on some secrets and the biggest the biggest piece of advice here, is probably to dig around on some of the what working group standards and actually just take a look at some issues.

There’s a lot of issue labels that the issues are kind of fixed if one of them is good first issue and basically, as the name implies, they are good first issues for people to get involved in and a lot of them are low-hanging fruit or some of Them are editorial in nature that you can just kind of go in and dig around in a web standard and figure out how to work with them. I want to cut away, though, from keynote and probably screw a lot of things that up in the process, but let’s see if I can just show what the what working groups page looks like hey.

Do we have it? Yes, okay. Now, if I can figure out where my mouse is, I would also be cool one. Second, all right cool. So so here’s here’s the what working groups github page, basically just to kind of show you you know it’s all open. It’s all happening right in front of you and it’s a very welcoming area you’re allowed inside. Basically, this is this was basically just a list of all the specifications that we maintains giant list of the HTML standard, the fetch standard and stuff like that, and so we can always just go to the one of these repositories and see what’s inside right.

There must be some sort of source code that the standard is you know existent and that it’s written in and a lot of times. This will take form in a take in the form of a BS file. So bs does not stand for we’re. Actually, very serious people here we’re working on standards right we’re on the platform so bs, since our bike shed and it’s basically this language that we kind of mix in with with HTML and pre process.

Before we build a standard kind of helps us with cross-linking and some other fancy things, it’s pretty easy to get the hang of. We could check out the source they’re, all the standards exist at spec or you know something dot, spec org and basically they look like this they’re, the ones with the green logos that the browser is actually trust, and so we go in yeah. We can check out the standard, all kinds of stuff like that and, more importantly, if you’re looking to get involved, you can go under the issues section here and we have a bunch of different labels that we use.

That’s not where I’d want to go so yeah. If we want to check out these issues, this, for example, this is the fetch standard. Where things like the fetch, your method exist and the request, object and stuff. We could go in and try to find the good first issues. You’re like oh yeah. This is really cool right. I can, I can dig around here and maybe help out on some issues, and so now we’re kind of on to evolving the web platform right.

We’re working with a standards body to help fix some of the problems that they’ve identified and the platform is so. This kind of this kind of goes back to interfacing with the community and the community groups online. So I want to talk a little bit about this when dealing with the what working group there’s a bunch of different ways to communicate with us we’re always on get up. Of course you can.

You know chime in on an issue and be like hey. I really want to work on this. This this looks really cool. I think it’s interesting. We’re always super super happy to provide mentoring, mentorship for people that are looking to get involved, also we’re on the really big bad scary place that is IRC we’re in the free. No under free node on the web working group blog, I’m always logged in a lot of us a lot of the others always logged in so always available to you also help with questions and stuff like that.

There’s a lot of information here that have thrown at you and things like that and at the very end of the presentation, I’ll kind of give you with a well one web page that you can go to kind of get a lot of this stuff from. But I want to talk about why to do this. Anyways right, there’s a lot of cool ways to read it, to learn reasons to learn angular until I react and to work on the web, but I think what’s really cool is, is you know? I know we’re in Seattle and Microsoft land basically, but if you have a problem with some Windows api’s, basically you kind of have to work in Microsoft to get them fixed or changed, or do something like that.

But what the web platform all this stuff is happening. Right in front of your face: it’s all in github, it’s all free to participate, and you know anybody. Anybody can do it and just go on and start working on stuff, and I think that’s really really. Cool web developers are in a really unique position of being able to influence and modify the platform that we all develop on every single day and that’s really exciting.

To me, and one of the reasons that I got involved, so I want to leave you with a repository that I just kind of started the other day. Now is the time to take pictures of the slides if you’re interested in getting involved. There’s a lot of information, there’s a lot more information beyond just what I’ve covered in this talk so check out the Cascadia j/s repository that I maintain on github. It’s just kind of got some getting started information and so the links to other talks that people have done on similar stuff and how to get involved in the web community and modify web standards and stuff like that.

Finally, I want to leave you with some of the things that I’ve worked on to hopefully, hopefully provide some motivation to show that you guys that you all can do the same. Recently. I’ve changed helfet works. The fetch API. I’ve worked on Chrome to basically modify when we said credential when we send credentials when we make a request stuff like that. Basically did the same for for module scripts and took part in some of the standardization work for there.

So that required, of course, talking to a bunch of the browsers and saying hey, you know we’re thinking about making this change. It kind of makes sense. What do you guys think and can I do it? I also standardized and implemented the referrer policy attribute. This is security, even private security privacy attribute and HTML. So I did this on the script Elementary simply so I like resource loading and then security privacy kind of stuff.

I’ve also implemented a bunch of console API eyes, so the console standard I mentioned is a really really good one to start getting involved with. So I encourage you to check it out. It’s what I started with and I also started working on Chrome partially. As a result of that, finally, I’ve been working on something called priority hints, which is just a new resource living API. That kind of lets developers tell the browser what priority they would like to be associated with a request.

It’s a new standard and so we’re digging through that I did the implementation work in Chrome and so we’re just kind of doing some experimentation to see if it’s going to be able to pull its own weight, but other than that. I hope I’ve left you with a good taste in your mouth and when it comes to web standards – and I hope that you all you know, feel motivated to get involved and contribute back to the platform thanks a lot.

That’s it


By Jimmy Dagger

Find out my interests on my awesome blog!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.