Go to
Result:
This page is mobileOK!
Page Size:
2.7KB
document: 1.6KB - images: 1.1KB
Size Type URI
1.6KB document Resource under test
1.1KB image http://static.rememberthemilk.com/img/logo_mobile2.gif
Network:
2 requests
document: 1 - images: 1
Type URI
document Resource under test
image http://static.rememberthemilk.com/img/logo_mobile2.gif

Check out W3C's training courses for mobile!

Help on the checker is available.

Congratulations

The document located at <http://m.rememberthemilk.com/> was successfully checked as mobileOK®. This means that the resource in question passed all the tests defined in the W3C mobileOK Basic Tests 1.0 specification.

If you are the author of the Web page, you may wish to identify your content as mobileOK conformant. There is more than one way to claim mobileOK conformance, detailed in the Claiming conformance section of the W3C mobileOK Scheme 1.0 document. Here are two possibilities:

  • Claiming conformance using POWDER

    To enhance discoverability of mobileOK content, you may wish to identify your content as mobileOK conformant using POWDER (the Protocol for Web Description Resources). In a nutshell, simply copy and paste the following POWDER document in a new file on your server and link to it from your mobileOK page using a link element in the head section of the page as described in Linking Resources to Claims using the HTML link Element section of the W3C mobileOK Scheme document. The mobileOK POWDER Generator may be used to generate more complex claims, e.g. to claim that an entire Web site is mobileOK.

    <?xml version="1.0"?>
    <powder xmlns="http://www.w3.org/2007/05/powder#">
     <attribution>
      <issuedby src="http://www.w3.org/data#W3C" />
      <issued>2009-11-24T18:20:22Z</issued>
      <supportedby src="http://validator.w3.org/mobile/" />
     </attribution>
     
     <dr>
      <iriset>
       <includeresources>http://m.rememberthemilk.com/</includeresources>
      </iriset>
     
      <descriptorset>
       <typeof src="http://www.w3.org/2008/06/mobileOK#Conformant" />
       <displaytext>The page is mobileOK</displaytext>
       <displayicon src="http://www.w3.org/2005/11/MWI-Icons/mobileOK.png" />
      </descriptorset>
     </dr>
    </powder>

    For further reading about POWDER, please refer to the POWDER primer document.

  • Claiming conformance using the mobileOK icon

    You may wish to claim conformance using the mobileOK icon:

    W3C mobileOK Logo

    Please note that the mobileOK icon should not be embedded within the mobileOK representation of the page, as the resulting page would not be mobileOK anymore. The mobileOK icon is rather intended to be used in Web sites that use content adaptation to advertise the existence of a mobileOK representation of a page in e.g. its desktop version.

Detailed report

  1. Style sheets

    The most efficient way to control the layout of a page is to use CSS style sheets. To use them well in a mobile browser, it is important to ensure that the CSS style sheets referenced by a page and the CSS styles directly defined in the page are valid, and e.g. make a good use of the @media rules.

  2. User input

    Keyboard and other input methods on mobile devices can be tedious to use. Inputs should be minimized. Default values should be provivded to guide the user whenever possible.

    • Warning Consider adding an inputmode attribute to this input element.
      If the expected text entry uses a well-defined subset of characters (e.g. numbers), identifying that set using the inputmode attribute of the input element can help mobile browsers uses the most adapted input mode on the device (e.g. numeric keyboard vs alphabetic).
      Add an inputmode attribute to the input element, with one of the well-known inputmode values.
      Triggered 2 times by the resource under test:
      … <input name="username" type="text"/>
      … <input name="password" type="password"/>
      Related best practice:
      [DEFAULT_INPUT_MODE] Specify a default text entry mode, language and/or input format, if the device is known to support it.
  3. At the HTTP level

    The source of the messages in this category is to be found in the HTTP headers that were sent along with the page. They are most likely due to the Web server configuration for static files, or the way the server-side scripts are written for dynamic content. Making sure that HTTP headers are correctly defined is essential in a mobile context with a usually low bandwidth and high latency.

    • Warning "Cache-Control" HTTP header is present and contains value "no-cache", or contains value "max-age=0"
      A no-cache (or max-age=0) directive prevents browsers from caching the content, and thus requires them to retrieve it through the network every time.
      If the resource needs to be revalidated each time it is queried, consider using the Last-Modified and/or ETag HTTP headers to limit the complete retrieval of the resource to the cases where the resource has changed. See Mark Nottingham's tutorial on caching to learn more about these techniques.
      Triggered by the resource under test.
      Related best practice:
      [CACHING] Provide caching information in HTTP responses.
    • Warning The "Pragma" header contains the value "no-cache"
      The no-cache value in the Pragma HTTP directive prevents browsers from caching the content, and thus requires them to retrieve it through the network every time.
      If the resource needs to be revalidated each time it is queried by users, consider using the Last-Modified and/or ETag HTTP headers to limit the complete retrieval of the resource to the cases where the resource has changed. See Mark Nottingham's tutorial on caching to learn more about these techniques.
      Triggered by the resource under test.
      Related best practice:
      [CACHING] Provide caching information in HTTP responses.
    • Warning The "Expires" header contains a date in the past
      An Expires date set in the past prevents browsers from caching the content, and thus requires them to retrieve it through the network every time.
      If the resource needs to be revalidated each time it is queried by users, consider using the Last-Modified and/or ETag HTTP headers to limit the complete retrieval of the resource to the cases where the resource has changed. See Mark Nottingham's tutorial on caching to learn more about these techniques.
      Triggered by the resource under test.
      Related best practice:
      [CACHING] Provide caching information in HTTP responses.
    • Warning A cache related header or a meta http-equiv value contains an invalid value
      An unknown value in a caching directive may be the result of a typo, and could prevent browsers from properly handling the caching information.
      Triggered 2 times by the resource under test:
      Invalid value post-check
      Invalid value pre-check
      Related best practice:
      [CACHING] Provide caching information in HTTP responses.

↑ Top