 Hi, Mariko. This is my Twitter handle and GitHub and everybody on the internet. I'm from web developer relations at Google. But it's a new job for me. I joined about five months ago. I was a web developer before that. So it's kind of like a new field for me right now. So the events like this are great. Not only I get to meet you all who use the platform, but also I get to meet the team behind the people who is building and a lot of people who work on the Chrome and stuff. So, you know, I go to people and ask like, hi, I'm Mariko. I'm new here. I recently joined. What do you do? And then I get the reply like, I'm on the platform team. And, you know, okay, cool. And then I go to my email and then I get invite like, what platform meeting? Cool. I'm going to go to that platform meeting. And then in that meeting, the conversation goes like this. Like, well, so like X, some framework, use web technology, but not on the platform or like from a platform point of view, blah, blah, blah. And then also there's a whole hashtag, use a platform, which, you know, I'm sure you've seen it. Like, yeah, banners. So platform, platform, platform, platform. So, like, do you know those souvenirs that you get at the tourist destination where it has all the city names and like tote bags and everything? So if I were to design a swag for my five months of experience at the Google, this will be the textile design. So, what platform, right? To me, this keyword is kind of like a sort of like a programming technology that I use. Like, you know, one of those things that I kind of know what it is and like copy and paste it and use it. But as soon as somebody challenges you, like, so explain to me, I don't know, JavaScript promise, I can, I'm going like, I use it, but I can't really explain what it is. But platform, to me, is like that. So I tried to find that example of like me kind of pretending that I know. So this was from March, somebody asked me, like, I don't really understand what the Node.js is and like the relation to V8. So I looked at the diagram and the diagram itself is not important. But then, like, zoom in, I use the web platform, even though I had no idea what the platform was. I just, like, titled it web platform. So it got me thinking, like, I don't really understand what web platform is. And I'm not the kind of person, kind of like a toddler who asks everything and questions everything in the universe. Like, I must know everything. So I got to people, engineers on the team who works on the platform and asks them, like, tell me what exactly is web platform. One thing I got was, like, things you built, like, websites and apps out of language of the web. And I'm like, okay. It's, like, I don't know, building blocks, Lego. I don't know. Another one I got was a set of interoperably implemented technologies available to developers across the web browsers. And I'm like, that's great. I have no idea what you mean. So platform, right? And then I got kind of like, I must understand this and me dive into it. The thing is, in my past life, before becoming a developer even, I worked on the platform. I was in the software platform industry. And I would go into client and tell them about, like, you should join a platform, build a product on a platform. I was on the company that made the video platform. And then I go back to office and talk to engineers and product managers and other stakeholders about, like, what should be in a platform? What kind of API should we expose? And most importantly, how are we going to make money from selling this platform? Because in 2008 and 2009, like, SARS, the software as a service, was, like, one thing, one wave. And then, like, platform as a service was a thing to do. So I know what platform is in software sense. But when I started web development, nobody called me or emailed me saying, like, you should use web platform. Or nobody charged me money to use, to start writing HTML, right? I just started, like, open up the text editor, write a talk, FTP to the server, and then, voila, there was a website. So what is the web platform? Because even I don't even remember who told me or when I was told, but there was this general understanding that web is open. It's the open web platform. So I was, like, okay, that's a key word I can Google. There is a definition on the W3C Wiki, which is the open web platform is the collection of open loyalty-free technologies which enables the web. So let's dive into this sentence and what it means. So first of all, open loyalty-free. Almost everything, anything I feel like that goes into web platform is done and logged and open. And what I really mean is open, that you can find a conversation as far back as 91 logged on the Internet about, like, you know, discussion about what the worldwide web should be. My favorite part of this log is the first email in this log is titled, the test again from Tim Berners-Lee, inventor of the Internet. And then he says, like, test again. Clearly he sent these messages before, because it's a gain. And then, like, if you got this, delete it, sorry. But, like, this is the one that did not get deleted, and now it's logged forever. Well, joking aside, if you go through those threads, there's, like, really interesting history and artifacts of how web was formed. So this thread, I think, is particularly interesting. It's a Mark-on-Jerison who was at the time working on the Mosaic Blizer proposing the image tag. And it goes, like, I'd like to propose a new optional HTML tag, IMG. The required argument is SRC equals URL. And if you read through this thread, there's a conversation about do we even need to embed image in HTML? Should we just have a link to some of the external resources and not even display the image? Can we use other tags that we were considering instead of IMG? And it's, like, a whole bunch of discussion, and it ends with Mark-on-Jerison going, like, yeah, that solution doesn't need to work for us. I don't think that works for us. By the way, we already wrote the code, and we are shipping it. So that's the open part. The discussion is done in open. Nobody is trying to say, like, whoa, my HTML is going to have embeddable image, and I'm going to charge money for it. No, like, the ideas and technologies and how it should be, the API should be, is discussed in open. Another part is that it is a collection of technologies that enables the web. We looked at the image tag example, but it's not only just defining the HTML tags. So what kind of technologies do we have on the web platform? Well, the web is evolving ecosystem. So one example is the pointer event. So we used to browse websites with keyboard and mouse, but then now we browse on those devices, and we use our fingers and two fingers, so we needed a way to address those interactions in the web, and we added pointer events. Another one, the web used to be just a document that we shared across the internet, but now we make applications, and which internet application needs to get access to local file system, maybe, so that you can upload image and make something like Instagram. So file leader API was added. This is the API that is near and dear to my heart. This is the API I used for the first application I wrote on my job, like, not the side as a hobby, but, like, the first application I wrote on the job, I used this file leader API because I had two weeks of off-time. I wasn't a web developer yet, but I was on the business side, and I had, like, a week, two weeks of off-time that client wasn't sending me assets. I was like, well, I learned JavaScript recently, and I know how to console log, and I know how to, like, HTML. I'm going to, like, try to make this, like, a little tool that's going to help me do this analytics thing, and what I used was file leader to load all of the data, the attributes that I needed to automate my job. So when I did this, my company did not buy me license. I did not ask for money to start making the thing. I just opened up my text editor and did it, and that's great. So collection of technologies which enables the web. And this definition is a lot close to the description of the platform I got from the engineer, a set of technologies for the web. But that's only half of what he described as the web platform. There's a whole other set here which is interoperably implemented across web browsers. So I went back to the same engineer who said this and asked them, like, so how does browser interoperably implement things? And his answer was, like, well, we used to just copy each other's bugs, but now we write spec for standards. And that's the way we make platform. And Alex, the speaker before this, kind of talked about how that came about. So you got that thing. But every web API and the platform features that we use, that as a web developer, we might encounter on MDN or any tutorials that we publish, behind that is thing called specification documents. And it looks like this. And if you go in, here's the custom elements section where it defines the element. It goes in detail what to look for, when to look for, what to check for error, and what kind of error to throw error when. It goes in step-by-step detail also how this API and how this feature should work. And you might have ended up this in page when you were trying to search for some tutorials and then you might look it away. Because I did. I certainly remember this, like, a design of a blue bar, sidebar thing. But, like, I don't ever remember just, like, getting any information that I can use on a web development job to finish this PR from this document. I was just, like, ah, that's not for me. I'm just going to look away. While I was just having this conversation, another colleague of mine kind of asked me interesting questions. So he walks on standards I thought at Google. And he asked me, like, so I have a question. Why don't you just contribute to standards? And my answer was, like, that's an interesting question. I have never thought that's possible. Because, like, somehow I think the standards are, like, a mystical creature called W3C and ECMA standard gives me this, like, golden document that we can use. And I've never thought that there was somebody or some human close to me writing these things. So I told him that, like, I just never considered as things that I can do. And he was, like, oh, that's interesting feedback. Glad to know. Because we never thought that was, like, you thought that way. And he told me, by the way, here's the way to contribute to the spec. And it turns out it's a lot closer to how we make web application and how we do software development. So let's look at how we work on spec. So let's say, for example, if you want to edit or add something to the existing spec, what does it take? Here's a HTML spec that is defined by what WG. And, you know, here's a link to the document that is kind of, like, I felt like that's not for me. But all of those are hosted on GitHub. And there's an issue tracker that has all of the thing that needs to get updated. It even has a label for good first bug. And it's interesting that the spec is an English text. When they say mean bug, it means fix this English text. So if you look at the PR that is made against this HTML repo, you find things like this. Like, explicitly mention possible values for image smoothing quality. So this was from one of the good first bugs. It just means that somebody noticed that in the spec text is a little ambiguous when they say values image quality, it didn't say what kind of quality is possible. So this edit just adds three more words to what kind of image quality needs to be added. And now, the person who made this PR is a contributor to the HTML. Much like we write tests for software, web platform and spec has a test called a web platform test. And if you dig into this repo, you can find how each of the web platform features should behave. And you can read through what each of them should do. And I'm kind of the person who sometimes when you don't really understand bug, you read the test and then see, like, okay, this is what it's supposed to do. And here's what I need to fix. I really enjoy looking at web platform tests and knowing how things should work. But what if you have a new idea? What if you're working for a company or working on a project that is completely out of what we consider as a web right now and you need something standardized? How do we go about that? I'm going to show the example of how to do it on W3C. But many of the standards follow the same steps. So there's a thing called web platform incubator community group, YCZ at W3C. And if you need the announcement, which happened, it's a little recent thing, like an announcement from 2015, it specifically says we will develop spec use cases document like we develop any open source software. So how do we do that? YCZ have discussed. And then there's a value of things and features and discussions are happening there. So let's say you have idea, new API that you want to bring. You create a new thread. Here's one from Sarma, who is speaking later today. And make a proposal. Usually those thread comes with a little bit of explainer. So in the GitHub, there's explainer like one markdown file says like, here's the problem we have. And here's a potential solution that we want to solve with this new API. If you lead these threads, the threads go into people asking like, well, what do you mean by that? Can you clarify your question? Is it really valid problem? Or any other things like, can't you just solve this with this other thing that already exists in the web platform? And those discussion happens. Once the virtual discussion happens and community agrees that this is actually a problem that we need to solve. And this cannot be solved by existing technology. We should make a new thing. Then it moves on to the next step. So if you are curious about those specs and explainer docs, YCZ WebIncurator community group has a GitHub org. And you can browse through all of the LEPOS with all of the explaining things. And it's kind of a good place to know what kind of new things like that are going to work. And it's going to be a good place to be. And you can also do a lot of things like using the web USB or considered for web platform. Once that discussion is mature, they do a thing called intent to migrate. And which means that we identify the problem, community agrees that we should work on it, and we want to formalize the process. And it moves on to what is called walking group. Walking group is kind of like a subset in the W3C that works in the W3C. And you can discuss how can we actually make interoperable technology. So CSS has walking group, service worker have walking group, and walking group usually have GitHub. And you might think, we already have the GitHub. What's the difference? Well, you know, there is the LEPO is now under W3C. And there is a whole bunch of process to move the spec in order to be official spec or recommended spec. So there is a document that feels like a gazillion pages of the process. If you're interested, you can scroll through and you can find things like, okay, if you have a spec, it goes from walking draft, WD, to CR, to PR, to recommendations, and you know, you can lead a whole through that. But once you identify the problem, then identify, we'll agree that we should actually work on it. Then there's a whole other set of process to bring more stakeholders together and make sure that the specs are done. So if you're curious, if you're browsing MDN, you can see what kind of specification this platform feature belongs to and what steps in those steps. So that's the spec process that is in. And it's in the table for MDN. And it's kind of fun to look at. So, as some writes, I talked about W3C case, but generally, other stunders bodies follow the same thing. Somebody has an idea. And somebody starts the conversation about, hey, I have this problem. I want to solve this. What do you think? And so I think that's a problem. And if somebody, that conversation happens one and two and many cycles, and then if they agree that, yeah, we should actually invest the time and bring the stakeholders together, it moves to a little more organized steps. And then they do another more set of discussion around it. And then once that's done, then it's qualified, and now everybody's happy and go party. So I asked the same engineer who told me about the web platform, like, how many web platform stunders, or like, how many stunders goes into making a web browser? And his answer was all of them. There is a lot of stunders bodies specifies many bits of parts of the platform. So W3C has CSS, a lot of web API, what WG defines DOM and HTML, ECMA is specifically ECMA technical . It defines the JavaScript. Unicode, most importantly to me, defines emojis. And you can propose new emojis to Unicode, there's a process for that. And IETF has things like HTTP. So I, before going into this, I felt like this, you know, person to person, somebody who is definitely not me working on spec was a process for spec writing. But after this, I came out that, well, it actually many parts of standardizing a web platform and defining what platforms should do, it's something that I, it looks like something that I do day to day. It looks a lot like software development. But I warn you, it takes time. And sometimes it's a little frustrating. I'm sure we were at a Polymer summit, we get frustrated, oh, is the spec ready? Is it already recommended? Why is it moving so slow? And there's a reason for that. Web platform is built on many different environments. Since joining Google, I got opportunity to attend one of those standard meetings. And I witnessed interesting conversations. So there was a conversation about internationalization API. And one browser was saying that, well, our browser is built on top of specific architecture, specific OS that does not use this internationalization library, which other browser uses, two other browsers share the same library. So their point was that, well, you too might think this is easy to implement because it's in your library, but it doesn't work for architecture, it doesn't work for OS, and it's really hard for us to implement. And those discussions, making sure that it is interoperable, takes time. Another one is that web is really unique ecosystem. You have to support HTML from 20 years ago, and you have to think about supporting HTML from 100 years from now. We can't just say, oh, excuse me, sorry, in order to use Polymer 3, you need to install web 2017. That's not how it works. It has to work backwards compatibility, and it also has to work in future. So a little story time, when they're considering those backwards compatible and future proofing, what kind of conversation happens at the standards? So 2014, one of the engineer who was sitting next to me, I think saw Rob's talk from a Google I.O., and he was really excited and told me that you need to write this thing called Polymer and use web component. This is the new and shiny thing, you should do it. And I was like, okay, great, I can write my own HTML tag. I want my HTML to look like this. I was in business, so I was thinking about data dashboard, and this looks pretty. I can define my elements and make my thing. Well, my first prototype didn't work because I didn't hyphenate the tag's name, and that's one of the spec. So Polymer doesn't work that way. I have to make it my dashboard and bar chart and hyphenate the name. And I was like, oh, why? I had this specific markup in mind that I want to write. I was kind of frustrated that Polymer didn't let me do it, and at the time, I was like, Polymer didn't let me do it. I didn't know anything about web platform. So that was my frustration. Two weeks ago, I was in the conversation with the engineer who was in the meeting when they decided that the custom elements should be hyphenated. It was an enlightening experience to me. So when they were discussing, okay, let's have this thing called custom elements. And developers defined their own tag, basically. How should the syntax be? And this engineer who was at the meeting told me that they were like, okay, we need to define the way that doesn't conflict with existing HTML and the HTML tag that might come in future. So we need to namespace it. Well, what about namespacing it with colon? Turns out XML used this syntax and SVG used XML syntax. So let's no go because it conflicts with what SVG. So colon, no. Another one was like, what if we just, like, prefix it everything? So, like, x-custom element or something. But, like, marking up these kind of, like, looks like a ridiculous. So, like, they were like, oh, we really don't want to do that. So, at the end, they ended with just simply hyphenating the word custom element. And everybody's happy, and that's how we code now. But this is so much more than just having a neat-looking markup. When the specifications decided that this is going to be, a custom element is going to be hyphenated, that means that they decided, in future, when they were to be considered new HTML native element, then they will not use a hyphenated name. It will always be known hyphenated name because the future HTML element, if they have a hyphen, then it conflicts with custom element. So that is kind of scary things to discuss. And, like, you know, you have to be careful about it because HTML, I think, will way over live my life, and you have to take care of what would happen in the future. So, it takes time. So, hopefully, you kind of got the idea of what the platform is and what kind of discussion that goes into. And I admit, as a web developer, myself, sometimes it's frustrating. I'm like, why is this doesn't work this way? And I go into Twitter and just like, I hate this thing. But I hope you got the idea that where you should go, if you have those frustration, there is a community discussion forum that you can send to many of the engineers who are at this, engineers and people who works on the stunders at this conference are more than happy to talk about why certain things that you're unhappy about happen that way. And I specifically want to thank the people who answered to my most London and Endress question about, like, I don't understand the platform, I don't understand what the web platform is. So, thank you very much. And thank you very much for Polymer team for letting me share what I discovered. And thank you very much for listening to me.