Mobilism 2011 Mobile Browser Panel

A panel I moderated at the Mobilism conference in Amsterdam featuring representatives from Nokia, Opera and RIM.

Jeremy Keith: Okay and thank you for that lovely introduction. Hello everybody. Is everybody having a good time?

That’s nice. That’s good to hear. I’m having a great time, I think today’s been pretty excellent. Great mix of talks we’ve had today, and this is going to be the last event of the day before beer, which is very important, so here’s how it’s going to work. We’ve got a kind of a …this is all going to be pretty unstructured. Even how long this is gonna go on is kind of unstructured. We’re beginning now and we’re going on ‘til at least five, but it could be five thirty; who knows? It could even be longer. But any time from five we might finish up if they’re really dull and boring; it won’t be my fault, right, if they’re really dull and boring? We’ll finish up early and we’ll all go for beers at five, but it could continue on. I’m only kidding. They’ll be wonderful.

So we’re going to have some questions for the people who make browsers, we’ve been putting the call out for a few days now, PPK on Twitter and me and my blog saying “if you have any questions you’d like to put to mobile browser makers, let’s hear them”, so I’ve had some responses on my blog, most of them people commenting “first!” but after a few of those there were some genuine questions, so I’ll get round to asking some of those, the good questions.

Some people have been asking questions on Twitter; thank you very much, I’ve been checking the #mobilism hashtag throughout the day, and there’s been one or two questions in there, along with nice comments about all the talks which was great to see, and the occasional comment complaining about whether the chairs are comfortable or whether the food is any good, right. It wouldn’t be a conference in the Netherlands if it didn’t have people moaning about something or another. This is the language that gave us the word mierenneuker; that makes sense that Twitter is the perfect medium for this.

If you haven’t submitted a question by Twitter, too late. You had your chance. I’m not going to be looking at Twitter while I’m supposed to be talking to these guys. However, you will get a chance to ask a question. As this progresses, I’ll open it up to the audience, so be thinking of questions. If, in the middle of this, you just can’t take it and you have to scream out your question straight away, do it man! Just do it! Like, stand up, wait for somebody to bring you a microphone and then just scream out your question.

Anyway, so this is the way it’s going to work. We’ll have some pre-prepared questions to begin with. Probably start with some of the more technical stuff—and the people want to know about technical issues—and we’ll broaden it into maybe more philosophical debate about the mobile web and the future and browsers and the meaning of life, and then we involve you guys, so it could go anywhere. Who knows? Who knows where this will go? So let me introduce the people I have with me here today.

To my left, I have Eli Fidler from Toronto in Canada. He works at RIM, which sounds rude, but isn’t. It’s Research In Motion, and you’ll know them for the Blackberry. Over there we’ve got Andrea, Andrea Trasatti, and I should be rolling the Rs as I pronounce both his first and last name, but I’m incapable of rolling my Rs. I apologise, Andrea…

Andrea Trasatti: Practised …we practised rolling them yesterday.

Jeremy: I’m sorry, I just can’t do it. Stage fright. Andrea is from Nokia, and then we’ve got Andreas Bovens, who is from Belgium but now based up in Norway, because he works for Opera. So basically representatives from RIM, Nokia and Opera.

And that’s it as regards representatives. Hmmm …hmmm, “how strange?” you might say. “I can think of a few other mobile browser manufacturers that should be on a panel about mobile browsers.” Indeed. And PPK has been doing its utmost to get representatives from other browser makers here and …no.

I mean Apple; forget about it, right? Apple never send anybody to any of these kind of conferences. Steve Jobs is allowed to speak, Phil Schiller, that’s pretty much it. No one else at Apple is ever allowed to speak at an event, so there’s no chance of having a representative from Apple here, which is a shame, and PPK tried to get someone from Google to come along, and there isn’t anyone specifically involved with dev outreach for Google Webkit; for Android Google Webkit. There is for Android in general, but not specifically for Webkit, and that’s a shame. It has to be said, the timing is kind of awkward because Google IO is going on and all that. And PPK reached out to lots of other people too, but this is it.

These are the people who were brave enough to step up to the plate, so I salute them for their bravery, and I have to begin with a disclaimer, and this is …you know when you put the DVD in the DVD player? You remember DVDs? And you get the disclaimer at the start saying that the views and the opinions expressed are purely whatever not the opinions of the …you know, the usual crap where they cover their ass about what they’re about to say in the commentary. Imagine that’s here, right, I’m putting that disclaimer up. The opinions expressed here are total bollocks just shooting the breeze; they do not represent a company’s opinion. So don’t be trying to hold Nokia to a certain standpoint just because of something Andrea says. And don’t think that Opera are taking a certain position on something just because of something Andreas says, okay? These are just opinions. I’m also saying this as much for your benefit as for the panellists here so that they know they’re in a safe environment, okay? Feel free. You can relax, all right? Nobody’s watching, right? Ignore that camera up there. Nobody’s watching.

