Questions for Mobilism

I’m going to Amsterdam next week for the Mobilism conference. Bizarrely, there are still tickets available. I say “bizarrely” because it’s such an excellent event—it’s like the European equivalent of the Breaking Development conference.

Don’t worry; I won’t be giving a presentation. I’ll leave that to experts like Remy, Lyza, Brad, and Jake. But I will be getting up on the stage. I’m going to moderating not one, but two, panels. I think it’s going to be fun.

We’ll be reprising the Mobile Browser panel from last year. Once again, there will be representatives from Opera, RIM, and Nokia. This year Google is also joining the line-up. As usual, Apple will not be present.

The new addition to the schedule is a panel on device and network APIs. I will be playing the part of a curious but clueless web developer interested in such things …because, well, that’s what I am.

I plan to open up both panels to questions from the audience. While I don’t quite fall into Cennydd’s camp, it would be great if more people would read this article on how to ask a question:

You have not been invited to give a speech. Before you stand up, boil your thoughts down to a single point. Then ask yourself if this point is something you want to assert or something you want to find out. There are exceptions, but if your point falls into the category of assertion, you should probably remain seated.

But I’m not planning to leave the questions entirely to the people in the room. Just as I did last year, I’d like to ask you to tell me what topics are burning in your mind when it comes to mobile browsers or device APIs.

Comments are open for one week. Let fly with your questions.

Have you published a response to this? :

Responses

Tom Hume

How can device and network APIs based on the browser keep pace, if device vendors continue to innovate and differentiate their products and platforms? Or should we come to terms with browser APIs lagging behind what’s available in native SDKs?

(not trying to turn this into native vs web apps, promise - the Boot2Gecko and WebOS guys have shown that it’s possible to narrow the gap between the browser and the platform, but thus far they haven’t succeeded)

# Posted by Tom Hume on Wednesday, May 2nd, 2012 at 7:18pm

paul downey

Which do you think are more important: document hyperlinks or users’ clicks?

Remy Sharp

To the mobile browser panel - and indeed the audience (sorry - long question - feel free to edit!):

When are we, as a web development community, going to stop giving Apple a free fucking pass?

They’re consistently lacking in the open discussion in to improving the gateway to the web: the browser. Sure, they landed an impressive mobile browsing experience back when the iPhone launched and it’s a great device, but there’s some serious questioning about whether they’re purposely cock-blocking web development and purposely hindering our advancement as a web industry.

WebGL is in mobile Safari, yet only available if accessed via a WebView object, not the real Safari (which is a WebView anyway…). It was recently discovered that they moved all web data storage (Web Storage, Appcache, etc) in a temporary data store meaning that it can be wiped at any time without warning.

Even the mighty PPK who tells entire browser vendors “fuck you”, doesn’t call Apple out, allowing them to slither on.

Why is it we continue to allow Apple to get away with it? And can this ever change?

# Posted by Remy Sharp on Wednesday, May 2nd, 2012 at 9:04pm

Jeff Bruss

You might say Breaking Development is more like the American version of Mobilism. The Mobilism event is more than 1.5 times larger than our lowly U.S. event, where we are still not quite getting the importance of mobile. Regardless, I think people need to understand the importance of developing for mobile and that conferences like both ours and PPK’s are leading the mobile revolution. Whether Amsterdam or Dallas, all aboard.

# Posted by Jeff Bruss on Wednesday, May 2nd, 2012 at 11:13pm

Alan Dalton

The User Agent Accessibility Guidelines (UAAG) 2.0 are guidelines for designing browsers and media players “[…] that lower barriers to Web accessibility for people with disabilities”: http://www.w3.org/TR/UAAG20 . How do the mobile browser makers try to conform to them?

Wart

As a designer/developer, It would be very useful for us if we could query the phone/browser to determine the connection speed or bandwidth.

there is some good discussion going on about this topic here on Chris Coyier’s css-tricks: http://css-tricks.com/bandwidth-media-queries/

see you next week !

# Posted by Wart on Thursday, May 3rd, 2012 at 11:47am

Lennart Schoors

While I carefully avoid to see the subject of Opera implementing WebKit aliases as a simple black and white matter, I did nod in consent with Peter Gasston’s remarks [1] regarding mostly visual embellishment properties like box-shadow and border-radius. Isn’t this some sort of box of Pandora, where authors now will have even less incentive to test in Opera browsers – because, you know, they’ll just mimic WebKit anyway?

[1] http://www.broken-links.com/2012/04/30/on-operas-implementation-of-webkit-aliases/

