W3C

List of comments on “W3C mobileOK Basic Tests 1.0 (2nd Last Call)” (dated 25 May 2007)

Quick access to

There are 82 comments (sorted by their types, and the section they are about).

1-20 21-40 41-60 61-80 81-82

question comments

Comment LC-1713
Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message)
Context: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
assigned to Sean Owen
Resolution status:

> For each included resource (see 2.3.6 Included Resources):
>
> If the response specifies an Internet media type that is not
> "text/css", "image/jpeg" or "image/gif", FAIL

Is there a good reason to exclude PNG?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1707
Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message)
Context: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
assigned to Sean Owen
Resolution status:

> If the HTTP Content-Type header does not specify a character
> encoding:
>
> If there is no XML declaration, or UTF-8 character encoding is not
> specified in the XML declaration, FAIL

XML provides an unambiguous default. Is there a practical reason, due
to broken real-world UAs perhaps, not to PASS defaulted UTF-8?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1710
Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message)
Context: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
assigned to Sean Owen
Resolution status:

> If the document's Internet media type is "text/html" or
> "application/vnd.wap.xhtml+xml", warn

What's wrong with HTML served as text/html?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-1719
Commenter: Ben Cerbera Millard <cerbera@projectcerbera.com> (archived message)
Context: Document as a whole
Not assigned
Resolution status:

> The draft is premised on a vision about mobile browsing that assumes
> special mobile content. Instead of implying a separate Mobile Web, I
> think the W3C should push for one World Wide Web with mobile browsers
> that can access general Web content.
> [...]
> The premise of mobileOK seems to be that you take the non-Web-ready thin
> browser and expect origin servers out there take special steps to
> accommodate it.

This is a fundamental criticism I have of the mobileOK guidelines. Mobile
phone networks here in the UK have been promoting their "access the whole
Web on your phone" capabilities for years. They can even do scripting [1].

Because so much web content is text/html, surely it is more useful to work
on improving support for that in UAs? Mainstream mobile UAs already have
better support for HTML than XHTML, many having no support at all for XHTML
[2]. I can browse the text/html Web fine on my mobile phone in the
here-and-now.

PDF and Word documents are also more common than XML formats on the web, in
my experience. Improving support for them would surely be the next logical
priority after HTML?

Advising against W3C technologies such as HTML and PNG seems like a strange
move for a W3C Working Group to take. Especially since these technologies
are already implemented widely.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1725
Commenter: Ben Cerbera Millard <cerbera@projectcerbera.com> (archived message)
Context: Document as a whole
assigned to Sean Owen
Resolution status:

> 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.

Perhaps the Default Delivery Context (DDC) is out of date? It seems to be
based on mobile phones produced in the mid-1990's. They have become
radically more capable in the decade since then. My experience is mainstream
mobiles getting closer to desktop browsers each year (Opera [1] and Webkit
[2] being industry leaders in this regard).

The mobile industry's aims are clear from their actions: make the whole web
available [3][4]. Surely W3C's MWI should be centered on making that happen
faster and more effectively? The current work seems to be on degrading
current content to accomodate a DDC akin to decade-old phones which, AFAIK,
no longer exist.

Vodafone [5], T-Mobile [3] and Three [6] already have a flat rate for web
access in the UK (as Simon Pieters speculated on). So for one thing, the
financial cost of page downloads is being solved by market factors...just
like it did for desktop PCs. :-)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1726
Commenter: Ben Cerbera Millard <cerbera@projectcerbera.com> (archived message)
Context: Document as a whole
assigned to Sean Owen
Resolution status:

> If "HTML Basic" existed I think there would be a good argument to
> specify it instead.

Since text/html work has started again at W3C in the form of the HTMLWG,
perhaps an "HTML Basic" spec would now be feasible? Then again, the 1998
attempt at this [7] didn't take off, so reduced HTML was not the solution
even with devices *that* limited. And since current mobiles handle full HTML
websites, degrading content at the origin server seems ever more unnecessary
(the network can do this on-the-fly if it needs to be done).

Sincere thanks for taking the feedback from the new HTMLWG seriously. I too
hope HTMLWG will add more practical value to the W3C's Mobile Web Initiative
(MWI) [8].
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1720
Commenter: Simon Pieters <zcorpan@gmail.com> (archived message)
Context: Document as a whole
assigned to Sean Owen
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1697
Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message)
Context: Document as a whole
assigned to Sean Owen
Resolution status:

> mobileOK Basic is a scheme for assessing whether Web resources (Web
> content) can be delivered in a manner that is conformant with
> Mobile
> Web Best Practices [BestPractices] to a simple and largely
> hypothetical mobile user agent, the Default Delivery Context.

The draft is premised on a vision about mobile browsing that assumes
special mobile content. Instead of implying a separate Mobile Web, I
think the W3C should push for one World Wide Web with mobile browsers
that can access general Web content.

Mobile access to general Web content can be accomplished in at least
two ways:
1) Putting a World Wide Web-ready browser engine on the mobile device
(e.g. Minimo, the new S60 Browser, Opera for Mobile)
2) Using a distributed UA that puts a thin front end on the mobile
and keeps the main engine on an intermediate server (e.g. Opera Mini)

The premise of mobileOK seems to be that you take the non-Web-ready
thin browser and expect origin servers out there take special steps
to accommodate it.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1698
Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message)
Context: Document as a whole
assigned to Sean Owen
Resolution status:

> It is not a test for browsers, user agents or mobile devices,
> and is not intended to imply anything about the way these should
> behave.