Okay, so that’s the ground rules I’ve set. So what I wanted to do was, I was going to begin with a targeted questions for each of the panellists, specific to their browser, then we’ll get into the more specific technical questions for everyone.

So let’s see, who will I begin with? Andrea. And this is a question that PPK put together. He wants to know exactly which browsers does Nokia maintain, and for which platforms? How long will they continue to exist? PPK tried to do a count, let’s see we’ve got like Symbian Webkit; S40 Webkit which is like Symbian, MicroB for Meego, Ovi for S40, and soon, Internet Explorer mobile. How many are there?

Andrea: I stopped counting after three, but right now in development we have two, so there’s Webkit for Symbian and Ovi Browser for Series 40. That’s all we have in development.

Jeremy: So that’s what you plan to maintain?

Andrea: Yes. So …the Webkit, for example, for Series 40 is not currently in development, so that’s end of life. There used to be actually a WAP browser in Series 40. That is not going to be maintained any further. Of course it is still coming and devices that are being released now…

Jeremy: What does end of life mean for …like, you’re not going to answer the phone calls when people have…

Andrea: We never answer phone calls anyway, but …no. It means that unless there is some major security issue, then that’s whatever is in the browser and that’s the amount of capabilities that you get. On the other hand, for Symbian for example, we keep maintaining the Webkit. We announced Symbian that is coming in the next few months, and you can already see it on the C7 stand, the one that is on sale in the US, that one is already pretty much the 7:3 browser that is coming to Symbian across the board, so on all Symbian 3 devices and also non-touch devices and previous devices, and the Ovi browser for the Series 40 which is a proxy browser.

Jeremy: And this whole Microsoft Nokia thing, you’re just ignoring that? Putting your fingers in your ears, going la-la-la?

Andrea: Well you asked me, PPK said, which ones Nokia is maintaining.

Jeremy: I see.

Andrea: So IE is a Windows phone thing and Microsoft maintains it. So far the plan is when the Windows phone comes it will run whatever browser is on that Windows phone.

Jeremy: Okay. So Nokia’s still Nokia: Microsoft’s still Microsoft?

Andrea: For the software platform, yes. So …mix Nokia …Microsoft talked about their I7, the IE9 coming in their next release which is I think Mango, so…

Jeremy: But if people have questions on that, you’re not the guy to talk to?

Andrea: No. Correct.

Jeremy: Okay. Good that that is cleared up. Speaking of maintaining end of life products, Eli …what advice do you have for people trying to deal with the old, the pre-Webkit Blackberry browser?

Eli Fidler: It’s a very good question, and we get it a lot from people, and I guess the first thing to start with is that Blackberry 6 and onwards is Webkit; that was the first Blackberry OS version that has Webkit, the Torch was the first device out, and in most respects, it is compatible with Webkit on all of the other mobile platforms, there’s obvious subtle differences between what you get on IOS and what you get on Android and what you get on Nokia’s phones, but Webkit is Webkit to some extent. Before that, we had the 5-0 browser, and the 5-0 browser is kind of a hybrid. It’s …it’s not Webkit. It does have some basic HTML5 and CSS3 support, but certainly not to the level that people who have been writing desktop websites expect, and supporting it can be a challenge sometimes

Jeremy: You didn’t mention JavaScript there…

Eli: Actually has decent JavaScript support. Performance is not amazing …so I don’t think that people are really going to be doing a lot of JavaScript based animations and highly visual things on the 5-0 browser but basic support for things does work better than a lot of people would expect and we are maintaining support backwards to 5-0 for our WebWorks platform which is our device APIs and widgets framework that I’m sure will come up in future questions. Before that, so 4-7, 4-6 and earlier the browsers were frankly not that great, and I think that everyone kind of knows that. Outside of the company there’s a lot of expertise on people who are being forced to support these platforms, probably more than I know. I joined about the 6-0 time so I don’t have a lot of personal experience there but there are some framework out there like JQuery Mobile that’ll be doing some of this work for you. So that’s definitely something to look into. All that being said, the market share of 4-6 and 4-7 and earlier is dropping quickly, and the market share of 5-0 and 6-0 together has well surpassed 4-6 and earlier, and that gap will continue to widen. The biggest use right now for the earlier releases is corporate devices in North America and that’s still an important market to target, but most of the people who are doing that are very specifically focused on those platforms.