Yoav Weiss

My questions are regarding responsive images:

Is there a vendor that plans on implementing the picture element? How hard would it be for browsers to implement the responsive progressive JPEG concept that I outlined at http://blog.yoav.ws/2012/05/Responsive-image-format ? (assuming they provide good data reduction and that the scan metadata format in the JPEG comments is standardized)

# Posted by Yoav Weiss on Tuesday, May 8th, 2012 at 8:01am

John Holt Ripley

Unfortunately I can’t attend, but I’d love to ask if there’s a reliable way to detect support for the tel: URI scheme so that we can link phone numbers accordingly.

# Posted by John Holt Ripley on Wednesday, May 9th, 2012 at 11:53am

Jason Grigsby

I’d love to have the browser makers perspective on the Ringmark and CoreMob initiatives that Facebook has been leading. Is it useful? Are they paying attention? How do they envision it impacting the priority of features (if at all)?

Also, where’s my freaking camera access?

Aaron Gustafson

At Tuesday night’s Code & Creativity, digital governance expert Lisa Welchman equated digital projects to an atom. Content, IA, project management, networking, graphic design, application development, performance, and other concerns are flying this way and that like electrons—a swirling mass of energy and velocity. What holds this chaos together and keeps the electrons from flying off in all directions is the magnetic pull of protons in the nucleus of the atom.

In Lisa’s analogy, the protons of a digital project are Web standards and Key Performance Indicators (KPIs). She believes that without these key ingredients, projects will often career out of control. Her reasoning? We all need to know how we should be doing things in order to work together well (Web standards) and we need to know what our expectations are for the project to be successful (KPI).

This really resonated with me. Mainly, it resonated because I am a Web standards guy, but I also believe in the importance of standards across the board. I think projects need copywriting standards, design standards, performance standards, coding standards, and many other kinds of standards as well. Standards hold a project together. For real.

That’s why Web standards are so important.

Without standards, the Web was an unruly mass of spaghetti code. I started working on the Web in 1996. I know, I lived it.

We used to deliver separate browser-specific JavaScript and CSS files to different User Agents. Our HTML code had to be 3-4 times as hefty to support all of the various ways browsers had decided to implement the same features. It was horrible and made building anything remotely interesting a truly painful endeavor.

Then browser makers got together to codify HTML into a generally agreed-upon set of elements and attributes that would allow authors like me to write pages that would Just Work™. That work extended into CSS, and so on, and so forth. I can’t thank them enough for doing that.

Tuesday also saw the W3C officially make Pointer Events a recommendation. I’d always liked the idea of Pointer Events because it abstracts the traditional concept of a click into a generic interaction that could be triggered by a mouse, a finger, a pen, an eye movement, or any other interaction method we come up with in the future. Sure, I work for Microsoft now—they proposed this idea—but that isn’t the reason I like the concept. I like it because it doesn’t tie us down to a single way of interacting with Web content that necessitates the creation of new specs when new interaction methods are invented. It’s future friendly and embraces the “continuum of experience” I evangelize incessantly.

When Pointer Events were first proposed, there was a lot of support behind them. Obviously Microsoft was on board, but Mozilla was too. And Google was all about Pointer Events for a while and was already using them when they did an abrupt about-face and decided they were ripping them out of Blink in favor of overhauling Touch Events (which Apple supports and which Pointer Events were intended to supersede).

And so now we have a recommendation from the W3C that browsers implement Pointer Events. Developers want them and it seems Apple doesn’t. And because Apple doesn’t want them, Google doesn’t want them now either. To quote Rick Byers (of Google) in a Pointer Events meeting in late 2014:

No argument that PE is more elegant. If we had a path to universal input that all supported, we would be great with that, but not all browsers will support PE. If we had Apple on board with PE, we’d still be on board too. The equation has shifted for us.

So, effectively, Apple is holding the Web back. Tim Kadlec wrote a great piece discussing the core issue at play here:

Let’s set any opinions about Pointer Events aside. Frankly, I need to do a lot more digging here before I have any sort of strong opinion in one direction or another. There is a bigger issue here. We have a recurring situation where all vendors (save for Apple) show interest in standard, but because Apple does not express that same interest, the standard gets waylaid.

This whole thing has caused quite a kerfuffle in the Web community. Obviously, some people are demonizing Apple (and, by proxy, Google) for holding us back. Others are quick to excuse Apple because of their history of pushing the Web forward (see CSS transitions, animations, etc.).1 Personally, I don’t think anything is ever truly black and white. Every company does some good things and some bad things. To channel Lisa Welshman again, it’s like yin and yang: The light has a little bit of the dark in it, and the dark has a little bit of the light in it.

