(upbeat music) - So that talk was amazing, and it's a really nice follow-up to one I'm gonna talk about, particularly what you were saying at the end there about how we actually, we know all this stuff and we see all this stuff, how do we actually then implement this stuff? So, a little bit about me and about this talk, and a little bit hopefully about you, can I get a sense of developers? So majority.
Do we have any managers? So it's a good balance of managers as well, so as John said I'm a staff engineer, it's a fancy title for senior developer or senior engineer, but I also work with a lot of junior developers, and I also work on a lot of open source projects, and I do a lot of mentoring, and in my own work, trying to find ways of integrating, the stuff that Sara was just showing us, amazing, how do I actually do that in my project, so that's been a real struggle for me.
So as John mentioned, I've been working for Mozilla for the last five years, before that I was an independent consultant, so I did standards as well, and even before that I worked for Opera software where I worked in even more standards.
So some of the things I've worked on more recently is for instance Web Manifest, the picture element which some of you may have used, I did a bunch of work on orientation device APIs, and over the last year-and-a-half two years I've been doing a lot of web payments, so if you were here last year I did a talk about web payments, and I'm still working on that, so the real struggle for me, as somebody who does standards and also somebody who does web development, so a lot of the specs that you see WC3 specs, that little thing at the top right hand corner you'll run into, it says Respec, I write that little thing, that little bit of software that puts specs together, so there's two of them, one of them is created by Ted Atkins, Sarah also mentioned the person that does all the CSS specs, I do the other specs, so anyway as part of that I'm always trying to keep up with CSS Grid and so on, but it's a real struggle.
And I imagine you will go through the same pain, both as managers and developers, like what technology do we actually apply to things. So standards, keeping up with standards, so let me just give you a little idea of the struggle there. So the web according to browser engineers like myself, it's really just a collection of standards bodies. So you may have heard of KHRONOS, Web GL, the W3C, service workers, they used to do HTML, now they do things that Web IDL, all the CSS stuff comes out of WC3, IETF is for protocols, so the HTTP protocol, HTTP2, TLS, then we have the WHATWG who is the standards body that basically shepherds now HTML and all the lower level stuff like URLs, streams, storage, and other good things which I can't remember right now. And then we have web innovation community group which is one that I chair, which is where new standards, so any new innovative thing, not all of them, but the majority of new things that are coming to the web go through the web information community group, it's a group we created to basically funnel our new funky ideas, from browser developers, from just normal web developers, from anybody in the community who is interested, we send them through that process, and hopefully eventually whatever comes out of there, will go into WHATWG, the W3C potentially, into the ITF and so on.
And then there's ecma which does JavaScript. So all of these are either markup, or they do APIs and so on, that's a lot right, that's a lot of standards bodies.
So let's just go through the WC3 standards. They're still going right, I got tired of scrolling, I had to stop for a bit.
So it's too much right, nobody could possibly keep up with that many specs, it's like I could spend my whole life just reading that, HTML alone, it's nearly a thousand pages, and the amount of detail that spec has, and you need to understand all of it to really understand how HTML works, it's just insane, and then there's JavaScript itself, so I've actually written a JavaScript implementation in JavaScript, so I know how much pain it is.
That's because I wanted to learn it.
Anyway it's a struggle, and that's something that I am deeply embedded in this community, and I write standards, I can't keep up with this stuff So it's fine if you can't, there's critical things that we learn about and we come to these conferences and we pick up these amazing things, like what's new in CSS and so on.
So we basically just end up with so many questions, and like I said, I work on real web stuff, I work on standards, I maintain open source projects, and I have questions.
So for instance is HTML done? That's a good question right.
What's up with Web Components, I've played around a little bit with Web Components, but I'd love to use them, can I use them yet? Maybe, anyone using Web Components? So that's one person, amazing.
So we've been here how many years, like seven or eight years, actually when I first started in standards we have something called XPL2, which was the precursor to Web Components, so it's been going on since 2006, 2007, so what's going on with SPG, so Sam already mentioned a whole bunch of interesting stuff, CSS Grid is amazing, people are using CSS Grid? A couple of people, it's really amazing, it's mindblowingly amazing, but what's next? I'm sure you've all heard of Web Assembly, if you haven't we're gonna talk about it a lot, there's this myth about do I need to learn Web Assembly, what does it do and will it kill JavaScript. Maybe I don't know.
What's going on with accessibility nowadays, particularly in relation to Web Components? We had some pretty serious security, threats happen just generally in computing this year, and they had a huge impact on the web, so what were those impacts and what does that mean for the web and for web browsers? - And then there's things like AMP, have people heard about AMP, the accelerated mobile pages? So I'm gonna talk a little bit about that, because there's a new standard being developed by Google called Web Packaging, and that has implications as well.
Like I said I work on payments, talk quickly about what's coming out with payments next, and something that's been really bugging me, it's been been bugging me for a couple of years, it's like why does Chrome seem to ship so many APIs, as somebody who works on Firefox, why do they ship so many APIs and we don't seem to ship at Mozilla and at Safari and also at Edge, why don't other browsers ship so many APIs, so we'll discuss that.
So in order to understand these questions, as John said I took a little trip, six weeks to go and find out what the hell is going on, and of course I went to Tech Mecca, San Francisco, so I went to silicon valley, coincidentally there was the Mozilla all hands which is an event where all Mozillians, so that's the thousand of us get together, and we basically plan out the next six months for what we're gonna do in Firefox, and also as Mozilla as an organisation.
And while there I got to catch up with a whole bunch of amazing people, so like I said I don't know these things, I know some of them, I know payments really well, but I don't know things that these amazing people know, so for instance I got to catch up with Jen Simmons, who is like, she does all this amazing CSS stuff, so if you've learned CSS at some point in your career, you've probably looked at an article from Jen Simmons, Luke Wagner who is one of the lead people in Web Assembly, so he's worked on the standard, shepherded the community group and now the working group, I caught up with Alice Boxall, who is actually Australian, she's from Sydney but happened to be in San Francisco, given that it's San Francisco of course you're gonna run into more tech people, she's actually at Google, and she's working on some amazing technology called AOM which I'll get into, which is basically enable a whole bunch of interesting stuff, inaccessibility and Web Components.
And caught up with Andrew Overholt who is director of engineering, so he happens to be my manager, so I had to put him in, I don't want to get fired, and I want to get a raise too. But he's the person that basically manages Dom, the Dom object model and the JavaScript engine. Initially I met a person called Ashley Williams who is on the Rust core team, so Rust is a programming language for people who don't know that Mozilla has been developing, a new programming language, which coincidentally you can use on the web, so it was really great to talk to Ashley, because we talked about okay, we have Web Assembly and we have this thing called Rust, how do we use them together? And I also caught up with Anne van Kesteron, who is a person very involved in standards, so he's editor of HTML, maintainer of HTML at the moment, the Fetch standards if you've used Fetch, this is Anne, XHR even, it's Anne van Kesteron again, URLs, encoding, storage, he does a lot of stuff, so he's a great person to talk to about, like Anne, where's the web going? And I talked to many, many more people.
So from there I headed out to Boston, to standards Mecca, so I went to the W3C head office and I spent a couple of weeks there, so there I had the opportunity also to hang out with Wendy Seltzer, who is the strategy lead at the W3C, and also Philippe Le Hegaret, we all have trouble pronouncing his name so we just call him LH, he's project lead at W3C and he is the person really involved with trying to make the web as interoperable as possible.
I was also fortunate enough to catch up with Ethan Marcotte, so as part of the WICG effort I asked Ethan to chair the container queries work, which was the elements query, also called the elements query which is certainly what Sarah showed, where you have an SVG and you can set the media queries inside an SVG, and it lets you stretch that SVG, it basically adapts, we want to bring that to any element, so we can trying to do that together with Ethan, and Ethan's been leading that part of the community. So it was great to sit down with him, and also Jeremy Keith happened to be there at the same time, so I got to have dinner with Jeremy Keith, it was really cool.
So a little W3C trivia, it's in this awesome building which is called the Stata Centre, it's a building built by Frank Gehry, when you get there you get a mug but you have to give it back at the end.
Above the directors desk they have this emergency shut off switch for the web, so if things get really bad, they just pull that switch, I was very tempted to.
And then every Friday, they have this little dog, his name is Kanye, it's a terrible name for a dog, they get Kanye, Kanye comes in and you can take him round to meetings and he just hangs out with you, supercool.
So lastly on my little adventure, after three weeks at MIT I went off to Toronto, it was intern season, and we got our interns to make Firefox logos for us, so when you instal Firefox that's where they come from. And while I was there I caught up with this person called Rick Byers whose the staff engineer over at Google, sorry actually senior staff, and what Rick's role is, Rick's a really amazing person, because his role is basically the person that goes around and talked to other browser vendors on behalf of Google on various things, he's a real advocate for the web, so any time there's a thing like YouTube doesn't work in, actually more real example like Meet, Google's Meet didn't work in Firefox, can you imagine? We have a commercial corporate account with Google and our own browser didn't work in the product that we're paying them to use, this is insane right? We hit this all the time, that's a person that we go and cry to, like Rick, go and yell at people at Google, make this work in other browsers, and Rick, like I said, he's a true champion of the web, and he deeply cares about making sure that all browsers succeed.
So I spent quite a few hours with Rick just talking about the future of the web, and about things I already mentioned, so let's get on with it, so unless otherwise stated these are my opinions on things that I gathered as I went on with my adventures. So I'm gonna run through this, because Sarah fortunately covered some of this already, so as I said HTML, by talking to for instance Anne van Kesteron and other people, HTML is basically a mains mode, which is great, so that we know new tags, it's all Web Components focused now, so as you might have seen in the news yesterday or not, Google has had an old implementation of Web Components, they're ripping that out of Chrome, and the reason they have this old implementation, it because YouTube really depended on it, but the rest of the browsers are now implementing, we're all planning to ship Web Components.
So it's really a good time to start looking at Web Components.
So to learn more a little bit about CSS, we're gonna get a different take on CSS, so as I said CSS Grid, if you haven't tried it, as you saw if you don't need to cater for IE11, or even if you do there's still an option there, but go and try it out, so I caught up with Jen Simmons as I said, and I'd like to give her an opportunity by the magic of video. - So my name is Jen Simmons
and I'm a designer and developer Advocate at Mozilla, where I have a chance to help create new dev tools for CSS and designers, where I help us make sure we're implementing the best CSS that needs to get implemented next, and help create new specs, and where I get the chance to speak at conferences and make videos and write blog posts and articles and books to explain to everybody what's going on.
Are we done with CSS? No we're not done with CSS, I mean CSS will continue to revolve across our entire lifetimes, I hear people complain that it goes too slowly, but actually it will evolve over our entire lives, so anything that changes in CSS needs to change very carefully.
And no we're not done, so CSS Grid means that now with Grid, Flexbox, multicolumn, flow, tables if you want, we have a layout system, a system for the first time on the web, we needed a name for it, so I coined the term intrinsic web design to say hey, it's not just Grid but it's Grid plus, it's Grid plus Flexbox plus flow, floats, we're gonna use all of those tools all at the same time, so will we keep getting more tools into that world of true layout using CSS only, yes we are, Grid level one gives us the grid that we have today, but we need to add sub Grid which is Grid level two. And there's all sorts of ideas about other things we could add to Grid to give us the ability to put borders and boxes and backgrounds on empty cells and in space, and there's all sorts of ideas that graphic designers need, so no we're not done, but also a lot of those things will take years to come out, CSS Grid level three, when will it ship, probably 2022 somewhere, and I think that's okay, because there is so much new juicy stuff right now, that it will take years for developers and designers especially, and for folks who make the decision about what goes onto a website, there's a lot to learn and absorb, and there are new ideas that we haven't even allowed ourselves to think about. There's sort of two questions you ask there and I want to answer both, one is if it's something new, and it's not in a hundred percent of the browsers that people are using, can you use it yet? You can, you don't have to wait until 100% of people have it, in fact there are very few, there's a lot of things that have been added to CSS in the last 10 years that are still only at 95% or 98%, if you understand how to read CSS properly, you get your developers to write it properly using Progressive enhancement techniques or what also being called resilient design, you can ship code today even if 70% of your users have Grid, because CSS is a declarative language, other kinds of programming languages are functional, where if there is one mistake, one typo, one piece of code that the browser doesn't understand then the whole programme fails, CSS is declarative, where if there's one little thing that a browser doesn't understand it goes I don't know what that is, or if you misspelt a word, it's like I don't know what that is, and the rest of the programme runs, it's very different, and it makes CSS very very robust, and that means that we can't architect our code so that you can create an experience, it's not gonna be identical, it's super important for people especially designers or stakeholders, clients people who are making the final decision to understand that the websites gonna look a little bit different on one phone to another phone or from one desktop to another desktop, or especially from a phone to a desktop, and we are starting to get the hang of it, it doesn't always look identical, but it's a good experience, it can basis the brand, the content gets across, people can do the function of the app, that's what's important, and CSS can do that, so yes please do go ahead and use the new things today, you of course need to evaluate little piece by little piece whether or not that's the appropriate piece, but it makes me sad when they think that they can't use it at all until it's been out for five years, because that's just not true.
- Cool, so container queries now, so I explained a little bit earlier what they were, so essentially as Sarah showed, having an image that can adapt as you stretch it or to fit a particular layout, we can't do that today with normal elements, so unfortunately we haven't made much progress, so we managed to articulate the problem really well, we understand the problem really well, but we haven't made great progress yet, so we've been at this now for six years, it's on the roadmap, it's coming in the future but we're not there yet, so that's the sad news.
SVG as I also mentioned, there was almost momentum, so I talked to for instance Chris Lilley at the W3C as well as other people at Mozilla, and there was a whole bunch of momentum recently, of like, yeah let's fix SVG, because it's not really a problem with SVG, but if you try to code SVG like JavaScript, the APIs are really clunky, so it's really good as a declarative language, so it's very flexible unless you do a whole bunch of interesting stuff, but when you actually try to manipulate it with JavaScript, it's really hard.
And we were hoping to fix that as a community, and we were like, we've got better things to do. So a lot of problems a lot of problems.
It may still happen so Google is very interested in restarting this work, but at this point it's like maybe next year we don't know.
So Web Assembly, Web Assembly is one of these big-ticket items, I personally feel that this is one of the things that's gonna really impact, potentially impact our workflow and how we think about applications and so on, so for those people who don't know, Web Assembly is essentially an assembly language for the Web, so it's basically a compiled target, so you can basically target any statically typed language that you would normally compile, let's say C++, C, as I mentioned Rust, so a whole bunch of these family languages that you can compile them to Web Assembly, and then Web Assembly will just run them.
So to give us a better idea of how Web Assembly came about, I'm gonna let Luke Wagner give us a little intro and answer some of the questions. - Well I mean I work on the Web Assembly in the community group building the Web Assembly standard, I work also on Firefox on the Web Assembly implementation, with optimising it and prototyping new features and talking to users and figuring out what they need, and trying to incorporate that in how we build the standard.
Well the first use cases that we started looking at were video games, and what was surprising is people were compiling C++ to JavaScript and it was running okay and it kept getting faster, and so it raised the question of how far can we push it, what's the limit that we can take JavaScript if we just cut all corners and just take every shortcut and that was Adam Jess which was pure JavaScript but it was optimised to the limit, and then we found that limit and found it worked, and people started using it which was exciting, which motivated us to go further, and then we had all these problems with the things JavaScript couldn't do, so based on all that we were like we need a binary format it has to be really fast to the code, it needs things like N64, it needs to be able to support dynamic linking, separate compilation, caching, people being able to share code between threads and all that type of stuff.
And so that motivated Web Assembly, and by then all these other web browsers were paying attention, because they had to run the ASV code anyway, so they are starting to care, and so they are all quite willing to collaborate on making a new cross browser standard, so we were able to have an enormous amount of interest in collaboration right from the beginning. There's a lot of things that I guess would have been completely surprising five years ago, like people compiling full game engines, full multimedia applications, auto cad, 30 year old things, so that's cool but I guess after a while we weren't too surprised because we help build all the tools that you are using, so surprising is kind of, I'm trying to think of something that came out of left field, it was surprising to find out that Wikipedia had made a poly fill for .ogg using M script, and if you visited Wikipedia on a site that didn't support this free format, then they ran the JavaScript poly fill, which I thought was delightful, since it's kind of a way to support open and uncovered formats.
I think there's a few different cases, and the most exciting widespread case would be, you use a web framework and that web framework has some big algorithms that are usually doing something computational on virtual dom trying to minimise the changes to the physical dom and those are opportunities to use Web Assembly, because you have data structures and computation, so several web frameworks are experimenting with this, none of them are totally in production, but I think within the next year it seems quite likely, somebody's gonna come out with something, that's gonna be there big claim to fame, is we get super high performance because we moved the dipping algorithm to Web Assembly, so in that case that comes out people just use that framework, just write in JavaScript like normal but they're just getting this optimised rendering to the Dom, so that one way, another thing we've seen with people is that you just have a hotspot that you profile, at all times in this algorithm, maybe your processing streams, or processing something, or generating some format, and then the best way there I think right now is if you're willing to learn Rust, there's a really smooth workflow for writing basically an ES module, what feels like an ES module in Rust, it has imports and exports, and has a whole tool chain to build an actual ES module that you can just use in your web bundler, and check into NPM, and whole tools that automate that whole process, so it really feels like you're writing modules just in a different language than JavaScript. The next thing is a shared memory with threads, so the ability to share web memory objects between workers, which lets you build up a P threads application, and that that kind of held up by general Spectre timing attack stuff, but I think were working through those issues so that will be able to ship that, and that helps really high performance game engines, but the thing I think that's really gonna impact the web more deeply is I think adding the GC integration to Web Assembly, so this is the ability for Web Assembly to directly manipulate JavaScript objects, Dom objects and pass them around without having to copy anything, and this will allow people to compile from languages that are low level like C++ and Rust, but high level like we're talking to Reason and I think there is possibility to extend typescript with gradual hyping that will allow them to use it, one of these or multiple of them will just allow people to write in languages they might have wanted to write in anyway just to get the type checking, and then as an additional bonus get a speed boost, so I think that's the real exciting future where everyone's writing Web Assembly without having to do low level programme.
- So as you heard that's really cool, because particularly the next version of Web Assembly, 'Cause basically will be able to just manipulate Dom objects as we do today in JavaScript, but within other programming environments, which is just mind blowing to me.
I'm super excited about that.
And if you're already using typescript for instance, just as a normal compile target for a Web Assembly. Again that sounds great it's very futuristic, how do we delve a little deeper and actually start finding little places where we can use this stuff, because we're not all of us suddenly gonna like, let's rewrite all the things, I know that's very tempting, I've done it before, but generally we should have some self constraint, and like okay let's build on what we already have. So Ashley Williams, I spoke to Ashley Williams who is working on this particular problem, so I'll let her in her words say something about that. - Web Assembly is absolutely not a replacement for JavaScript, despite the fact that there's a lot of sentiment out there that Web Assembly will kill JavaScript and will never have to write JavaScript again, the real vision of the folks that are actually working on Web Assembly, the spec and the tooling, is that Web Assembly is a partner with JavaScript, it's meant to be able to supercharge your JavaScript and work seamlessly alongside of it. If you have a JavaScript application there is usually spots that are extremely heavy computation wise, they often can become hotspots for your application, and so when you find those, what we are hoping is that you can surgically replace those kinds of spots with Web Assembly to be able to make those processing heavy portions of your application run significantly faster with a much smaller memory footprint.
A lot of the examples that were currently seeing have a lot to do with parsing, which I think is really interesting, there's a really amazing project by Nick Fitzgerald, about rewriting the source map implementation in Rust that's compiled to Web Assembly.
And there's a couple of other very large organisations on the web that I will not name that are looking at passing config files using Web Assembly. So Web Assembly as a target, and because it's a spec and it's quite a small spec, you can compile any language to Web Assembly, but just because you can doesn't always mean that you should, so Rust is an extremely good candidate for targeting Web Assembly, because it doesn't have any runtime and it doesn't have a garbage collector, for languages that have runtime and garbage collectors, if you were to compile them to Web Assembly you would have to include then in the Web Assembly, which starts getting rid of those awesome benefits of it being small and it being fast, because it will be time boxed by those things. Yes there is a tool, so as I stated before, our goal with Web Assembly, particularly in Rust and Web Assembly, is that as a JavaScript developer, you should be able to go into your app and be able to surgically replace just the small hot path, now part of the requirements of being able to do that, is however you're writing this Rust that maybe generates the Web Assembly and then how you use that Web Assembly, needs to work with all the JavaScript workflows that you already have, so we've been working on a tool called wasm unpack, and what wasm unpack is able to do is first it's an integrated developer workflow, which I know that JavaScript developers really love, which means that it can run all these amazing developer tools that we've already written for Web Assembly like profilers and sniffing and a bunch of other really awesome optimizations, but it will also compile wasm for you, but the biggest thing it does is it's going to wrap everything up for you in an NPM package that you can either use locally or published to the NPM registry, such that anybody who wants to can then just pull that package down and use it as if there was JavaScript inside of it, there's wasm in there, but our goal is that you shouldn't have to even worry that it's there, it should work exactly like JavaScript.
And one of the amazing things about that, is that it will also integrate into things like, bundlers such as Webpack, Webpack currently works, Rollup and Parcel we're currently but you can also use stuff like Greenkeeper by keeping up-to-date.
- Very cool, so I'm personally very excited about that.
I Wanna quickly talk about web packaging, as I mentioned there's been a lot of controversy around AMP, so for those that don't know, I'll summarise the controversy very quickly, so AMP is essentially HTML tags that, or Web Components really that Google defined, that if you put into your pages are basically opting into, Google basically taking over the experience of your page so that when people search for your site, or for instance a news article, it appears on the Google front page with a little lightning icon which is the one at the top there, and what it provides for users is a really fast experience, because everything is coming out of the Google cache. So this deeply concerned a lot of people, because although it provides an amazing experience for users, basically what it's doing it centralising everything in the Google cache, so it's the same as, the Facebook equivalent, I've forgotten the name of, anybody remember what the Facebook ones were called? (man mumbles) - Sorry? (man mumbles) I can't hear it but you heard it there, anyway there's alternatives, Apple News does the same thing, these are not great because they basically break the web, the other thing that is really bad, is that instead of being your own origin, it's gonna be google.com/your.com/article, so we didn't like this as a community and also as Mozilla, So Google heard these complaints, and they're like, okay we understand what the problem is, let's try to solve this problem, so what they come up with is essentially this thing called sign exchanges and web packaging, so sign exchanges are essentially like okay when you send the HTTP request over TLS or secure connection, you essentially get back a response, and somehow that response is encrypted, so using the TLS certificate, so if we take that as a unit, we can basically take this is a signed exchange, and we can make multiple requests, so one after the other, and basically we can get a sequence of them, take them together and put them into something like a zip package, which is really cool.
So here we have a set of data that is cryptographically assured to have come from some origin, and what we can do then as I said we can put it into a little package like a zip file and then we can pass it around, so you can cash it, and you can do really cool things, for instance instead of being on the web at all I can send it to you over Bluetooth, I can save it to my hard drive, and I know because it's cryptographically assured that it hasn't changed, because I can verify the signature, I know this came from food.com, so that's amazing.
What if we had this format, and we get stuck it again in the Google cache, but this time because you don't know even that it's cryptographically assured, that it came from example.com or my site.com, there's no way of distinguishing that this thing is not coming from some particular server, it's just again all coming from Google, so again we are scared that with this technology Google again is gonna centralise the web, but this time we won't even know, so it's an interesting one to track, I wanted to mention it, because it's very hotly debated now in the standards community.
So I want to give Alice a chance to describe this technology that she's working on, which again is really amazing.
- [Alice] Hi I'm Alice Boxall, I'm a software engineer on Google Chrome, working on big Chrome and Chrome OS accessibility. So a few years ago some colleagues of mine at Google were talking to our counterparts at Apple and at Microsoft and at Mozilla, and we realised that we'd all come up against the same idea of wanting to create something which was like the dom but for the accessibility tree. Primarily two things come to mind, so one is custom elements in shadow Dom, there are a few problems around that, so shadow Dom in particular makes relationships difficult, so when you're talking about accessibility trees, often times you need to express a relationship, so this describes that or this labels that, or disowns that, and then when you're going across a shadow boundary, you actually cannot express that relationship because it's all done in terms of ID racks, so that was one problem that we came up against that was problematic, another one is that just in general, using attributes for ARIA was quite painful, again when you're creating a web component, the semantics should just be bundled in as part of the component, as part of the implementation details of the component, if you're using ARIA attributes you have no choice but to leak those semantics out into the white dom.
Purely developers who are writing component libraries in frameworks, or doing very complex pages, so particularly for Web Components are a very key space for us, so this idea of wanting to be able to express the semantics of a web component that can then be included in a webpage, without the person including it really needing to know very much about the implementation details of the semantics, they may need to override it, obviously using a native element, you'll still need to set things like labels as they make sense, but the implementation details can be completely abstracted away.
So by taking another look at use cases, we realise that we can actually get a long way with ARIA if we make ARIA a programmatic interface as well as an attribute-based interface, so it'll use the existing ARIA spec, so whatever is the latest ARIA spec right now, it's 1.1, will list the attributes and roles that you can use with that spec, but make them available as properties on every element and every shadow root as well, so setting it on the shadow root will allow you to express those default semantics, and you can actually, we're actually planning to spec it so you can pass it as part of the custom element registration as well, so for static things like roll, and a few other things you can actually say this is just a part of this element, every single instance of this element created gets these defaults.
- So I unfortunately don't have time to do all these, so I'm just gonna run through them very quickly. So security wise, there was a big attack earlier in the year, called Spectre and Meltdown, and effectively these were attacks on CPUs, so a security researcher or a couple of security researchers worked out that you could basically look ahead and read memory from other processes, and although this doesn't affect everyday companies directly, browsers are a big target for this attack, so essentially Mozilla and other companies had to get together and work out a solution, so at the end of the day what we did is we're gonna try to do on the web is isolate origins into processes, so that essentially sites cannot look into each other's memory space, because basically all CPUs are flawed now which is really bad, so we've had to change a lot of things, you're not gonna see a lot of timing based specs any more, because they are susceptible to this, and basically all CPUs in the last 20 years suffer from this flaw, and it's really bad. So that's what Andrew was gonna tell you about. Just briefly on payments, so if you saw my talk last year, payments is basically now landing in all browsers, and we're hoping to ship this.
This is a first look at Mozilla's UI, this is what we're hoping to ship in a couple of months. What we're adding to payments, new for all browsers, is the ability to retry a payment, so before if your payment goes through, yeah, if it didn't, oh-oh, so now you can actually go your CCV is wrong or the postcode is wrong, and you can actually get the user to retry the payment, and we've also added very fine grain error reporting as well.
I want to show you just this video very quickly, because it shows you basically where this technology wants to go.
(upbeat music) This is by a company called Worldline, this is the prototype, so don't judge the quality of this, because this is really, really early technology, but it shows basically web payments and web authentication working together, and this is butt ugly, but the potential of this stuff is quite huge, particularly in the payments world because it will reduce fraud significantly, that's at least what we hope.
So this could be an SMS code or anything like that coming in and now this is using a UVQ which some people may have, but most people will not have this, so normally users will use for instance on Windows, Windows Hello which is the face recognition software, so imagine now you're gonna pay with something, but you'll pay it with your face.
Here the payment is the UVQ.
So I was gonna talk about innovation, why does Google go fast, I can basically just summarise it, so Google is pumping out a lot of APIs, like a lot, like you can see Google who initiates API, Google, Google, Google so it's not that Mozilla and other people are not doing that, our focus has been quantum, increasing the speed of the browser, and also on user privacy, so while it looks like Google is doing all this innovation, because they're getting stuff to developers, at the same time the browser vendor's are doing innovation on privacy and security, so there's a whole bunch of other stuff we could have talked about, but way out of time, thank you.
(audience applauds) (upbeat music)