Jeremy: Okay. Good answer. Although when you said Webkit is Webkit, I could pretty much see PPK kinda …tense up

Eli: I know

Jeremy: Because I believe you have strong opinions on that viewpoint.

Eli: I hope everyone’s read PPK’s article on how Webkit is not Webkit!.

Jeremy: It is well worth reading. So Andreas, for you, Opera, in the mobile space has two products and I can never keep straight in my head which is which. What’s the difference and which is which between Opera Mobile and Opera Mini?

Andreas Bovens: Okay. So to explain it simply, inside the Opera browser there is core rendering engine; we call it core internally. To the outside world we call it Presto. It sounds a bit fancier and faster even. And so what we try to do is in all the deliveries we do and all the products we make, we ship the same …sorry, the same Presto rendering engine. This means that in Opera Mobile, you get the full rendering engine; the same rendering engine you get on desktop, on the desktop browser is also available on the phone. And so the Opera Mobile browser is currently at version number 11, and it’s available on Androids and on Series 60 …for Series 60 phones, so we’re not supporting Windows Mobile 6.5 any more, and I’m not sure yet what will happen with Windows Phone 7, so that’s a little bit up in the air still. So that is Windows Mobile, so you’ve got the full …the full browser, the full rendering engine on the phone. In the case of Opera Mini, there the rendering engine lives on the server. That sounds a little bit strange but what happens there is it’s a proxy browser, which means that whenever you load a page on Opera Mini, which is sort of a thin client on the phone, it quickly connects to a server, it says, hey I want to load this web page, the server connects to the site, fetches the web page from the site, renders it on the server and then sends back a strongly compressed version to the phone. That happens with …that sounds pretty complicated, but it happens really fast, actually often faster than if you would render everything on the phone, so that’s …that’s Opera Mini, and so we see that a lot of people that have feature phones are interested in this because their phones are not capable of running a full a full rendering engine basically; their devices are too slow, too outdated or there are other issues, so for them Opera Mini is perfect because it allows them to get a decent web experience without having a a smart phone or the latest model of phone.

Jeremy: So just in terms of numbers, which gets more use?

Andreas: Opera Mini gets more use because there’s much more feature phone users out there than smart phone users, so I believe we surpassed in March we had 102 million monthly users on Opera Mini, and they viewed if I’m correct 60 billion pages within that month, which amounts to 8.8 petabytes of data that was compressed through our servers and then, well you keep about 80% or so of the data traffic, so it …it’s interesting for users also because while they have to pay less in they have to pay less per megabyte of course because they get less data, and which is especially cool when you’re roaming, because you have to pay less, so it speeds up things significantly.

Jeremy: Well, I mean, as we saw in the talks earlier today what is a feature phone; what is a smart phone; the lines …I would hope to see those numbers drop off.

Andreas: Of Opera Mini?

Jeremy: Yes, and more and more people using say Opera Mobile.

Andreas: So …yeah, so there is …so we see people increasingly also using Opera Mobile. I believe right now we are about 50 million people use Opera Mobile monthly, so it’s increasing there as well. However, what you do see, and we were also surprised a little bit, so you would think Opera Mini is only for a feature phone and once you have an advanced phone you go to a full rendering engine; it’s more powerful, and that’s true, I personally prefer it as well, but still in certain scenarios, for instance when you have bad coverage, it was mentioned a couple of times today, then you actually see that hey, Opera Mini is …is just useful there as well, and so we see that even on high end phones like on Android phones, we see that there are a lot of Mini users out there, even although they have the built-in Webkit browser or Opera Mobile to their disposal; they still also use Opera Mini aside, or to combined, or exclusively, yeah …so..

Jeremy: Andrea: does Nokia have a similar kind of service …Ovi…

Andrea: Yeah, so the Ovi browser that I mentioned earlier is what they call distributor user agent, so it works pretty much the same way as Opera Mini where there is a proxy on the server side for us that fetches the page, computes, does everything compression, and then delivers to the Client, and the reasons are petty much the same where small screen, low bandwidth, reduced cost and reduced CPO.

Jeremy: So would you agree that it’s not going away any time soon, that’s going to be a long term trend?

Andrea: Well, depends what you mean by long term, but definitely right now there is interest, a lot of interest in this type of technology, mostly for data usage and accessibility basically on remote servers, so it makes it easier.

