Mobile/Open Web

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

The Mobile web must be opened, like the Desktop web was a decade ago. This requires a multiple-pronged strategy.

This page lists the different attack points and links to more specific action plans.

Site Evangelism

See the more detailed plan.

We must reach existing sites and ask/help them to fix themselves. We don't want to demonize them for "doing it wrong" but we want to help them fixing their sites.

• Opera and MS claimed in the CSSWG: "it doesn't scale" - maybe, but it is worth it for big sites, although they can be the most difficult to reach.
• This will takes time and, as we've seen with the Firefox 10 2-digit version number evangelism, sites often don't move before the problem is critical. Even with a precise diagnostic and an offer for help. We need to keep the pressure on.

This won't be sufficient by itself, but is worth doing and we have to focus on important sites first. We have to measure our success to make sure we devote adequate resources to this.

Allies: we want to promote the Open Mobile Web and not only a Gecko/WebKit mobile web. Our message should (and will) reflect this. Other mobile browser vendors have the same problems (particularly Opera and Microsoft). Can we work together?

Developer Evangelism

Web Developers must get accurate information about how to do a mobile web site that works on every browsers:

We need pragmatic MDN articles on:

• How to do proper UA sniffing for mobile sites
• How not to forget a prefix
• I'm using a prefixed property, what other prefix/polyfill do I need to add to keep the Web open? (-webkit fail-over)
• How to decide when to use an unprefixed CSS property?
• Progressive Enhancement (and polyfills to deal with older browsers)

These good practices should be in references pages (on the MDN). Then we need to advertise them in conference, blogs, tweets, etc. We need to lead Web developers to tools that simplify the process of writing/testing open web-friendly sites:

• preprocessors (Sass, Less, ...)
• validators (CSSLint, ...)
• etc.

But reaching Web developers is not easy: they are busy and not all haunt the blogosphere or events.

• We need small campaigns on specific subjects (spread via the blogosphere and social networks)
• We need big coordinated campaigns between vendors(?) (to reach Web devs that are not reading blogs or going to events, ...)

Web devs have managers, and we should turn them into our allies. We should craft messages to convince the managers that asking for sites for 'iPhone-only' is not a good investment (they could ask for all devices for almost the same amount of money).

Tools

We need to provide tools that help authors find incompatibilities earlier, and make the easy path the right path.

Preprocessors

Check that SASS, Less, ... (Feel free to complete) do not have bugs, that is do not forget some prefixes/polyfills...

CSSLint

Be sure that the entries are correct and up-to-date

Online tools

There are plenty of online tools that generate prefixed and unprefixed syntax (for animations, transitions and especially gradients). We have to check them and reach their authors if there are bugs.

JS un-prefixing tools

We should not recommend them (as most of them are slow to run, and if the network is slow to load the script they may lead to problems like FOUC or similar).

But as Web devs use them, we need to check that they do their job correctly! And reach their authors if needed.

Automatic regression finders on different engines

there are companies offering that: we have to be sure we are tested) (Cloud Testing?)

Remote debugging

debugging and regression testing in an automated way?

Desktop testing

https://wiki.mozilla.org/Mobile/Desktop_Extension

New Tools

(feel free to list ideas)

CSS/HTML Specification Work

See detailed thoughts about the CSS part of the problem: [1]

• We should aim to remove prefixes as soon as possible.
• We need to push what's possible to CR.
• We need to make sure that all useful CSS properties are on the standard track somewhere. There are a some that are not:
  • -webkit-scrolling-overflow: touch; looks new and not yet submitted. Is praised by some articles about the release of Chrome for Android: Happily, the very new -webkit-overflow-scrolling: touch property, which debuted in iOS 5, is also now available in Chrome for Android. It’s smooth and fast. (See [2] )
  • ... (complete please!)

• Drop prefixed versions at some point after unprefixing
  • Convince other vendors to do the same (even if it's only Google, it would be nice as it would create uncertainty again in using them). This uncertainty will force Web developers to maintain their sites and will favor simplicity (i.e. unprefix) over complexity.
• Remove (lessen) the need for UA sniffing

Web developers sniff UA for several reasons:

• To work-around bugs in browsers. This is not a big problem as that means that they are already considering different engines. Improving interoperability by fixing bugs is always nice.
• To provide different HTML for mobile and desktop as they have different layouts. This is necessary in different cases:
  • First if they have completely different Web sites. We should convince them that this is not necessary the right way to go: Progressive Enhancement (PE) is much more future-proof. (XXX I'm not sure about this - do we really want to tell people not to do one site for desktop and one site for mobile? While it may be technically possible to have a unified site, lots of people do two, and why do we care massively, as long as the mobile version works?)
  • Second, they do this when the layout of the mobile and desktop can't be achieved with the same HTML. We should push the adoption of new CSS layouts (CSS3 Columns, FlexBox and perhaps Grids). This improved flexibility will reduce the need for UA Sniffing ([3], under Source Order)
  • To serve less big HTML images for the mobile than the desktop (no Media Queries for HTML, only for CSS!) ([4], under Media). We need to solve the <img> HTML problem (See HTML has an <img> problem):
    • The <img> tag has not the flexibility of the audio and video HTML elements that allow the client to choose the most adequate version of the media. Instead, people does UA sniffing or do dirty tricks w/ JS. A Responsive Image Community Group has been created on the W3C about this problem.
    • A SVG image is blurry in Firefox if resized, defeating the opportunity to recommend to use SVG images where possible. (Bug 600207)

Technical Changes to Firefox for Mobile

There are changes to Firefox for Mobile that can be done to facilitate its adoption and/or compatibility:

• UA that gives the Mobile/Tablet information to the site (done for Mobile, not yet for B2G, as they don't do tablets yet)
• Support, temporarily and on mobile only, for some -webkit-prefixed properties
• Fix bugs that sites tell us mean they have to UA-sniff:
  • bug 600207: SVG-as-image is fuzzy/pixelated when zoomed or printed, when we trigger the tiling codepath (XXXwhich site or sites need this?)

Other

There are a lot of other small actions we could consider:

• Make sure our new UA string is included in lists of mobile UAs like WURFL
• Fix code which is on GitHub or other open repositories (see Prefix the Web by Chris Heilmann)
• Perhaps create an isitopenyet.com website with a number representing the amount of top-100 websites w/ correct CSS, if we can successfully detect that?