From Core Mobile Web Platform Community Group
Jump to: navigation, search

The Coremob project starts from a simple desire that the Web should work equally well for all device classes and should be a platform of choice for any type of application.

Currently, the Web works pretty well for feature phone devices. And it works well on laptop/desktop devices as well. In both of those, one can find decent levels of interoperability (for well-crafted content) and graceful degradation, as well as a reasonably healthy diversity of implementations. In both classes, the Web performs at levels that match user expectations and usages, or are on a clear trajectory to reach that point. While more can and should be done to make developers' lives easier in providing more and better content to their users, there is no immediate obvious need for work that is not already defined or in progress.

For smartphone and tablet devices however, the picture is less rosy. We have a strange conjunction of a browser engine dominating the market and feature fragmentation at the same time due to different vendors enabling their own different subsets and providing their own extensions. Developers trying to target such platforms are currently finding it far more complicated than it needs to be. What's more, Web technology does not currently operate in this device class at the level of expectation that users have, and when developers try to use features that would allow them to get closer to such expectations they routinely have to do so through proprietary extensions (e.g.: vendor prefixes).

As a result much of the content created for this device class is created outside the Web. This hurts not just the Web on smartphones, but the entire Web ecosystem since content that lives in “apps” is not available to other device classes. It also drives developers away from the Web platform.

Producing better alignment for this device class will make it a lot easier to target content for the whole One Web, with much better progressive enhancement capabilities since they will be much easier for develop to.

This work is not mobile-specific, but rather mobile-scoped. This is to say that there is no part of it that applies solely to any particular device class. Some features are not always available to all devices, but in such cases paths to graceful degradation are normally designed into the system (where not, the issue should be brought to the relevant group). Our work does however focus on addressing issues commonly found in developing Web applications on smartphones and tablets.

We do so by taking a platform view of Web application development in this device class. As things currently stand, there is a large body of diverse specifications at varied degrees of maturity that are supported on devices. These specifications are designed to work together, but also to be implementable separately. And when they are implemented separately, we get more fragmentation than we bargained for. The idea here is to try to reach alignment on at least some of the core parts that should always be available.

Our focus in this work is entirely driven by developer needs. There may at times be some corner case issues that would require deep exegesis of this or that specification were we to address them. But unless a demonstrated interoperability issue can be exposed that concerns a real-world use case for such corner case behaviours, such exegesis will not take place and we will gladly ignore these darker corners. At times some choices may be messy, or even against known best practices. But if they are the most pragmatic option, they will be chosen.