Jeremy: Okay, well let’s get into more sort of how devices deal with …with the web pages out there on the web, and one of the issues, of course a lot of web pages aren’t made for small screen devices, so you introduce zooming, but you could zoom in different ways. Some browsers would choose to literally re-flow the text maintain what’s on the screen; others would zoom so that the text is now going off the screen beyond the viewport, so if each of you could tell me what your particular browser does and why you went for that solution. Eli?

Eli: Okay, so our zooming is …different on some of our different platforms, but if we look at the 6-0 Webkit browser that we’ve released, right now it does re-flow text when you do a double tap zoom, so we call that a block zoom, and by default it will change the line breaks within a block bubble element that has text in it that they fit on the screen if it fits within a reasonable set of parameters, if it …you don’t have to make the text too big or too small to do that, to make the line breaks too ridiculous. That feature can be turned off, but we’ve found that people don’t want to scroll horizontally as a general rule, so that’s why we did it. It’s a slightly different implementation than what some of the other platforms are doing, particularly IOS and Android, but achieves basically the same result that when you …indicate that you want to focus on a block of text by double-tapping on it, we make it so you don’t have to scroll horizontally. That was the problem statement that we tried to solve. It has historically been done by much more drastic measures on our 5-0 browser we had something called Column Mode, which literally took all block bubble elements of the page and oriented them vertically, so the entire page does not require horizontal scrolling; as you can imaging that makes web developers crazy because it totally breaks your page layout, and we’ve tried to break your page layout as little as possible. On our larger screen devices like on Playbook, we don’t actually re-flow text at all because we haven’t found it to be particularly necessary in talking to users on the larger screen.

Jeremy: Fair enough. And Andreas. Opera, what do you do on Opera Mobile?

Andreas: Yes, so I think …so this goes way back, there was mention of this …what was it called …Column Mode or something like that…

Jeremy: Yep

Andreas: So we had something similar which we called Small Screen Rendering. SSR. Nobody knows what it stands for whenever we …we have it in the US, so now it’s called I believe Mobile View. It’s still there in the options in Opera Mobile, so that also re-flows everything in one long column and it sort of alters the page. Web developers don’t like this very much and users are often confused, although we still see a lot of people using it, interestingly enough, so that is one way of dealing with it. The other way where we deal with it so the browser sits with this Mobile View or SSR mode turned off by default, so you get an experience where you get the full overview of the web page and AU pinch to zoom, and then wherever you are, so that that block of text gets actually re-flowed and sort of fit nicely within the available screen width. We did a little alteration before, so let me go back one step, I believe in Opera Mobile 10 we did that before, so we didn’t have pinch to zoom; we only had two level zoom, so you were zoomed out or zoomed in, and then we would already pre-calculate, okay, this is how big, how wide the text block is going to be when you double tap, and then people who are not web developers and users were not very happy because you had these wide, wide blocks of white space randomly over the web page and they thought, oh my blog or my website is broken, and we always had to explain well no, it’s just because of two zoom levels, otherwise you would have to scroll left and right; that would be really annoying, and then we experimented a bit with only doing it on tap or only when …sorry, only when …only on tap and not when pinching, and then we saw, so that was in 10.1 data which came out in November, and then we thought no, this is way too complicated; nobody understands it any more, and then we said okay, let’s just give the user the option, it’s on by default, so you pinch everything is re-flowed, and if you turn it off, it doesn’t re-flow and you can …you can scroll left and right if you want or just not zoom in too much, but so …yeah.

Jeremy: I know you could actually use the small screen rendering even on the desktop browser?

Andreas: Yes, that’s correct.

Jeremy: Is that still in there?

Andreas: No, it’s not in there any more. So also because we …it sort of …I believe it was listed as something like, well that you could give the impression that it was like a mobile emulator or a mobile view …view mode, which it wasn’t really because we didn’t ship it any more by default and sort of people would be confused to think like, oh …that’s how Opera renders mobile pages …ha ha ha …so that’s why we didn’t…

Jeremy: Don’t use a desktop browser for testing mobile websites.

Andreas: No exactly

Jeremy: Okay, fair enough. Andrea. Re-flow or zoom?

Andrea: Good question! Nokia has a large variety of devices so on the low end, if we’re talking about the old browser that was re-flow because of the screen, and the same happens in Ovi browser where the default behaviour is to re-flow, but actually as much as Opera, you can just go into your settings and change it, and you will get an overview and then you can zoom in, and the reason there as much as the Symbian devices that are not touch, is mostly usability, so it is not very easy to point and zoom in or double-tap or zooming, pinch and zooming is so much easier, and with old devices with no-touch wasn’t that easy, and so for consistency, even on touch devices right now, we zoom automatically onto what the browser thinks is the main content of the page, and we try to re-flow it, let’s say…

