Edit comment LC-1720 for Mobile Web Best Practices Working Group

Previous: LC-1726 Next: LC-1697

Comment LC-1720: Comment Shortname:; Commenter: Simon Pieters <zcorpan@gmail.com>; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
As I understand it, the tests suggest that authors use a separate version
for desktop and for mobiles. I can understand that doing so can be
desireable today for the following reasons:

1. Users have to pay per byte for browsing on the mobile.
2. The connection speed on mobiles is slow.
3. Many mobile browsers have bad support for CSS.

On the longer term, (1) should be addressed by providers offering monthly
fees; (2) should be addressed by improving mobile networks, and (3) by
improving the implementations. (2) and (3) are already happening, and I
wouldn't be surprised if (1) happened soon. When these have been
addressed, there is little reason for authors to provide separate versions
for mobiles and for desktop, as opposed to using one version that works
for both.

The tests warn for things that are not supported on some mobile devices,
such as scripting, even though it is possible to provide fallback content
for UAs without scripting and including scripts doesn't harm UAs that
don't support it. I would suggest not warning for things that don't harm
mobile browsers and could benefit other UAs, in the interest of not
putting unnecessary strain on authors.; Related issues: (space separated ids); WG Notes: My personal opinion is that the difference between a desktop and mobile phone-friendly page is not bridge-able with just some CSS and media selectors. The phone (and here we are talking about low-end phones, not big PDAs) has a drastically smaller screen, no keyboard, no pointer, and may not even be able to load the single document that's also written for the desktop into memory. I do think it's feasible to write once for the desktop and some kind of portable device, but such a device is substantially different from what people have in their average phone / browser. For this reason I think the mobile (= phone) context needs to be considered separately. It's "different enough", in the same way that I don't think anyone seriously expects a desktop web page can be "rendered" comparably by an audio text reader. One might reasonably argue the web just doesn't belong on mobile then. I think there is enough motivation for getting some kind of web access onto phones that the BPWG should exist, and don't think its activities harm the One Web cause. That's my speech. > The tests warn for things that are not supported on some mobile devices, > such as scripting, even though it is possible to provide fallback content > for UAs without scripting and including scripts doesn't harm UAs that > don't support it. I would suggest not warning for things that don't harm > mobile browsers and could benefit other UAs, in the interest of not > putting unnecessary strain on authors. The tests check how well content works on an abstract device profile called the Default Delivery Context, which isn't assumed to support scripting. The relevant Best Practice here says "don't use script unless you know the page works fine without it." A machine test can't determine whether script is essential to the page or not, though more likely than not it is. Given that the target device doesn't support script, it's at least a waste of bytes. Well, that's the rationale behind the warn, and it is not a failure for the reason you give exactly. That is, you don't have to remove <script> to pass the mobileOK Basic tests.; Resolution: We don't doubt that implementations and feature sets are improving, costs coming down and so on. However, that has far from universally happened, and even if it did, we believe that the context of the mobile user will often make it desirable to present an interface that is sympathetic to that context. In particular it is possible to pass mobileOK Basic while using <script>; it merely generates a warn. More generally, we're not saying you can't use <script>, just that you need to be able to deliver an experience to baseline devices that works without script. You may do whatever you like to other devices.; (Please make sure the resolution is adapted for public consumption)