Generally, I’ve found that Apple tends to do what is best for Apple, without considering how it affects designers, developers, or the Open Web. On this issue however, I just haven’t figured out their angle yet.

Some of their past decisions have offered a clear view into their motivations. Take offline for instance. Apple supports the Application Cache API (as most modern browsers do), but there’s a catch: You can’t store audio files in the cache. That makes it nearly impossible to build a decent game in HTML because you won’t get sound effects if you aren’t connected to the Web. But for Apple it makes perfect sense: They sell games in the App Store.

Their motivations behind other decisions are more murky, however. For example, Safari implements the HTML5 Form Validation API, which means it knows if a field is valid or invalid. The catch? It won’t halt the submission of an invalid form. Every other modern browser acts as you’d expect.2 I don’t get it. I used to think/hope they just had not figured out how they wanted to handle notifying the user of the error, but it’s been like this for about 5 years.

I’ll let Tim jump in again here:

Apple has a very, very strong influence over what standards get adopted and what standards do not. Partly it’s market share, partly it’s developer bias (see, for example, how other vendors eventually felt forced to start supporting the webkit prefix due to vendor prefix abuse).

Apple simply does not play well with other vendors when it comes to standardization. The same sort of things we once criticized Microsoft for doing long ago, we give Apple a pass on today. They’re very content to play in their own little sandbox all too often.

He’s channeling a bit of Remy Sharp there (circa 2012):

When are we, as a web development community, going to stop giving Apple a free fucking pass?

They’re consistently lacking in the open discussion in to improving the gateway to the web: the browser. Sure, they landed an impressive mobile browsing experience back when the iPhone launched and it’s a great device, but there’s some serious questioning about whether they’re purposely cock-blocking web development and purposely hindering our advancement as a web industry.

WebGL is in mobile Safari, yet only available if accessed via a WebView object, not the real Safari (which is a WebView anyway…). It was recently discovered that they moved all web data storage (Web Storage, Appcache, etc) in a temporary data store meaning that it can be wiped at any time without warning.

Even the mighty PPK who tells entire browser vendors “fuck you”, doesn’t call Apple out, allowing them to slither on.

Why is it we continue to allow Apple to get away with it? And can this ever change?

As Tim points out, Apple certainly isn’t the only company that plays games when it comes to standards:

The other vendors aren’t exactly perfect either. The Microsoft folks, no doubt reeling from all the negativity aimed at them over the years, have more than once been content to let everyone else duke it out over a standard, only getting involved late when a consensus has been reached. The Blink folks, despite being the best positioned to take a stand, have been happy to play the “Apple won’t do it so I guess we won’t either” card on multiple occasions.

But he’s also quick to highlight the disappointing reality about Apple with respect to the other browser vendors:

It’s easy to reach the Mozilla, Google and Microsoft folks to discuss their thoughts on these emerging standards. That’s a much harder thing to do with the Apple crew.

Apple is very much a black box and their processes are incredibly opaque. Now I’m no hater, I use their products daily.3, but I am also not an apologist. I think relationships are improved with honesty and openness. I honestly wish Apple’s processes—at least when it comes to the Web—were more open.4 Heck, they often don’t even show up to meetings at the W3C. If we knew what they were thinking or why they were doing things, we could at least understand where they were coming from rather than having to speculate about their motivations. Whether we agree or not is irrelevant.

Regardless, we are where we are and I can’t help but wonder one thing: If we stop giving Apple a free pass and continue marching forward without them, will they eventually be forced to scramble to catch up like Microsoft did when IE6 sat on the shelf for so long? I don’t know what the answer is, but I sincerely hope they come around and begin to treat the Web with the respect it deserves before that happens.

When browsers refuse to implement Web standards, we all lose. And we take one step closer to the swirling pit of chaos and spaghetti code we thought we’d put behind us.

All of which were (in true Apple style) developed in secret and then bestowed upon the world in a grand spectacle.

Ok, Opera Mini doesn’t, but Opera Mini is also a different sort of browser. It is a proxy browser and the proxy handles all of the back and forth between the browser and the website’s origin server(s).

I am composing this post on a Mac… provided by Microsoft. Yes, you read that correctly.

I have felt the same way about Microsoft for years because I knew the great work they were doing behind the curtains. Part of the reason I joined them earlier this month was because they have been opening up and I want to encourage and nurture that.