Jeremy: That does bring up an interesting point, that basically you were trying to avoid actual zooming when people were trying to navigate with keys or a joy-stick or whatever, but now that there are more and more touch devices, is that as much of an issue, I mean maybe you’ve had to re-think it?

Andrea: Well right now, Nokia still is selling both, so even tough the move is towards touch only, there are still devices, and even the browser 7-3 that is coming with Symbian Anna will actually …is actually being back-ported to the non-touch devices so for consistency, we’re now going with mostly re-flow. Now if you have a very big image, you will still have to scroll left and right, but we try to avoid that as much as possible.

Jeremy: Fair enough. Fair enough. Do you have any idea of numbers of touch-screen devices, non touch-screen devices that Nokia’s shipping, planning to ship …it’s okay if you don’t, that’s fine.

Andrea: I’m trying to think, because there were some …we are talking about shipping 150 million Symbian 3, and all Symbian 3 are touch. But that is going to be between the end of last year and next year.

Jeremy: Okay, so we’ll see. All right. Enough pussy-footing around. Something I have to bring up, because it’s come up in the talks today, and I have the chance to talk to browser makers, have to bring this up. Device APIs, right. We web developers, we want access. Grant us access! Why don’t we get …native apps get to use stuff, native apps get access to the contact details, address book, photo library, the camera …the camera! All the stuff and yeah it’s coming, it’s coming, it’s coming …why is it so hard? What’s the problem here? Andrea?

Andrea: We had device APIs in WRT for years now. The only point is that it was not standardised so WRT came before even the W3Z started doing the …widget packaging and distribution, so at the time we were ahead of the curve and then we never standardised towards one

Jeremy: So how does it stand now, making a native app for…

Andrea: Yeah. WRT is a package that you develop and it’s web technology, so it’s HTML and JavaScript.

Jeremy: So whether making a website or making a native app, you’re saying I have the same access to…

Andrea: No. That’s the thing. So in WRT you do. In the web browser you basically have access…

Jeremy: It’s the web browser I’m interested in.

Andrea: Yes. I know. But I can even bring one more item to the discussion that was mentioned by Brian Leroux earlier which was Qt Mobility and through Qt, you can use Qt Webkit and you have access to a bunch of API sensors, a number of things. The point is that you still have to built a shell in Qt, but then you …once you fire the Qt Webkit, you have actually access to a lot of device APIs.

Jeremy: I can’t just visit the URL and that URL have access@

Andrea: Not right now, no.

Jeremy: Why not?

Andrea: Er ….because we haven’t done it yet!

Jeremy: Yet. Yet. Okay, that’s good. Yet is the word I wanted to hear there. Andreas? Is it hard?

Andreas: Yeah, it is hard I think. At Opera we’ve been playing around with this for quite some years, mostly in the context of widgets, but still, you can’t load this in the browser in the URL, so then we talk a bit about that. I think the dual location API is a good example of something that came to W3C was agreed upon through, well a process the W3C process, they always take time, but this one went fairly smooth I think and then implementations followed in desktop. I think two years ago there was not even a single browser with this in and now we have it all on desktop and mobile and everywhere, so that’s …that’s something that went really well. And … but it’s not so easy to do it for all the APIs, so to give one example, a couple of …let me see …two months ago or so, or maybe even less, a couple of weeks ago, we created a special built of Opera Mobile with support for the device element

Jeremy: That’s right

Andreas: So we released …we released a post about this and so we said, look, we’re going to do this and we think this is very interesting, the device element will allow you to sort of hook into the camera on the phone, and …I never really know what it is, the front face, the one that points that way, not to your own face, and so you could …you could play around with it and script it and do all kinds of stuff, and so we said, well we’re about to release this and the moment we announced this on our core blog, the specification changed. Literally the same day. Probably as a bit of a reaction to …it’s a lot of politics in these working groups and so on. There’s always a lot of things…

Jeremy: No …No …Politics? It’s W3C! No…

Andreas: So anyway …so then we …but that’s a good example of, well you want to ship something but there is stuff so much changing and very often there’s a significant investment. You have to decide in advance, okay are we going to put a couple of people, a couple of man months of work on this, knowing that it will change and so we, in this case we knew it. Luckily we were well prepared, because one week later, we actually shipped the version public with the new get user media API implemented, and so that was there. It also had device orientation events and stuff like that, so we are experimenting with this, but if you try to build, it’s quite interesting, you can play around with it. It’s still a bit unstable; it’s a little bit crashy; the specification is still changing. So is it ready for deployment in the real browser? Maybe yes, it still needs some work. What do you do for instance with privacy …do you prompt the user every time …do you want to access this application or this website wants to access the camera, are you fine with it? It’s a whole other different matter from oh, this application wants to access your camera because you get a sort of …you have this point of control in between which you don’t have with websites…

