 So yeah, let's start right down there. You, sir, first question. Hi. So I love that all the sessions today were about from very different perspectives. So it was design, accessibility, performance. But for me, I work on a website, and it was one thing missing for me, and I was SEO. So how? It seems like when you use lots of customers, so it's slightly related to the accessibility, I guess. You can implement the semantics using a lot of attributes, but it does seem to have all this JavaScript dependencies. So I guess, can you make it work with search engines, or would you basically need a completely different tool? Yes. Yes, you can. So that's a question we get a lot. And just kind of right off the bat, working with Polymer in terms of SEO is absolutely no different than building apps with any other JavaScript library or framework they might use. The problems and challenges are exactly the same with SEO for Polymer as you would get for an Angular React app or anything like that, which also means, fortunately, that same set of tools that are available in terms of SEO also work with Polymer. So if you're building single-page apps, you're going to naturally need to pre-render and pre-render on the server side your application so that it can't be picked up by search engines. And so all the set of kind of services that you might use to pre-render your Angular application, pre-render IOS, one of them, they're a number more, they all work with Polymer as well. So essentially, same set of problems with single-page apps, same set of solutions. And if you build your site just like any other site in terms of SEO, you'll get the same results. So it's no different. OK, thanks. Thank you for that question. Yes, you, sir. You've introduced us today to PolyGit and Polylint, quite nice sets of features. But things that don't exist in JavaScript, but they do, for example, exist in the Dart language, will we see continued cooperation with Dart? I could take that one as well. Yes, so fortunately, yes. So the Polymer Dart version of Polymer Library is still being actively worked on. So they are working really hard to get a Dart, Polymer Dart for Polymer 1.0 out by the end of this quarter, so end of this month, approximately, is the goal, which is great. It's a small team, it's a really small team, just like the Polymer team, working really hard. And we love all the work that they do. So they actually already have a branch of Polymer.dart for Polymer 1.0 up, so you can check it out and kind of poke around. And hopefully, they're still working on it actively. But hopefully, very, very soon, it'll be production ready. So let me do a quick Twitter question here, because it's in a similar vein. A lot of folks are wondering, how does Polymer and Angular, how are they going to coexist? Is this going to be the Taylor show? I get the fun questions. So there's a lot of JavaScript frameworks out there, even though Polymer is not a framework, it's a library. So really, there will always be a lot of libraries and frameworks out there. So the fact that we're both part of Google is just sort of a side effect to the fact that Google is a very big place working on a lot of projects all at the same time. So we work really well together. With Angular, especially with their upcoming 2.0, which supports web components, we've done a bunch of work to work on interop with it. And a lot of projects inside of Google are actually using Angular and Polymer together. So we think there's absolutely a niche for every single library out there. I think you guys have probably authored some yourselves. And I think they'll continue to work together. All right, you, sir, at the microphone. I don't know if I missed this, but that question came up in the breaks. How does browser caching play with Polymer caching in the current state of affairs? Are there collisions? Do things get messy? Is there anything I have to look out for? Thanks. I guess I can speak to that quickly. No, there really shouldn't be any issue. HTML imports, which is a primary platform tool that Polymer uses to grab dependencies. Fundamentally, you're implemented in the platform and support browser caching just fine. It works really well with ServiceWorker that was talked about a lot today, too. So really, everything should just work well and be fine. There's really no issues there. OK, thanks a lot. Thank you. All right, another question from Twitter. Someone asked, building an accessible website can sometimes be ugly. You've got things like focus springs and stuff like that. Is there anything that Polymer can help with in that department? Yeah, that's a great question, actually. So if you're actually using some of the paper elements or even the gold input elements, those are actually going to come with a really nicely designed focus state with them. That's definitely one way that you could go with it. Another way that you can consider is that if you're not going to be using the paper or the gold input elements, if you're building your own, you're going to have some focus rings and focus states that are available that are going to be built in. One thing to consider there is that that sort of look and feel, that focus ring, it might not always go with your site or your app. And that's totally valid if you don't feel that that's the right sort of way to go. The good thing to consider here, though, is that you can work with your designers to work in a focus state as part of the design from the very beginning. So accessibility really feels like a very just integrated part of the entire flow, as opposed to something that's just kind of tacked on top. From the super nerdy techie part, we try to make behaviors to actually help with this. So we've made the in-key focus behavior. I couldn't name it anything better at the time. But that basically lets you, if you have a ripple, when you're focused, you display that ripple, because it's probably going to be slightly nicer than the blue outline. So checkbox does this. RadioButton does that. PaperButton's a little bit different. But that one also has a behavior that you can override if you don't like it for your particular button. And if you're using iron control state, which basically tells you what's going on with your button, you can always listen to what's happening on focus and make your own style. So at least all the hooks are there. And then you can style it however you want. Great. Another question. You, sir, down at the mic. Hi. First of all, thanks for this awesome event. That's seriously cool. Question on a technical part. Say you have two components. One is built with web components, JS 1.0, and the other is built with 1.1. How would you incorporate it in one application without conflicts or dependencies? Yeah, so there's a couple parts to this question. So first, yeah. So in the current version of custom elements and web components, we don't really have true isolation between elements that you can register. So it's possible that one component pulls in a dependency of a paper button 1.0, and another one pulls in a dependency of a paper version 1.1, for example. And right now, elements are registered into a global registry. And we know that this is really unsatisfying. And this might, I don't know, we typically get questions like this. So we recognize that this is very unsatisfying. And it's really kind of an artifact of the fact that specs are really hard to get through, especially when we're trying to get cross-browser specs pushed through. And this was actually a known deficiency or conceit of the version 1 of the custom element spec in order to get consensus and to get it pushed through. So that's really like on the version 2 of custom elements to really tackle the notion of how can custom elements be registered or registered into scope registry so that you can have multiple versions of the same component on the page. So I think that's one part of the answer. However, the other way I like to look at it is that if you think of the NPM model where each package can pull down its own dependencies and its own versions, then each of those can pull down its own versions. And you may have seen crazy dependency trees where you have 97 versions of the same async package or something. And that model, while it's nice from a, you know, it's possible to put all these things together point of view, when you look at it on the client side, it's really just kind of incompatible. So even if we built a system that allowed you to have like 47 versions of paper button, the first thing you would want to do was go get that down to one version of paper button. And so when we think about client-side tech, it's just a little bit different. So ultimately, right now, we're kind of pushing the pain forward to say, resolve the dependencies first, because that's going to ultimately end up in the smallest payload for your app. Yeah. So follow up question on that. So would you then advise not to use, for example, third-party dependencies, because you don't have control on that? It's more just that right now, when you're using Bower, Bower will identify the conflicts. And then there's a process of resolving them. So by leveraging the package tool, while we have a love-hate relationship with the current state of package management, the good thing is that they can highlight where you have dependency conflicts and help you resolve them. All right. Let's take a line from over on this side. I got another question about the accessibility, because I know there are problems with accessibility and the focus event around the shadow DOM. But does the shadow DOM helps somehow in it? So we would like the shadow DOM to be as close to the shadow DOM as possible. In the perfect world, everybody would have the shadow DOM, and we wouldn't need to use the shady DOM. So if you're doing things where you're taking advantage of the shady DOM, because you think that helps you fix focus issues, that's kind of like a bonus of the shady DOM, but it shouldn't be there. So you should probably file a bug and we'll fix it so that it doesn't work for you anyway. There shouldn't really be discrepancies between how focus works on the shady DOM and how focus works on the shadow DOM. And we occasionally in elements find bugs where we've dug ourselves into a hole because focus is hard. And then we keep trying to fix it so that shady DOM and shadow DOM focus do exactly the same thing. I just wanted to add one thing, which is just that there's actually a lot of complex, pretty technical behavior around focus. If you consider, for example, I think it was in Monica's talk, she showed the input type date, which has the pop-up. And if you think about that focus date, I mean there's like, if you think about the notion that there's that elements focus state, okay, so it's focused. But then the actual keyboard is gonna go to the specific date or month or year field. That's pretty tricky. And this is an area in particular in shadow DOM where the spec is still sort of evolving and the behavior is evolving. It's an active area of development in Chrome where actually there's sort of experimental implementation going on, which will help inform the spec. And hopefully this will be something that will evolve relatively soon. Because again, we wanna sort of get to the point where we can very easily make kind of that kind of complex behavior that you can do in these built-in elements. I just wanna point out that this is kind of an interesting aspect of Polymer being part of the web platform team at Google. Is that when the guys who are working on new browser features like shadow DOM and like these questions about focus, have a concrete question, like how should this work? They have a team that they can come to is sitting there right on the bleeding edge of what all you guys are doing out there on the web. And we can actually give them feedback and really tighten the loop back with the browser vendor. So I think this is a, it's a really smart thing I think that Google chose to do with kind of having a client-side framework work so closely with the platform team. Also, focus is really hard. Like literally the hardest. Okay, thank you for that question. Another one from Twitter, and this is actually something someone asked me in person out on the floor the other day too, what's the best way to share data across elements? Number one, think locally. Number two, composition. Number three, the mean, what about? So. So. Right, you guys got it. Listen to the first tech talk. So I mean, that's basically the answer. I mean, you know, we, like I went into excretion detail, we've kind of codified this notion of, you know, being able to share data through a tree, but not in a super undeterministic way. It's all shared from one mediator to another to another. And then those notifications, you know, always flow through that tree, through those connections that you've made in the bindings. And so, you know, in general, you know, application data that is truly shared that doesn't need mediation, that doesn't need someone to kind of make a decision in between before it's propagated, it's very easy to just use Polymer's two-way binding system. And I think, you know, the one, you know, place that sometimes comes up is, yeah, I started out binding this stuff together and then I realized that, you know, but I needed to put like an if statement in there somewhere, how do I do that? And that's just kind of, you know, a sniff test that, you know, these things aren't actually shared, they should probably have two names and then there's some mediator that's, you know, making some decision and passing the data along. So, you know, I think it's really key, you know, hopefully you have a better understanding now of what the data binding system in Polymer is actually doing. And then you can make the decision when you want to just fall back to, you know, kind of using events and mediating the data manually versus kind of using the built-in data binding. Okay. Over there. Hi, so we've done a lot of work on our components to follow the structured data model or schema.org stuff. So my first part of the question is, one, will those components, although we've tested them inside the tool, will they actually be picked up as rich snippets? And the second part was, are you doing any work with elements for those kind of things like schema tags and social tags? Yes, great question. Absolutely, and 100% it will work. It will get picked up by search engines and shown as rich snippets. And we've actually done a lot of experimentation with this. At Google, the search engine crawling team, there is a strict firewall between them and any client teams. So we have as much information out there as all you have in terms of actually how the internals of the search engine work. But we actually have done a bunch of experiments and there are experiments live on GitHub that were posted about a while back, about a year ago now, on the Chrome developers blog that goes into exactly this. And it's multiple examples of polymer elements that get internal state and data and then expose that explicitly through attributes that can then be picked up, schema.org attributes, things like that and get picked up throughout the entire loop and then rendered as rich snippets and things like that. It absolutely works. And it's actually a really cool model because we can expose this data. I think the example was you have a location and you wanna expose that location data so that it's picked up by the search engine. And you only have to have that data once. You don't have to now, if you were a hand coding or hand coding this markup with schema.org, you'd kinda have to repeat yourself in where you put the location latitude and longitude in the schema.org and then in your data and how it flows throughout your application. But fortunately with data binding and reflecting to attributes, you can just have that data once in your application and it can be both exposed through the schema.org and it can be exposed however your app needs to expose it. So it's absolutely use case that works well. What about rival social networks? It's schema.org. So, you know, however, whatever social network support that markup would support this. And similarly, Open Graph, you can do a very similar strategy with reflecting it and it should work. I can't speak obviously to how other networks do their fetching and their parsing and their crawling. But ultimately, again, exact same things you'd run into with any type of JavaScript rendered application. It should work and you just got to try it out. Great, thank you so much. Yeah, over here. Hi guys. There are a lot of bugs nowadays. Like the components are cool, but not cool enough yet. Polymer is cool, but not cool enough yet. And just to make it clear, for your opinion, what is the weakest point of Polymer now and how can we as a developers help to improve that? And yeah. Well, let me give you my take. I think that maybe the weakest point is from my perspective, sort of as a core engineer on the team is a very technical point, which is just that we are embracing the platform. I think this is the future, but it's very hard for us because while Chrome's implementation is great and native in there, it's really hard to try to polyfill this behavior on other browsers. And the work that we have to do and sort of honestly, the fact that we have to spend a lot of time doing that work is kind of the weakest part from, it slows down our progress. It makes it harder for us to get stuff to you guys, the fact that we have to do that hard work. So the good news on that is, you've heard some stuff about how native implementations are coming to other browsers and the faster the better, because then we can all sort of reap the benefits of that and as the platform grows, we grow and everything's better. So I mean, the good news is the weakest point is gonna go away, but it's, for a little bit more time, it's gonna still be difficult. Hopefully just for us and not for you. Yeah, I was just gonna add, yes, and what can we do to help? I mean, it's kind of call your senator. Make it known to the other browser vendors how much we really need these primitives, especially things like Shadow DOM that are just, we tried, they're virtually impossible to polyfill because they're such a core, incredibly needed piece of functionality in the platform. So as soon as that becomes native, we're all gonna benefit tremendously. We can stop worrying about spending all this time doing the polyfilling and stuff. But like Steve said, like Taylor read off this morning, there's a lot of really good momentum. So we're very happy about the future. So kind of actually following on that a little bit. A while back, and this is one of our Twitter questions, Mozilla wrote a blog post saying that they weren't planning to implement HTML imports instead favoring ES6 modules. So what is the team's thoughts on that? Sure, I can speak to that a little bit. So I think the important thing about that is to sort of note that they didn't say they're not gonna do it. They said they're not gonna do it right now. They don't think it's a top priority compared with this other thing that's got this other specification and is sort of on track with other ES6 features. So that's fine, and that's reasonable. And Chrome, honestly, is also implementing modules. They've also implemented HTML imports. And the awesome thing about that is that fundamentally sort of it was something that a bunch of the Chrome engineers, Blink engineers got together and realized that the fundamental sort of design parameters of those two systems were compatible. And there should be a way to sort of get the best of both worlds. And there are some people now working on that. And I mean, I think as that evolves, we will hopefully see relatively soon the glorious future where we have modules implemented natively and they interact correctly with imports and sort of everything works nicely together. This may take a little bit more time, but we're gonna get there. Because fundamentally, I think they're compatible systems. They both have sort of an asynchronous loading model. They both have a lot of commonality in sort of the way that they want to de-duplicate resources. So yeah, I mean, I think fundamentally we're gonna get there. It's gonna take a little bit. And I think at that point, I hope that the browser vendors will say, oh, okay, there's a lot of power to having this declarative HTML way of loading resources along with this script-based way. And they should be able to coexist and interact. All right, yeah, once more over here. I guess on a similar vein to what you guys were talking about just now, how would you advise someone writing a Polymer app now to guard against the possible flux and like API implementations of the different vendors to some of these standards? So someone writing a Polymer app now, what would they have to do two years from now when some of these standards might have changed? How could you mitigate some of that? How could you prepare for those kinds of scenarios? So yeah, I can speak to that again just quickly. This is kind of what I was alluding to you when I said we have this hard work to try to make that substrate of Polyfills relatively sane for cross-browser development. So as we get, I mean, so far, we've really only had to deal with the native implementation in Chrome. And honestly, it's hard to Polyfills. So we sort of try to find the sweet spot of the features that we need to get where we can sort of get cross-browser performance. As other features come online in other browsers, we're gonna have to sort of take hard look at saying, okay, so now Firefox implemented this. Let's try to let that part be native and let the Polyfill fall away here. So we're gonna need to manage that so that people using Polymer are not gonna have problems over time. We're committed to doing that. We have a lot of experience doing it at this point. So I mean, I think what basically the answer is, is that as native implementations come online, Polymer sort of, I mean, honestly the web components Polyfills, which really are not part of Polymer, but are used by Polymer, are gonna have to sort of adapt and be able to coexist with the native implementations. So what you're saying is that the Polyfills are gonna drop back to the native implementations, or are the Polyfill APIs gonna change? So I mean, I think the exact shape of the solution will have to evolve as if Safari implements something that's problematic versus Chrome I'm gonna have to see at that time. But the notion is that once you get up to the layer of Polymer, hopefully you've got an API that's stable and not gonna change out from under you. So we will do the work that we need to do. I mean, I can't promise anything good guys, God knows what's gonna be actually implemented, but we're working really hard to make sure that it's reasonable and follows the spec. And so far all signs are good. So I mean, I don't really anticipate anything that's gonna be fundamentally like so hard to deal with there. I think pretty soon let's hope that one of the browsers implements native shadow DOM and other than Chrome and then, you know, you can use Polymer's Polyfill for that only selectively and not on that browser at that point. So I think it's gonna be pretty clear. And from an element's perspective, we test all of our things both in the shady and shadow DOM so that if at least the shadow DOM comes around, if you're just using our elements you shouldn't really notice a change unless you've been cheating and just using explicitly shady DOM things. So if anything changes, we'll like at least make sure that the paper elements and the iron elements are gonna work fine. Thank you. One of our engineers, Peter, today gave a lightning talk. I think he said, we got your back. I think that was the phrase, you know. So, you know, the Polymer team here is committed to kind of helping make any of these transitions as other browser vendors kind of bring their native implementations online to help you adapt and, you know, we may have tools and that sort of thing to help convert. But we are, yeah, we got your back. All right, another Twitter question. What is Polymer's accessibility roadmap? What does that look like? Absolutely, that's a great question. So accessibility is really just very highly integrated into the Polymer library now. So we had a lot of work leading up, obviously, to the 1.0 launch, going through all of the testing, all of the identification of any sort of user issues, then figuring out the right ways to implement solutions to these issues. But we obviously don't wanna stop just at Polymer 1.0 launch. We wanna work and we are working together at a very regular basis. So every time that new changes are actually implemented across any of the elements, they're going through substantial testing. If any of you were, you know, if you were listening to the talk earlier, we've got a significant way of testing across a lot of different components which we've outlined in the gold standard accessibility checklist which is available on GitHub. So we definitely encourage that everybody takes a look at that. So that'll give you a sense of kind of the different use cases that we are testing for for each of the individual elements. So things like, of course, keyboard focus, focus states, keyboard interaction, is that working. Things, testing with screen readers and making sure that everything is, all the declared semantics are working properly. Labels are implemented the right way so that a screen reader can get the most clear and intuitive spoken feedback to the user. Then looking at things like contrasts and color, the way the colors are rendering, magnification, all of these are being regularly tested across multiple browsers, multiple sets of assistive technology and screen readers, and multiple operating systems. So this will continue in addition to some automated testing. So for instance, the accessibility developer tools audit, that's all being executed on a regular basis. And moving forward, I mean, accessibility is definitely a moving target. This is a dynamic world that we live in. So I would say, you know, we're basing all of this based off of the use cases that we can think of now for the users that are out there with varying assistive technology needs. But who knows what sort of technology is gonna come out in the future? I mean, that's an amazing thought that things might come out in the future that can totally revolutionize our world even more. So, you know, as that happens, we'll have to incorporate that into testing. And also we'd love any additional feedback. Like if there are additional use cases that some of you can think of right off the bat of, oh, you should consider this or that, let us know for sure. I mean, we've got the Polymer Slack channel and you can find me on Twitter. Anything that you need, like we wanna be listening to you and incorporating that feedback and working that into our roadmap. Also, I think my personal next plan for accessibility is RTL. We've sort of slacked off on RTL really badly and the Chrome settings page is coming after us. So RTL will get better and maybe look at internationalization. That's the thing that's on the roadmap. And also Laura mentioned the Polymer Slack channel if you are not already on that. That is at Polymer-slack.herokuapp.com. You can go there to hop in the channel and discuss things. All right, let's take another question from over there. Hi, so I really liked the mediator pattern. And I was also wondering if you have any experience with like taking a donor application, which is, for example, an anger application and wrapping it in your own component and then reusing it in your app. Is that something like you have any experience with rebuilding Google apps or is it just, well, do a green field and take it from there? You mean specifically just like literally putting something that was already built in some other technology in kind of hiding that in a custom element and then using that? Yeah, I mean, we actually, I mean, it's kind of funny that there are a lot of, because that declarative interface is so powerful, we do this wrapping a lot. I mean, not specifically with a full angular application, for example, but there's no reason that you can't, right? You have lifecycle callbacks and you have a DOM node in which to render stuff. And so, for example, like people do stuff with D3, for example, there's a lot of examples. We've often taken like jQuery widgets or something like that, something that's really useful. Then you can just, you pull in those dependencies through its import and then in the custom element, you can just hide all that, have the jQuery widget or whatever, render itself into the local DOM and you can totally expose that out as an element. So yeah, fully possible. All right, so we're gonna take, these will be the last three questions, the speakers up here. So yeah, we'll start over there actually, you sir. Sorry to ask you another one. So Eric talked about when to get better performance at the polyfill, you only load it on browsers that need it. And as browsers start adopting features, that gets more and more complicated. I was wondering if you'd thought about maybe making that into a Bower component that was version based on different browsers that we could pull in. That's a good idea. And I think that, I mean, so far, we haven't really had this problem because mostly it's been, the native implementation has been on Chrome. I think this is something that, it's a thing that we'll have to evaluate as some of the features are coming online and other browsers for sure. And yeah, I think we'll try to make sure that that continues to be straightforward and as easy as possible. So yeah. Yeah, we'll definitely evaluate a case-to-case. That reminded me of a case, there are like two or three small things that we ship in the web components light polyfill that are only there for IE. It's like for IE 10, you need, they don't have, I don't know, weak map and mutation observer and a few things. So we polyfill those and we kind of had this question. It's like, well, that's like 4K, maybe we should make a different version of web components light just for IE. So like for, so that you could do that. And that one it was like, no, maybe for the complexity of having to explain that to all you guys, like use this one for IE. And maybe the 4K is okay. But if that got to something significant, we would totally look at doing that. All right, yes sir. Hello. I have a question about internalization. Do you have any plans, any tools, elements to use for internationalization? Yes, absolutely. So there's an element for that. So they're actually, I talked a little bit to this at the beginning. And this is kind of our typical answer, at least today for internationalization and similar topics, which is there are a whole bunch of different strategies that you can use for internationalization. So we've already seen a lot of different apps. You have different techniques of approaching internationalization. Eric Bodleman actually wrote a great example with the Santa Tracker that launched with Polymer, which used one, I think it was an I-18 message. And it was a filter or an expression around the binding system that looked up translations to be able to do internationalization. That's one approach. We've also written I-18 next element, which uses a slightly different approach to mapping out translations and things for internationalization. This is absolutely something that we wanna tackle with the carbon element set, this new kind of element set that we're just working on to do app level structure. So internationalization will be a big piece of that. Of course, it will not be necessarily the only solution. All of these are good solutions and it really depends on what you need for your application. But we do wanna build a kind of polymerific internationalization solution with that component set. So coming relatively soon as we build that set out. But in the meantime, there are these existing solutions out there that have worked successfully on various applications. Okay, thank you. Thank you. Last question. Hey guys, yeah, thanks. Thanks for all your work, by the way. Yeah, I mean, like the specs are awesome and like you guys gotta go through a lot of stuff. I mean, also the other browser vendors. It's really cool what you guys are trying to do. Yeah, I had a question. Because I mean, like isomorphic and universal, this is becoming like a trend right now, right? And as well as like native, so react native and then you got Angular 2, you can render to native and even the command line, it's like crazy stuff, right? Is there actually, I mean, maybe this is a stupid question and it's pretty early, but is there a future in other platforms for web components? It's a very good question. So we consider on the Polymer team, we are native, we're native on the web platform and we're native to the web platform. We're as tight to that platform as you can possibly get with web components and that's really the value that web components gives us. So one way to think about it and the way we like to think about it is that that is our native platform, it's the web. Web is only getting better, it's getting better on mobile devices all the time. You get all these benefits building on the web platform that you don't get building natively. And so that is our focus, is building on the web platform, making the web platform the strongest platform that can possibly be for building everything from basic text rendering applications to really full-fledged interactive applications and beyond. So that is our focus today. And certainly Polymer 1.0 is only three months old, so there's a bright and broad future ahead of it and we certainly would be excited to see any experiments or things that any of you would be interested in building to experiment with this kind of rendered in native. It's an interesting idea. And what Polymer is beyond being native to the web platform, it's also this component model. And the component model and the mediator pattern that Kevin talked about, that's certainly all applicable to other platforms. So from the kind of componentization perspective and that philosophy of how you build things, that could apply broadly across platforms. And so you can imagine our paper buttons up there, it's just markup, it's just HTML. If you're building an Android app, if you're building an iOS app, you're using XML to lay out your application anyway. That translates relatively, it should translate relatively straightforward. So absolutely it should be possible. It's not our focus today, but we're excited for the future. Cool, thanks. Thank you. All right, I think that's actually the last question. Please give it up for the speakers.