In practice, the draft is implying expectations about UA behavior.

> Content passing the tests demonstrates that the content provider
> has
> taken basic steps to provide a functional experience for mobile
> users.

I don't like the implication that pointy-haired managers are likely
to take statements like this and bother their teams about hunting a
badge of approval instead of testing that their sites work with
browsers that run on mobile devices and are capable of browsing the
real World Wide Web.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1699
Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message)
Context: 1.3 Claiming mobileOK conformance
assigned to Sean Owen
Resolution status:

> 1.3 Claiming mobileOK conformance
>
> A standard mechanism will be defined that allows content
> providers to
> claim that a URI or group of URIs, such as a Web site, conforms to
> mobileOK Basic or mobileOK Pro. It will be possible to make
> claims in
> a machine-processable form. It will also be possible to notify end
> users of the presence of the claim by means of a human-readable
> mark.

I think testing content along the lines of mobileOK should be part of
the internal quality assurance process of content providers. I think
it should not be part of the external marketing process.

When people are just hunting the badge for marketing purposes, they
may make silly workarounds to please the testing software while
actually making the user experience worse.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1724
Commenter: Anne van Kesteren <annevk@opera.com> (archived message)
Context: 2.3.2 HTTP Request
assigned to Sean Owen
Resolution status:

On another point, Content-Type of the response for both image and style
sheet requests is simply ignored. The image type is determined through
sniffing and in case of a linked style sheet it is simply parsed as CSS.
This is more or less required for user agents if they want to support web
pages out there.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1691
Commenter: Laurens Holst <lholst@students.cs.uu.nl> (archived message)
Context: 2.3.2 HTTP Request
assigned to Sean Owen
Resolution status:

Second, in that same section, I think saying that UAs must send
‘exactly’ this header is not desirable. That would prevent UAs from
handling additional media types, such as image/png or image/svg, and
limit innovation. After all, the UA would not be able to claim a
mobileOK label anymore. The spec should say that UAs must send exactly
this or a superset of this header.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1703
Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message)
Context: 2.3.10 White Space
assigned to Sean Owen
Resolution status:

> For XML 1.1 [XML11] it is defined in section 1.3 as consisting
> of the
> same characters with the addition of NEL (#x85) and the Unicode
> line
> separator character, (#x2028).

Surely an XML 1.1 document cannot get mobileOK approval.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1711
Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message)
Context: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
assigned to Sean Owen
Resolution status:

> If the document does not contain a DOCTYPE declaration, FAIL

I think the W3C should promote doctypelessness for application/xhtml
+xml. See http://hsivonen.iki.fi/doctype/#xml

However, documents that rely on the WAP dollar substitution must have
a doctype that activates the dollar substitution in Opera. Still,
relying on the dollar substitution is a bad idea.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

typo comments

Comment LC-1748
Commenter: Shadi Abou-Zahra <shadi@w3.org> (archived message)
Context: 2.3.6 Included Resources
assigned to Jo Rabin
Resolution status:

COMMENT B.7:
- comment nature: [typo]
- location: 2.3.8
- current wording: Note that forms with method _get_ are permissible in
documents under test, but must not be checked in case posting caused
unwanted side effects such as the addition of unwanted records to a
database.
- suggested revision: Note that forms with method _POST_ are permissible
in documents under test, but must not be checked in case posting caused
unwanted side effects such as the addition of unwanted records to a
database.
*rationale: We think it's a typo as currently POST is the method that
it's not been checked
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1727
Commenter: Jon Ribbens <ertwg@sitemorse.com> (archived message)
Context: 2.3.8 Visible Linked Resources
assigned to Jo Rabin
Resolution status:

| 2.3.8 Visible Linked Resources
| ...
| Note that forms with method get are permissible in documents under
| test, but must not be checked in case posting caused unwanted side
| effects such as the addition of unwanted records to a database.

I think that's probably meant to say 'forms with method *post*'.
Either way, it doesn't make sense in context as-is.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1730
Commenter: Jon Ribbens <ertwg@sitemorse.com> (archived message)
Context: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
Not assigned
Resolution status:

| 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
| ...
| HTTP Content-Type headre
| application/xhtml+xml; charset=UTF-8"

Extraneous " at the end of the line.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1753
Commenter: Shadi Abou-Zahra <shadi@w3.org> (archived message)
Context: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
assigned to Sean Owen
Resolution status:

COMMENT B.12:
- comment nature: [typo]
- location: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
- current wording: application/xhtml+xml; charset=UTF-8"
- suggested revision: Remove '"'
- rationale:
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1758
Commenter: Shadi Abou-Zahra <shadi@w3.org> (archived message)
Context: 3.6 EXTERNAL_RESOURCES
assigned to Jo Rabin
Resolution status:

COMMENT B.17:
- comment nature: [typo]
- location: 3.6 EXTERNAL_RESOURCES
- current wording: Count the total number of unique included resources,
as defined in 2.3.6 Included Resources
- suggested revision: Add '.'
- rationale:
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1762
Commenter: Shadi Abou-Zahra <shadi@w3.org> (archived message)
Context: 3.13 NO_FRAMES
assigned to Jo Rabin
Resolution status:

COMMENT B.21:
- comment nature: [typo]
- location: 3.13 NO_FRAMES
- current wording: "If the document contains a frame, frameset or iframe
element or object element..."
- suggested revision: "If the document contains a frame, frameset or
iframe element or _an_ object element..."
- rationale: Apparently there is a missing "an"
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-60 61-80 81-82

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org