Jeremy: You install the application?

Andreas: You install the application so…

Jeremy: But you just visited a website

Andreas: Exactly, so you’ve already sort of given consent or so those kind of things are all …well more complicated I think than with native web apps, and that’s why they take more time, and that’s why browser vendors are very interested. We love this kind of stuff. But at the same time we also have to see, okay, what takes well what do we do first? There’s so many things in the list, and…

Jeremy: Yeah …actually I was kind of disappointed that the device element got removed and now it’s pure JavaScript API because I genuinely preferred the clarity of solutions, but you do bring up the whole point of if you try and innovate too far ahead and you …you end up making something that’s proprietary. Unintentionally, because you’re going ahead at a standard, but then you’re waiting for a standard like W3C to finish something, you’re waiting for years, so it does seem like there’s this dance between implementation and specification, and that’s not just with mobile stuff. Obviously that’s browsers in general. Yeah, so Eli, device APIs. Now you have …you got the hardware as well as the software, right? You’ve kind of got that…

Eli: Yes

Jeremy: You’ve got that tie-in. That’s gotta help.

Eli: It definitely enables us to do things, but we’re in a very similar situation to what these two guys have already talked about, where we do have a widget framework, for web technology based apps, WebWorks that provides you access to almost 100% of the same issues…

Jeremy: Sure, but we’re interested in what happens when they go to URL in the browser.

Eli: So most of our APIs that are accessible from an arbitrary website in the browser, we get from upstream Webkit, so we work very closely with the upstream Webkit project, and that means that things that go into the upstream codebase eventually will make their way into our browser as a general rule. It’s not true for absolutely everything. Which is why geo-location and that sort of thing is very well supported. None of the other mobile Webkit browser makers other than the Qt browser are upstream, so in particular the mobile Safari Webkit and the Android Webkit are off in their own worlds, very far diverged, which is why it’s hard to come to agreement on these sort of things, so we are participating in the W3C to get some standardisations on some of these things. A big restriction for us is that once we ship something, we are very stuck with it forever and…

Jeremy: So you want to get it right

Eli: It’s very, very hard for us to say the kind of things that Opera can; hey, we’re going to put up a dead built and have people try it and see what’s going to happen, because we have to support it forever.

So making choices, those initial choices, you may rue the day further down the line. Speaking of making choices you may rue, video codex. Which ones to support; which ones not to support. Why? Why not? Technical reasons? Political reasons? So on a Nokia browser what …if I have a video element for example, what’s going to play?

Andrea: So the Nokia browser doesn’t play anything embedded in HTML5 there’s no support for that but anyway, usually what is supported so you can download it and play it offline or you can play it in a Qt application. It’s H264 is usually…

Jeremy: So you are paying the piper? You are paying the…

Andrea: Not only that, you are also paying Adobe so you can also play Flash like video. So we’re paying everyone, except the free one that is Google.

Jeremy: But you’re not going to support that?

Andrea: For now, no. So it’s not in the devices right now.

Jeremy: So you like to pay money?

Andrea: Yeah …yeah …but then we charge it on the customers.

Jeremy: Okay, fine. So you think if it’s free, it can’t be any good? That’s basically your philosophy?

Andrea: No, no. At this stage of course there’s for example a chip reasoning where chips have hardware acceleration for example for H264…

Jeremy: Is that mainly the reason then? Because of hardware acceleration?

Andrea: Well, right now it is one of the reasons, yes, and the other is that we’ve tested and used it three years and we know how it works and everything. WebM for example is still the new technology and hasn’t been tested enough for us…

Jeremy: So it’s like a wait and see attitude with WebM?

Andrea: Yes. It could come. If it is a better standard I don’t see why we wouldn’t. But at this stage, H264 is the kinda safe horse.

Jeremy: You might want to work on that video element support as well, you want to get that in there. That’d be good.

Andrea: But you can try it in a Qt application.

Jeremy: I’m interested in going to URLs in a web browser. I don’t know how often …

Andrea: I’ll send you a line of code of…

Jeremy: I know you all love your little wrap this stuff up in and standalone thingies…

Andrea: You can sell it on the App store.

