Tip:
Highlight text to annotate it
X
>>Jim O'Donnell: So for our question time panel which feature from your competitors
do you most envy and wish you had in your own browser? Who wants to start?
>>Chris Mills: The IE6 rendering engine. [audience laughs]
>>Gervase Markham: Actually, he's almost serious in that if Firefox had a built in
copy of the IE6 rendering engine we could probably capture that market share which is
still stuck on IE6 right. Because all their proprietary, internal intranet sites still
work. No, maybe not. >>Paul Rouget: So, I think it's a case of
Firefox, it's. I'm looking at you. I think multiprocess is something we're looking for
in Firefox. I think it's going to be really important to have this, right? So yeah, multiprocess for Firefox.
>>Michael Mahemoff: I sort of think I would
have said advanced audio which I think is something that Mozilla's had for a long time,
but now there is something in Chrome although I think it's still more advanced in Firefox.
I suppose there are some things, the Zoo model for extensions, gives you the ability to do
things what you can't yet do in Chrome. Like I was saying this morning, for extensions
Chrome is more task orientated and anticipating what all the main use cases versus all that
just opens up the whole browser.
>>Mathew Staikos: I think that one of the
interesting things that Chrome has going for it is the multiprocess aspect as well and
the process separation of codes into the [inaudible] in the browser, so I think that's really interesting.
>>Chris Mills: Given that I'm a complete CSS junkie
I really love some of the CSS3 functions that the WebKit based browsers
have, like the animations and hopefully we will get those soon but not soon enough for my liking, so.
>>Jim O'Donnell: Why are people reinventing
their own widgets rather than using the W3C standard for widgets?
>>Paul Rouget: Don't ask me.
[Audience laughs]
>>Audience: Ok, so we've seen JSON based
packaging of application for Chrome Webstore and I think Mozilla is also reading Chrome
manifest format for extensions. But the W3C widgets spec is probably 90 percent there
and it's supposed to be extensible, so why are you not trying to follow the existing standard
>>Michael Mahemoff: I think in the case of
Chrome there were basically 2 options and they went with one or the other. They both
had strengths and weaknesses and it was basically building on the extension framework so that
you have the idea of packaged apps, that are apps, using the kinds of things widgets do
but they are also very closely tied in with the extension framework. I think the way things
have gone is that there is very much, if you look at most of the apps on the store there,
at least at the moment, there have been hosted apps. So you could argue that there it's
closer aligned with widgets but it was the kind of thing of getting it out and seeing
what people did with it, and then hopefully evolving it and trying to tie in with like
that as a standard, or trying to evolve it into some other standard. So it's definitely
always the intent to keep these things and make them more standard. But it was a case
of getting it out there, seeing what people do with it and evolving it.
>>Paul Rouget: Also, so for information. I know that we have an implementation of the,
with the widget. It's an extension, but it's not good. I think that the answer of this
question in our case is that widgets are cool, but that's not all. That's not everything.
So why do you need widgets right? >>Audience: I don't mean widgets as in UI,
but as a concept where you have a zip file with a bunch of HTML and a Manifest file.
>>Paul Rouget: Yeah, you know with the Prism like application, stuff like that? Yeah, I
understand that. But so, we're working on the web apps these days. Chrome has app store,
we have, we're working on an app store too. And we're going to have, do you think we
just need this zip mechanism with files inside? I think we need something more complex than
that. With AP, coming with APIs. I think it's more complex than just the W3C widget specification.
I think it's not enough. And I don't think it's covering all the needs today and the
future needs as well. I know the specification, I know how it works. I think packaging is
maybe not the right way to do it. Or maybe we want to transform a webpage to an application.
I'm talking about something we're working on these days. It's, but when you have Twitter
on my phone, right? Maybe I don't want to go through the widget thing to have Twitter
webpage as an application. Maybe I want just a button and transfer this webpage as an application,
right. I think all this stuff we're covering, you know the installation of process of a webpage
as an application and bringing APIs and all these things, also the permission system.
There's a lot of things that are not covered by the widget specification. I think we need
more than that really.
>>Chris Mills: Not really, because we do use
the W3C widget spec and in fact we wrote it, pretty much.
>>Jim O'Donnell: Next question: In the theoretical world, where all browsers render things in
a standard way, is browser user experience the only way to compete? So if each of you
guys supported exactly the same parts of the HTML5 spec, how would you choose between browsers?
>>Gervase Markham: Not entirely, speed would also be a way to compete. But user experience
considered broadly, yes. I think there are still philosophical differences between the
way different browsers approach sort of a user's interaction with the web. And the
way I think it works and the chap from Chrome will feel free to disagree with me is that
Chrome is a window on the web. That is to say it wants you to see through it. The webpage
is the thing, the browser just gets out of the way. It's as simple as possible and we,
I think of Firefox more of like your butler. It stands behind your chair, you know, not
getting in your way. But suddenly when you need something, here you are sir, it's there.
I mean it's more, it assists I think in more ways and therefore. So I think there are different
models, so yes. The user experience in the broadest sense, perhaps. Yeah, but that's
also hypothesis contrary to fact. It's like if the moon was made of green cheese, then
what would this be like.. or whatever. >>Michael Mahemoff: Yeah, that's what strikes me.
It's a very theoretical proposition, because the browsers will always evolve and
choose different features and evolve at a different pace.
>>Paul Rouget: Also for competition you have where the browser is running. We all support
like open Linux, Mac, Windows and some phones and look at Opera, they're running everywhere
right. It's another way to have a competition where you manage to make your browser run.
>>Michael Mahemoff: There are quite a few other aspects, so you mention speed, there's
also other things like security and there's also the whole developer experience and how the
developers look into all things like this. >>Mathew Staikos: And in the case of mobile
as well it's definitely about security, speed but also about how well you implement things
for battery life and to minimise network traffic and that kind of thing. Those types of differentiators
exist today between all the different WebKit browsers. Which effectively render things,
more or less, in the same way. >>Chris Mills: Yeah and that sort of goes
into what I was saying earlier in my talk, all about streamlining, I think that's before
I even had any beers at all, streamlining the way that your browsers run and making
them small enough footprints, so they'll run on even older operating systems. Because
if you look at even the Eastern European countries and a lot of even more developing countries,
a lot of the spanking new hardware that we use for a year and then throw away, will end
up in those countries. And we need to consider, you know, people who haven't got the latest
operating systems and things like that as well. And that also goes onto the mobile space
as well you know. People that use slightly less powerful feature phones as well as the
latest smart phones. And that's what we always try and do with our browsers, is making sure
we always can consider all of those folk as well as the people in the US and the UK and Western Europe.
>>Jim O'Donnell: As an IT manager at a London
university, I recognise that I am a dinosaur. IT services are often run by middle aged men
using email and SMS and out of touch with communication methods and browsers of today
and the audience is a different generation. Is this a barrier to change? A barrier to
innovation as well maybe.
>>Unknown voice: Yes [Audience laughs]
>>Chris Mills: What can we do about it? It's
very hard, isn't it? I mean I spend a lot of my time going into universities and colleges
and trying to improve the way that they teach web design and improve the set of browsers
that they've got installed on their systems and there's so many varying factors that
present a barrier to actually pushing things forward. You know sometimes, in terms of getting the
browsers installed, it will be something along the lines of, the system administrator guy
knows how to administrate and make IE6 secure really, really well. Therefore his job, his
attitude is that if it's not broke, why should I fix it? Which of course creates problems
for people that actually want to get new browsers on the system. And also with the teachers
like. Actually teaching web design, a lot of the current curricula, were written 15
years ago, but they just haven't had the knowledge and the money to update it since
then. So these kinds of things are going to be an issue for a very long time. So, it's
hard to get stuff changed quickly. You know, it has to go through 4 different committees and..
>>Gervase Markham: And in terms of, the difficulty
is of course that he says, if it aint broke don't fix it, the only way he's ever going
to fix it is if it does break. And if it does break it means that people like you are going
to have to write websites that don't work in IE6. And of course there is pressure not
to do that because you know you don't want to be throwing customers on the floor. You
know, I had an idea about, I don't know 12, 18 months ago and I never kind of got around
to implementing it or being able to put enough oomph behind it. But the idea was
called Death of IE6 Day and way that it would work would be that sites would say that we
are no longer committing to support IE6 beyond date. Where date was about 6 months after
the launch of the campaign right. We're not saying we're not going to support it, we're
not committing to support it, right. Then you have a website that lists all of the sites
and all of the companies that are committed and it gets longer and longer and longer,
right. And then you send this to your IT guy, right. And say, ok, you can do 2 things. You
can check that there is no site on here that is business critical for us. Here is a list
of 5000 sites. Or you can just upgrade our browser. At that point, they go, hmm, there's
a big risk here. If one of those sites is really important to someone high up in my organisation,
I could be stuffed. Maybe I should upgrade the browser. That was my thought.
>>Chris Mills: It's a nice thought. I like your way of thinking, it's not even that
simple, is it? Because quite often you'll have a great big company which is stuck on
IE6 as one of their critical accounting systems or something will only work on IE6. And a
middle manager paid a quarter of a million pounds for it 10 years ago and won't admit
that he was wrong. >>Gervase Markham: This is an awesome opportunity
for Opera, Chrome or Firefox because installing multiple copies of IE on the same machine
is kind of difficult. Whereas you know installing your alternative browser alongside.
>>Michael Mahemoff: This is where a Chrome frame comes in. It's sort of solving, just
by the way [Audience clap]
I mean what I've seen is there are two kinds of, it's helpful in all these sort of situations
to understand the motivations and the fears of these people who are making decisions.
And it and what I've seen is that there are two kinds of, two rationales to the keeping
IE6. One is that people have this kind of idea that it's kind of secure, or whatever
fantasy they want to entertain. And the other is simply the legacy problem. And for that
second case, where they're bound to IE6, even though they know full well there is a
big bright world of modern browsers out there. That's the sort of scenario where Chrome
frame can help. >>Gervase Markham: So Microsoft could actually,
they've recently launched a site, I don't know if any of you saw it which is designed
to help with this problem. But the biggest thing they could do to help with this problem,
someone blogged this and I thought this was awesome, was just take the IE6 binary and repackage
it as a standalone download, right, for later versions of Windows. So, if you need IE6 for
your web app, then you have this purpose built binary that works with this web app.
It's like a sort of, it's like a Citrix viewer, or some kind of viewer for that web
app. And you just use the IE6 binary for that and that's all that it does. The system browser
is something more modern, IE8, IE9, Firefox, Chrome, whatever right. If they were to package
it up that way and de-entangle it from the operating system, so any version of Windows
could install a list of standalone stuff linked to the IE6 binary. Then I think that would
remove a lot of the barriers to having IE6 as the default set browser. But of course
there may be political, or technical reasons why they wouldn't want to do that. But it
would be, I think it would make a big difference.
>>Audience: Can I just come back because I'm
the old man that wrote that out. I think one of the problems is, you know, I was
bought up with the telephone and this that and the other, been in IT for 30 years. There's
a big difference between the 50 year olds that are making the decisions, that are still
you know, got no understanding of this technology or very little compared with my sons and daughters
that seem to you know to take to it like a duck to water. I think a lot of it's down
to the fact that probably my generation just don't understand the benefits. But also I
think, especially in the university sector, sometimes we just don't ask what the customers
really want. And you know we've had that before where we've announced an email policy
for all and all the students just laughed at us because none of them used email.
They're all using this Twitter this that and the other you know, and I think it's
a matter of you've got to ask the youth of today and understand what's driving today's
customer. >>Gervase Markham: In terms of browser upgrades,
there's a difference between understanding the need for a more modern browser and understanding
the needs for some of the communications tools, that, as you say, the youth of today are using.
I mean I personally, this is going to be a controversial view, think that Twitter is
pretty much a gigantic waste of time and space.
[Some small applause]
A few people agree with me, but you know,
I don't have to understand or appreciate that some people get value out of Twitter to know
that, for example, a browser needs an upgrade. Or I don't have to have a Facebook account
to know that a browser might need an upgrade. So I think that the problems that you talk
about are not the same problem.
>>Jim O'Donnell: If you have a phone, we're
getting interference on the audio, you might have heard clicking noises from somebody's
phone, so could you make sure that if you've got a phone and you're not using it that
you turn it off because it's interfering with our recording the session. Thank you.
>>Audience: Are they here? Sorry, can I, time
for one for question? Sorry, I'm real sorry. It's really cool having all you guys here,
but sometimes when you come to events like this you kind of realise that you're in a
utopian world. And one of the things that I never really hear from you is putting into
perspective, money. Because the reason why a lot of people are not upgrading is money.
It's the cost of upgrading, it's not just, oh, let's update the browser. And until you
can figure in or factor in the cost of money, sorry, the cost of upgrading, then we're
all just talking here as people who are knowledgeable and know that yeah, we want the latest fanciest
browser. But in organisations that's not going to happen. So, how do you think? Or
what is the method that you think you can use to get in there and talk to them about money
>>Gervase Markham: Well the cost of upgrading
doesn't necessarily go down. The way people keep it low is that they upgrade infrequently.
So that they incur that cost not very often. Which means that and we do see this, that
over time, eventually, this IE6, kind of body of users will slowly decrease. And these are
people that don't incur the cost of upgrading very often. But the other way that the money
balance changes is when the cost of staying where you are increases. In terms of increased
user support, increased difficulty with patches. Your operating system goes out of support.
Your browser goes out of support. Your boxes get routed because your browser has a hole.
>>Michael Mahemoff: Additional development complexity.
>>Gervase Markham: Yes, additional development
complexity. There's not, I don't think there's much we can do to, I mean we can't really
make it cheaper for an enterprise to upgrade all of its desktops. Right, because the costs
involved with that are not things within our control.
>>Jim O'Donnell: Ok, this one is specifically
for Firefox, but we can maybe talk about vendor prefixes in general. Which CSS3 features can
we drop the vendor prefixes from when Firefox 4 is released?
>>Paul Rouget: So, text shadow, box shadow, the background size, background position and
we still have it for transitions, transformations and gradients. I think that's all.
>>Gervase Markham: The resource you need to answer this kind of question is developer.mozilla.org.
It's an awesome web developer resource and you should all use it. It doesn't just cover Firefox,
it will tell you, yeah, proper documentation for JavaScript. Join the campaign.
>>Paul Rouget: About CSS3 we wrote a blog
first about where we dropped the extensions. On hacks@mozilla.org. And if
we drop another extension we're going to blog about it on this blog first. And we have on developer.mozilla.org
we have a div, I mean we have a list of stuff that changed between Firefox 3.6 and 4.
>>Michael Mahemoff: For Chrome, I can't remember if it's on that url I gave today
on 3ofe/chromestatus, but if not I'll make it an action to see if we can actually get some information on that.
>>Audience: This is a Firefox question.
You said you weren't going to change the engine between 5,6,7. So does that
mean there won't be any dropping of prefixes before the next engine release?
>>Paul Rouget: If we drop a prefix, it's going to be for Firefox 7. I mean I think
so. I mean so far, from what I know, from the run map, we're not planning to drop anything.
Maybe gradients, I don't know. >>Gervase Markham: The reason you have a prefix
is either because the implementation is not complete or because the standard is not complete,
right. If it turned out that we'd implemented a draft standard and we'd done it, a really
good job of it and the standard became final and was exactly the same as what we'd implemented
and therefore switching wasn't a case of just changing any code, just dropping the
prefix, who knows? I don't think there's a policy on this is all I'm saying.
>>Paul Rouget: And whatever happened with, I mean, if we decide to drop a prefix we still
keep the version with the prefix, ok. It's not going to break anything.
>>Jim O'Donnell: Is HTML5 at the moment a backward step for accessibility? Browsers
can be upgraded, but assistive technology is still expensive, and HTML5 support for assistive technology is poor.
>>Chris Mills: That's an interesting one.
I don't particularly think of so much because there are free screen readers available. And
a lot of the implementations in HTML5 are written to have improved accessibility out of
the box. For example HTML video players are keyboard accessible out of the box and a lot of the form
elements are keyboard accessible out of the box. Which is basically just getting rid of work that you previously
had to do to make that sort of stuff accessible. And at least it means that the companies that
don't particularly care so much about accessibility which is quite a few people. At least that
stuff is given away for free anyway. >>Jim O'Donnell: Video player I think still
doesn't support captioning officially. >>Chris Mills: Oh well with captioning, there
is. We've got an implementation of WebSRT now with track element so it is coming, it
is coming along. >>Gervase Markham: And on the particular issue
for captioning a quick plug for universalsubtitles.org which is a Mozilla drum beat project which
is basically about putting translations and captions on every single video on the internet,
eventually. So yeah, if you're putting up a video on your website and you want people
to be able to caption it, then use their infrastructure. It's pretty cool.
>>Chris Mills: It is pretty cool, I agree. >>Michael Mahemoff: And at a higher level,
I think accessibility is a very nuanced concept and HTML5 is helping to replace what were previously
black boxes, you know, binary holes of Flash or desktop apps that have no content whatsoever.
HTML5 is basically embracing the general concept of the web which is mark-up plus styling.
So it this is where people sort of talk about Canvas being the new Flash and not having all
that. But as far as many of the core elements of this and the fact that for instance with
font face we can do text now instead of actually just storing it in another black box of just
images just generated on Photoshop. There is a lot that this is actually helping with
accessibility as well. And things like also what you were talking about today, web forms
and, you know, micro data, there's a lot more of about being declarative and
that is all hopefully useful for screen readers of the future as well. Albeit that they do
have to be upgraded at a cost. >>Paul Rouget: And these days there's a group
working on accessibility for Canvas 2. They're talking these days so they're going to have
something for Canvas 2. So I think it's way better and I mean just thinking about not
having to use Flash plus the forms just this is a big change for accessibility.
>>Jim O'Donnell: And I'd add that AT does tend to have much better support for
WAI-ARIA nowadays. So even where it doesn't support HTML5 forms you can add attributes
to your JavaScript slider widgets or whatever that will tell assistive technology that this is
not a div or a span this is actually a slider, and assistive technology understands that.
>>Gervase Markham: There's actually one other
HTML5 feature which hasn't been mentioned at all today which will be a big boon for accessibility
and that is the additional semantic element. So when you know what's a side bar, what's
a section, what's the main part of a page it allows a screen reader to jump directly
to the content rather than having to plough through a mess of div
class equals this, div id equals that. Also, I mean the additional power of CSS3 means
generally less HTML mark-up. You have more power in your styling, you need less structural
elements. And that's got to be a win for accessibility as well.
>>Chris Mills: Yes, something that we recommend that you do if you're worried about
the screen reader support from the semantic elements is use the new semantic elements
but also put the WAI-ARIA attributes on them as well, just to give that extra step of backwards compatibility.
>>Audience: Landmark roles..
>>Chris Mills: Yes they are
>>Audience: [Inaudible]
>>Chris Mills: Of course another thing to add is that regardless of what tools you're
using it's still possible to completely screw up the accessibility of the site. And
so it's really down to the implementation completely aside from the actual, particular
version of HTML you're using. >>Audience: Thanks, so yeah this is my question.
I appreciate that HTML5 you know will provide all those things you've just talked about.
And with the point about in NVDA, it is getting better all the time. From my experience that
where people are using JAWS it's because it actually supports other things besides
the web browser which of course in the real world other people are doing things other
than browsing with the web, and I think if NVDA can actually improve to actually incorporate
other applications as well then I think the gap will fill quite quickly. But it's a concern
I have like with the costs of upgrading JAWS is a lot of money and that's why we
talked about the IE6's lag, it's going to be screen reader lag for the same reason. So thanks
>>Jim O'Donnell: Mobile browsers? How far
are your mobile browsers behind your desktop equivalents and what are the main differences?
>>Paul Rouget: So, I have a list. >>Gervase Markham: It's quite a short list, isn't it?
>>Paul Rouget: The thing is, in Firefox 4
for mobile, we have the same engine right. But we have multiprocess and some features
in the case of Firefox 4 are not working very well in the multiprocess world. So we don't
have IndexDB on this phone yet. We have some troubles with video, it's not working
perfectly well. But there's something else. The thing is, there's a lot of different phones,
right. So I have one here, I have another, the one there, and WebGL sometimes works,
sometimes doesn't. So WebGL, sometimes video, sometimes IndexDB at times isn't working. Yeh
>>Audience: [Inaudible]
>>Audience: and the other way for Firefox 4 mobile we have stuff which we don't
have on the desktop, like the multiprocess, for now, as well as the notification things.
>>Gervase Markham: And do we support GL Location on the desktop for Firefox 4?
>>Paul Rouget: Yeah >>Gervase Markham: Ok, we do. A little while
back it was just the mobile, but I guess it's now on both.
>>Mathew Staikos: This is a really easy question for me because we only make mobile browsers.
But I think what's interesting is that the mobile browsers that we do have
>>Gervase Markham: The difference between your mobile browser and desktop browser are vast!
>>Mathew Staikos: They're huge! It's interesting
though, if you look at what we have on our latest devices like the tablets we're coming
up with, the capabilities are actually very, very close to desktop capabilities period.
So there's they're starting to get really really close together. Even though we don't
have our own equivalent of the desktop browser, but compared to the other vendors, our mobile
browsers are actually very strong. >>Chris Mills: With Opera, we pretty much
keep it as close as possible between the mobile and the desktop rendering engines. Effectively
uses the same engine for each equivalent version, it's just that we might have some of the
features turned off in mobile, due to performance reasons. You know, things like,
do you want to have a massive great big sprawling animation transition flying around on your
mobile screen. Probably not. And it tends to slow it down quite a lot on some phones.
So, especially on Opera Mini which is designed for allowing people on lower power feature
phones to actually browse the internet and also because of the way Mini works, because
it's a proxy based browser it doesn't have the actual rendering done on the device itself.
It has that done on a server farm. And then the server farm actually sends a properly
formatted compressed version of the webpage and it's like a snapshot of the page in the
current state, similar to pdf in concept. But because of that it means that it doesn't
do so well in things like when you've got lots of constant JavaScript background
processes and Ajax updates and things like that. It doesn't deal with stuff like that
too well. But then again you know that's the point of Opera Mini is not to have a wickedly
cool, just like the desktop experience. It's to have an experience that can be used even
on pretty old, crappy, feature phones, to a reasonable degree.
>>Michael Mahemoff: And with Chrome there is no actual Chrome on mobile. It's not a
trivial problem to acutally port a browser like Chrome that has to work with all these latest features
that on the various desktop operating systems, and then to have to worry about putting that
onto mobile operating systems as well. So it is, it is progressing. There are things
like in Honeycomb SVG and in some of the device APIs that are there now so you can do webcam, or
recording from the camera. But it's slowly progressing, it's not actually the same browser.
>>Gervase Markham: But you're not actually doing too badly at least you shift your browser
for the operating system your company makes,
unlike some.
>>Jim O'Donnell: I think we actually know the answer to this one, but we'll ask it
anyway, because I think Chris just answered this.
How come we have an Opera browser on iPhone, but not Firefox?
>>Chris Mills: Ok, so we don't have Opera
Mobile on iPhone, we have Opera Mini. The reason we were allowed to sneak Opera Mini
onto the iPhone was because >>Jim O'Donnell: There's somebody's phone
interfering really badly with the audio, so. >>Chris Mills: Who's Tweeting? Stop it.
>>Jim O'Donnell: Is it possibly someone's iPad or someone's 3g modem? Thank you.
>>Chris Mills: Yeah, that's better, so the reason we were able to sneak Opera Mini onto the iPhone,
but not Opera Mobile is because, as I said before, it's a proxy-based browser, that
doesn't render stuff on the desktop. So, it doesn't duplicate the functionality of
the WebKit browser that's already on there. And that's the only reason we were allowed
to have Opera Mini on the iPhone. >>Gervase Markham: Yeah, there are a number
of restrictions on Apple's app store, for those of you who weren't here earlier. The
only way you can get apps onto the iPhone is through the Apple app store. The Apple
app store has certain restrictions on the sort of applications it will shift. Two of
the restrictions are: first of all it must not be duplicative of the existing function,
as the gentlemen was saying. The second of which is it's not allowed to download and
run code of its own because that would allow you to download and run arbitrary stuff on
Apple feel upset by that prospect and of course the web browser's entire purpose pretty much..
>>Chris Mills: Allowing you to have control of your own device or computer.
>>Gervase Markham: Well indeed, you pays your
money and you takes your choice, as I was saying earlier. So that is why if you want
to, if you think this is unreasonable, then I'm sure that steve@apple.com would be pleased
to hear your complaints.
>>Audience: I was just wondering on the Blackberry platform what's the policy with other browsers?
>>Mathew Staikos: I mean in general the browser
on Blackberry is the Blackberry browser. There are other options. You can run Opera on Blackberry
>>Chris Mills: Both? Is it just Mini or is it Mobile? I can't remember to be honest.
>>Mathew Staikos: I mean it's something that can be downloaded and put on a Blackberry.
But by default now going forward it's the WebKit Blackberry browser.
>>Audience: How high do vendors imagine version numbers going before an alternative naming
convention is adopted like with Android.
>>Gervase Markham: For a short time I thought
there was kind of like a rule of 10. When an application got to version sort of 9, it
either kind of died or it transformed to something else. See, MacOS, Netscape almost, various
things that now some, Chrome got to 10 successfully. So, it's my kind of rule of thumb has gone.
>>Chris Mills: Chrome will be way ahead of us in a few months in terms version numbers.
>>Gervase Markham: Yeah, what's Android's system? Someone?
>>Audience: [Inaudible]
>>Gervase Markham: Oh I see, right, but they
have numbers too? So Gingerbread is 2.3 and so on and so forth. I mean everyone has code
names, we have code names, we name ours after parks. As in national parks in different countries
around the world which is kind of cool. And Thunderbird name their's after beaches. But
yeah, numbers are numbers. >>Paul Rouget: Yeah. I want to reach Firefox 42.
>>Chris Mills: I think we're going to start moving in steps of 10 now.
>>Gervase Markham: Yeah we missed out on shipping
Firefox Pi, we went from 3.1.4 to 3.1.5 which is a bit of a shame.
>>Jim O'Donnell: HTML5 video can't currently stream live video, in my opinion this is one
of the real problems with it, with the exception of Apple's Safari, will WebM catch
up and finally support proper video streaming.
>>Paul Rouget: So, it's difficult, I mean
it's complex topic. Today what you can do is to have progress in download. So what you
can do is to do live streaming with WebM, it's possible today But it's not super efficient. First because
it's through http and second because it's.. So we're working on something based on http,
there's something coming. I know, I saw on your backtracker for Chrome they are working
on something, we are working on something too so to have the IP based streaming mechanism.
>>Gervase Markham: Actually, a slight quibble with the question of course HTML5 video is
codec agnostic, there are other codecs and I watch Air Mozilla every week on Ogg streaming
video. So you can do it. >>Paul Rouget: But this is not progress with download and it's not just..
So yeah, so if you want progress,
you don't want progress in the download you want adaptive streaming. And you don't want http
So right now we're not ready yet. I mean HTML5 is not ready yet. We're all working on it
Google are working on it. We're working on it.
>>Jim O'Donnell: Is there an official list or specification chart detailing what each
of the browsers do, for instance Firefox 4 can provide a WebKit for audio API as well
as Chrome which Opera can't do, whilst Chrome can provide offline storage caching.
>>Gervase Markham: Can I plug developer.mozilla.org again please?
>>Paul Rouget: So the thing is, we are planning to, we are working on something. So developer.mozilla.org
it sounds like a Mozilla website, it's a Mozilla website, yes, but we're planning to integrate
more data from other browsers. We're working with Google on it we want to have more.. exactly this,
we want to be able to understand what you can use today. Which browser and also
with things about adding some ways to work around a lack of feature for example. So it's
the plan. Already right now we are changing a bit how the pages work to always have a
big table on top of the documentation. To say so ok, you can use this here here here,
not here and stuff like that. >>Michael Mahemoff: And a couple of other resources:
html5readiness.com and caniuse.com >>Paul Rouget: Best website ever.
>>Mathew Staikos: And you can use for the Blackberry stuff, you can use the Blackberry
developer forums to get lists and answer any questions for our support for WebKit
and other features we offer on our browser. >>Chris Mills: We have the dev.opera.com which
is the site that I maintain and publish stuff on and we also have separate doc sites. So
the first one is more kind of tutorials and the second one is just dry support
reference type stuff. But we tend to start, we started pointing all the reference stuff
to all that relevant articles that covers those sort of features in more details
and in pretty much all of our tutorials we talk about which browsers support those different
things. We try to make all of our demos as cross browser as possible.
>>Jim O'Donnell: In what way is Google App Store different from this site works best
in Netscape 4 or in Internet Explorer 4, or are we just reinventing sandboxes?
>>Michael Mahemoff: A few things, the Chrome web store
is supposed to be promoting standard web apps You can put Flash apps in it if
you want, you can put Java apps, if the user's got them installed. You can do what you like.
But, the things that we're most interested in, I think, are the ones that will work on
other browsers and work outside of the web store even on Chrome. It's just that it does
actually have these extra powers, it's got the ability to do payments, it's got a few..
a new feature like background. So, you can, in that sense progressively enhance it. Maybe
those things will become standards in the future. But because it's such a new concept
it's really just out there to try them out now. But certainly there's no problem with
putting an app in that's a standard web app that's using complete web standards. There
are still plenty of those apps that are being featured as long as it fits the criteria of
being a rich web app with all the sorts of things that users are looking for.
>>Gervase Markham: So, I think, our vision on this point is a little different. We'd
like to see competing stores offering web applications rather than having one built
into the browser. We're hoping to offer software and services in support of that vision. But
I guess that would mean we wouldn't be saying Firefox goes to this particular web
store. And there's also hope that people will be able to self-publish applications.
They just put metadata on their page about their application and that might get picked
up by people who are populating web stores with applications according to their own criteria.
So I think our vision is of a broader eco system of stores as markets work, reputation of
various stores goes up and the reputations of others goes down and some stores become known for
being discerning for particular areas and so on and so forth. So yeah, so we think a sort
of open web store model is what we'd like to see.
>>Chris Mills: In terms of our add ons site. So you know our widgets page and our extensions
pages and things like that. We don't have any restrictions that say
you have to download that stuff from that store. You can publish an Opera extension
or widget pretty much anywhere, download it and install it. It's just that we recommend that people get
the stuff from that page because it's stuff that goes through and is published on that
page has had a definite decent QA procedure done on it and is guaranteed not to have anything
horrible inside it. >>Mathew Staikos: Yeah and for our platform
as well, we have obviously our own store and but there's obvious security implications
with allowing other applications on, especially a Blackberry. But we do support, you know,
general open standards and just developing sites especially for WebKit, their supporting can run on our platform.
>>Jim O'Donnell: I think we've got time for one..
Ok, oh, this is Michael's question, yes: It appears nowadays that browser manufacturers
are introducing many proprietary features, with more to come. Is it worth implementing
proprietary browser features or if you're interested in the consistent user experience
should you go more for the features which are supported across browser?
>>Gervase Markham: Well, it depends what you mean by proprietary, right. Way back in the
browser wars like, long before some of you were even born, I'm sure. You know, Netscape
and Microsoft were competing and what they would do is they would implement a feature.
They wouldn't necessarily document it as a standard or how it's quirk works or anything.
But they'd just say, here's this thing. You can do this cool thing, use our browser, it's
cooler because it does this cool thing, right. That is a mile away from the situation we
have now where we have Opera and Safari and Firefox and other people and even Microsoft
a bit collaborating together in the W3C to produce standards that everybody implements.
And browsers experiment with stuff, yeah. because that's part of the standards development
process. And we do our best to prefix it and keep it out of the way, so that when the real
standard comes along, you don't end up trying to use the real standard and breaking the
older browsers which did it a different way because they were trying something out. The
model of standards development we have now is one that's much better for the web than
the old one. And so when we implement stuff like the audio data API which no one else
has, right. We keep it out of the way, we play with it, we do cool stuff with it and
then we say to you guys, what do you guys think? And they go, well that's cool, but
actually this APIs a bit skewy and we think ok, we'll fix that and so on and so forth.
And then there's a development process and then I think you know that's so much better
for the web than the old days. >>Paul Rouget: Chrome is experimenting with
stuff, seeing if people like it. But the thing is, don't forget something. The way it works
is not the standard specification, then the browser, then the web developer. It doesn't
work in this way at all. It's like a triangle ok. So we're all working together, it's
just a mess, I know that. It's hard sometimes. Ok we have a feature like, request animation frame.
The first time I announced this feature on our blog. I said ok, it's an experiment,
play with it, don't use it in production, play with it, tell us what you think. And
we got really good feedback. And we're working on specification, we're working on implementing
this feature right. Same thing with gradients. It's the way it works, so proprietary features,
it's not that, it's just new features. Just new. And the way it works is very healthy..
I don't now, what do you think? >>Michael Mahemoff: Yes, like you say it's
messy because the real world is messy. But it's the way it has to be, it's recognition
that you can't just write a standard upfront. You have to get developers to use it and see what
they want to do with it and that's where developers, like everyone here can get involved
with that whole process as well, and feedback what you actually want to see in the APIs.
And what you'll notice is, for instance with Chrome, and I'm sure it's the same
with the other browsers, you'll actually see the names on the standards, people who
are writing the standards are the same people who are doing the code in the browsers you know
It's a tight process. They're iterating between the two.
>>Gervase Markham: To a small degree, sometimes I blame people like Paul, who comes along
here with this siren song of you know, the audio data API and everyone gets really excited.
No seriously, it's not his fault. It's like he says, it's a triangle
>>Paul Rouget: There's one thing
>>Gervase Markham: The things we talk about aren't ready for deploying on websites which have to work everywhere.
>>Paul Rouget: There's one predatory feature
that you should not use, it's plugins. Like Civilized for example. This is a propriatory
feature that you're not supposed to use. And this could be a problem for things like
open video, the features we're all working on. This is good stuff.
>>Chris Mills: I was just going to add that it's pretty much impossible for it not to
be messy given that we have to design stuff out in the open by committee, quite largely so.
It's a very difficult process and I've never actually been to any working group meetings,
but from what I hear they're just move at a glacial pace that takes a very long time.
But then there's the other approach of course where browsers just go, we'll implement this
really awesome thing and then try and shoe horn it in the spec afterwards. Mentioning no names.
But, it's a bit dubious, but then again it still produces really cool features
and helps to innovate and drive the web forward, and we all seem to sort of get there eventually
with a lot of the major features. >>Jim O'Donnell: But xml and http requests
without which we wouldn't have the web we've got now were Microsoft proprietary extensions
to their web browser. >>Gervase Markham: Yep, they're a very cool
thing with a desperately inappropriate name. No one uses it for xml and for goodness sake,
consistent capitalisation on API names for the web.
>>Jim O'Donnell: Ok, that will be our last question. I'm getting thirsty I want to go to the pub.
Oh one last question.
I forgot about this one. What's behind the little
hatches on the Chrome logo? lasers? >>Michael Mahemoff: Yes, lasers.
[Audience laughs] You'll have to speak to the Chrome UX Team for that one
>>Jim O'Donnell: Ok thank you very much to our speakers who came along today.
[Applause]
There should be another set of slides on there with the important information like where the pub is.
Doing that, somebody's won some DVDs, haven't they?
>>Sponsor: Thanks, I'll keep it short, I know everyone hates sponsor messages. But
you're going to get one. We're here from topten.co, we're a London based web app. We
started a month ago and we're building a web app all about creating and sharing lists.
So today we've been asking you guys to come and rank browsers and make your favourite
list as to what you think are the top ten browsers out there. And thank's to everyone
that's done that. We can reveal the results to you now. So in tenth position
was Flock, in ninth position was Midori in eighth position Lunar Scape, in seven Maxthom,
in sixth position Camino, in fifth position IE9, in forth Opera, in three Safari, they're
not here today, boo. And number two Firefox and proving that lasers do win it's Chrome
at number one. So, thank you everyone.
[Applause]
And we also have a prize for everyone that took part.
So one person has won the top ten sci fi dvds of all time, and that is Louis Ramy.
So Louis yeah, do you want to come and grab that, well done.
[Applause]
>>Jim O'Donnell: Oh yeah, oh nobody won it, nobody won the bingo. Did anyone get more
than 3 in a row, 4 in a row? Can the panel just start shouting out buzz words?
[General chatter]
>>Jim O'Donnell: Ok, thank you very much to our speakers, Terence Eden, Chris Mills, Michael Mahemoff, Paul Roget..
[Applause]
And again it's a pity Martin Beeby couldn't be here and hope that his wife is recovering from her accident yesterday
He has been answering questions on Twitter, so if you have a question about IE9, and you tag it
No, no, she's fine after the accident I think, just shaken up
Are we going to try and get him for a talk?
There you go, he'll record his talk and you can get it online
Thank you very much to our sponsors +Lion, Top10, who ran the competition, 9 Web
Web Directions, who provided the app media ticket, UBelly, Campaign Monitor and Squiz
and, I'm old and my glasses don't work, Incubator, I can just barely make that out
Incubator who very kindly streamed the video today
Right, important information. We're going to The Pilot