Jeremy: Monetise. Right. No; I want to go to something in a URL, in a web browser, and have it just work. Am I asking too much, apparently?

So video codecs. Obviously, okay, you’re in an interesting position because you, as well as making this mobile browser, Opera Mobile, you also make desktop browser. I take it it’s the same …the same factors, factor into what you do and don’t support?

Andreas: Mmm …yes …yes and no. So there’s a couple of differences. On this stuff we have Ogg support, and WebM support. On mobile there’s no Ogg support. We do support WebM from Androids 2.3 and onwards, so Opera Mobile running on Android 2.3 will be able to launch or play WebM video in the native player, so we hand it off when there’s a video element, with a WebM URL, or a source link from it, you click on it and then it will launch the native video player that’s available on the device. So you don’t have to download it first. It starts playing right away. Or there is …so in the other Android devices but also in all Android phones basically, we also support H264 because it’s already present on the system, so we just the same there, we hand it off to the system and …so

Jeremy: So the system’s doing all the work?

Andreas: The system’s doing all the work basically. So if you want to run …so in-line video support is not …so inside the page is not yet …we don’t have that yet, so there’s performance issues mostly. It’s …you mentioned also how it works acceleration. For instance WebM doesn’t have this yet. It might be coming. I’m not entirely sure how close that is, so there’s an issue there. So we don’t have that running yet. So probably if you really need in-line video on your mobile application, your only choice is probably Flash for now which runs, but, well, it’s Flash.

Jeremy: Okay, that’s a shame. Can I watch a video on my Blackberry?

Eli: So …in our in market hand-helds right now on 6-0, we do not have support for the HTML5 video element. On Playbook which just came out in the last month, we do. It supports H264

Jeremy: So you’re paying the piper as well?

Eli: Yes. And similar to Opera, I guess, from my perspective, we hand it off to the system. So Qnix has this very nice video playback API and the codecs all come from there.

Jeremy: So you really are making those decisions about which code …it’s the system…

Eli: As the browser team, we are not involved in that decision.

Jeremy: Okay, fair enough

Eli: But embedded video works very well in the Playbook browser, and will be coming into the Blackberry 7.

Jeremy: So still on sort of technical details, something else that web developers might occasionally mention that they’re interested in …a little CSS declaration …position fixed! Now I mentioned that this is happening at the same time as GoogleIO and I think the Android guys were quite excited to announce that they now do support position fixed, so has the bar been raised do you need to get on that?

Eli: Blackberry 6 again in market 1, we support position fixed the same way that Android used to, which is when you scroll, the position fixed scrolls with the page and then jumps back afterwards, which is …not what anybody wants, but in the Playbook browser, we have true fixed position support. If you put position fixed on something, it will be fixed for real, and the page can scroll underneath it and be fast and that will be coming to Blackberry 7.

Jeremy: Okay. Good. Glad to hear it.

Eli: And I still haven’t seen it running on Android, so as far as I know, we are the only mobile browser in market that does support that.

Jeremy: Oh yes, a pissing competition. Just what we want. Andrea?

Andreas: Yep. In Opera we do the same, so we …it’s sort of fixed as in, when you scroll, it’s still stuck to the page and then when you stop scrolling, it jumps back into place, indeed not particularly smooth.

Jeremy: But is it really that hard. I mean, I don’t make a browser…

Andreas: It is …it is very hard, so to be honest I’m also not …so it’s fairly complicated because it relates to …so …well, how to say this simply. Basically if you make a mobile browser, there’s a lot of hex involved in sort of getting or …a lot of tricks involved let me say it like that, to make this …to the view port stuff and the zooming and all that, and so you have to calculate a whole lot of things and there’s a number of layers, so for instance what do you do when …so if you have a web page with a view port metatag, and then what is position fixed? Well there’s fairly obvious what should happen, like you always want this bar to stay at the top regardless if you scroll the page, but if you also zoom at the same time and then what should happen then, and what if a whole say sidebar with a lot of elements is fixed and you …so there’s a lot of calculations to be done there, and it seems …so in our older infrastructure, in our older way of rendering web pages on mobile, which was pre-Opera Mobile 11, that would have been basically impossible to do, to support position fixed. However, now with Opera Mobile 11 we have if you pan, it goes very fast and so that’s because we have a new way of putting the layout and everything…

Jeremy: Calculating it?

Andreas: Calculating it. And so now they’re thinking …so we haven’t done it yet, but they …I was talking to developers a couple of weeks ago, and then they said, well there is a possibility we can actually get this to work properly…

Jeremy: You think you might beat these guys to the punch? You might get it out in time?

Andreas: I’m not sure yet, but we’ll definitely try. So it’s …I don’t think it’s that far away, I’m not going to make promises but, yeah, it seems to be less impossible than it was before. So that’s very vague, isn’t it? So anyway.

Jeremy: Andrea, you got position fixed for us?

Andrea: In 7-3, so the one that is coming soon, yes. So it mostly works but I would agree within there sometimes you might have some…

Jeremy: There’s a lot of things I’m clearly not thinking of. It’s not as simple as it sounds.

Andrea: Yeah. You might get it wrong if you zoom…

Eli: I could maybe give you just a little bit more detail on that. So right now there’s the big question about what to do with zooming and position fixed together; should you zoom the fixed position element or should you not; if you zoom the fixed position element and it’s stuck to the side of the screen, eventually it’s the whole screen, then you can’t get any content underneath it.

Jeremy: It sounds a lot like Frames all the complicated stuff that came along with Frames, there’s more to it than…

Eli: I think that there will have to be some evolution in the standard to decide what to do when you combine those two things. Right now, mobile browser zooming is kind of just a layer on top of existing web standards, so everyone does something a little bit different with text re-flow and and…

Jeremy: I as an author can’t specify how I want the mobile browser to zoom.

Eli: So I’m trying to actually do some prototypes right now on some interesting things that we could do with fixed positioning and zooming together, but we don’t have anything done yet. We also …some of the things that we tried to do with fixed positioning on the existing browser, where it does zoom by the way, are very complicated because of the layout, so there are some limitations where you do have to fall back to the jumping behaviour that nobody likes but eventually does get you something fixed, but some of the partners that we’re working with on the frameworks, like jQuery, have started…

Jeremy: I’m going to stop you there, because it’s getting boring!

Eli: Okay.

Jeremy: I wanted to talk about calculating. Calculating, because, come on, time’s pressing; we don’t want to spend all the time on these technical things.

Eli: I’m sorry…

Jeremy: One more little quick technical question is when you’re calculating how big to make a page to fit on a mobile browser, I as an author can specify, in the meta element I can use the viewport width I can say device width whatever. Now for Opera, you also support a way for me to do that in the CSS, which is the @viewport …it’s not a selector, declaration block, whatever. Why? What’s wrong with the meta element?

Andreas: So …we felt strongly that …well the meta element was sort of a bit of a …well it’s a little bit of a hack to override specific browser behaviour. Originally it was defined by the iPhone; it came to other browsers as well. We also implemented it, played around with it a bit and then we felt, well this is actually more something that belongs in CSS because you’re controlling the layout, the width or …well, in a way…

Jeremy: So it’s like you’re crossing the streams by having this presentational instruction…

Andreas: …element inside the mark-up, yeah. So that’s what we were feeling, so we tried to work a lot on our viewport implementation, and he made, well, a proposal to the CSS working group called …I’m not sure any more what it’s called …device …sorry?

Audience member: Device Adaptation.

Andreas: Yeah, Device Adaptation, thank you. Device Adaptation and so that defines it at viewport rule where you put basically …it’s sort of a mapping of all the attribute …all the properties in the viewport metatag, but you convert them to CSS. So not all of it is the same, so a lot of them look similar; you have certain things that are different, like initial scale for instance becomes zoom, because I believe IE has a sort of zoom…

Jeremy: It does indeed

Andreas: Yeah, so we tried to see there what makes sense. I’m not sure yet if that’ll be the final naming but for now, so we implemented it like that.

JKIt makes sense if you put it like that, that it is …it’s presentational, so it doesn’t belong in the mark-up there.

Andreas: So the interesting thing is Patrick Lauke, one of the guys in my team, he’s been experimenting with using, well applying viewport conditionally dependent on media queries, so you can change the viewport dynamically depending on the size of the screen.

Jeremy: Because otherwise you’d have to use JavaScript to edit the meta element…

Andreas: Yeah, exactly, so…

Andreas: ….detection. I mean you must use server side detection, otherwise to set the right viewport size which can be a problem, and that’s also why viewport is kind of developing into a little bit of a monster with DPI and scalability and initial scale…

Jeremy: Do I detect that you’re wary of implementing it, perhaps?

Andrea: No, you’re wrong, because we have it in the C7 it’s already implemented, it’s at market in the US and it’s coming to 7-3, but we are facing pretty much the same problems where there are developers that design websites for the iPhone or for some specific Android devices supporting a certain width, and then it doesn’t work. We’ve seen funny pages where they define the viewport, they define you cannot scale it, even though without defining th

Have you published a response to this? :