W3C

List of comments on “W3C mobileOK Basic Tests 1.0” (dated 30 January 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-1602
Commenter: Jo Rabin <>
Context: in
assigned to Jo Rabin
Resolution status:

Do we need to be more specific about what we mean by valid utf-8, css, jpeg, gif and xhtml validation?
../actions/439 190
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1636
Commenter: Micah Dubinko <mdubinko@yahoo.com> (archived message)
Context: 1.2 Applicability
Not assigned
Resolution status:

1.2 Applicability

"The tests apply to a URI. Passing the tests means that under the right circumstances, resolving a URI will retrieve conformant content"

What is "conformant content"?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1637
Commenter: Micah Dubinko <mdubinko@yahoo.com> (archived message)
Context: 3.4 CONTENT_FORMAT_SUPPORT
assigned to Charles McCathie Nevile
Resolution status:

3.4 CONTENT_FORMAT_SUPPORT

Is the intent that all WML content is excluded from the possibility of being mobileOK? In some regions, WML devices still represent the majority of mobile UAs. To ask another way, it the intent of these tests to specifically exclude testable guidelines for WML?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-1608
Commenter: Loretta Guarino Reid <lorettaguarino@google.com> (archived message)
Context: 3 mobileOK Basic Tests
assigned to Sean Owen
Resolution status:

MobileOK Basic 1.0 limits itself to machine-testable properties, while
WCAG2 includes human-testable as well as machine-testable properties.
There may be occasions where MobileOK Basic tests can be used to test
all or part of a WCAG2 technique.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1646
Commenter: Christoph Richter <Christoph.Richter@bwin.org> (archived message)
Context: 3.11 MEASURES
Not assigned
Resolution status:

And btw, because of the Measures point, there is always an need to define 1px size of whatever for lines. And since we can produce for each handset the right page for their resolution we make everything in pixel…
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

typo comments

Comment LC-1647
Commenter: Bert Bos <bert@w3.org> on behalf of CSS Working Group (archived message)
Context: 2.3.4 CSS Style
Not assigned
Resolution status:

The "not" in "style elements whose type attribute is not
"text/css"" is erroneous since the type attribute on the style
element is REQUIRED as per [2]. Maybe just a typo?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1613
Commenter: Carlos Iglesias <carlos.iglesias@fundacionctic.org> on behalf of ERT Working Group (archived message)
Context: 2.3.4 CSS Style
assigned to Jo Rabin
Resolution status:

#5: Section "2.3.4 CSS Style" reads: "Style elements whose type attribute _is not_ text/css"

Souldn't be "Style elements whose type attribute _is_ text/css?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1597
Commenter: Jo Rabin <>
Context: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
Not assigned
Resolution status:

the example xml declaration is missing the mandatory version attribute
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1618
Commenter: Carlos Iglesias <carlos.iglesias@fundacionctic.org> on behalf of ERT Working Group (archived message)
Context: 3.7 GRAPHICS_FOR_SPACING
assigned to Jo Rabin
Resolution status:

#10: Section "3.7 GRAPHICS_FOR_SPACING" reads: "If image height and width are both less than 2 pixels, warn"

As 2x2 images are allowed ("at most 2x2" in the prose), the test should be: "If image height and width are both less than _or equal to_ 2 pixels, warn" to be in agreement with the prose.

Moreover, shouldn't also non-transparent graphics for spacing be considered?
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1663
Commenter: Jo Rabin <jrabin@mtld.mobi>
Context: 3.24 TABLES_LAYOUT (partial)
Not assigned
Resolution status:

real = actual
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-1635
Commenter: Micah Dubinko <mdubinko@yahoo.com> (archived message)
Context: Document as a whole
assigned to Abel Rionda
Resolution status:

Overall impression

The overall impression the tests give me is that, given a non-whitelisted device, the safer alternative is to exclude all CSS. This seems like the wrong impression to give mobile developers.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1629
Commenter: Kai Hendry <hendry@iki.fi> (archived message)
Context: Document as a whole
assigned to Daniel Appelquist
Resolution status:

Anyway it would be good if some mobile developing hints were just
implemented by a normal W3C HTML validator like http://validator.w3.org/
or Unicorn. Anyone working on that? Banging out this bureaucratic
document "W3C mobileOK Basic Tests 1.0" seems a waste of time and
resources.

You need to evolve faster.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1630
Commenter: Bruno von Niman <ANEC_W3CRep_Bruno@vonniman.com> (archived message)
Context: Abstract
assigned to Ignacio Marin
Resolution status:

Comment #1: In the perspective of the above, we believe that this may be understood as
(strongly) misleading consumers, who will have other, natural assumptions about the
meaning of the trust mark. Assumably, if a mobile Web site is declared to be “mobileOK�?,
consumers will assume the trust mark to is some kind of guarantee for aspects that will mean
OK to them. In other words, it may well be assumed as a guarantee for reliable content, safe
access, and trustable connections with a fair usability and some minimum levels of
accessibility. Furthermore, depending on the consumer’s age, assumptions may even be
made about the some kind of appropriateness of the content, when accessed by young
children.
An analogy to the above is TV sets marketed as “HD ready�?. Even if this is only a declaration
of one of the TV set’s capabilities, consumers (typically uninterested in details of this and
other technologies) will naturally assume this to be a declaration of compatibility and
capabilities for receiving and displaying high definition TV broadcasts without further needs to
buy additional products (such as a set-top box) and most probably, subscriptions (that will
also imply a considerable monthly fee). Consumers are often not aware that HD displays will
only display an HD picture when connected to an HD receiver (set-top box).
This will lead to consumer disappointment and the product may even be handed back. To
continue with the analogy, “Real HD ready�? TV sets are now marketed and the situation is
becoming very confusing…what was “HD ready�?? And what may be next? False marketing
does not aid the successful uptake of new consumer technologies.
Therefore, we suggest the re-branding of the mobileOKâ„¢ and mobileOK Basicâ„¢ trust marks
in some way that reflects their true and proper meanings. Due to the complexity of the
required branding, this may be a challenging task but worth the effort. It is not our task, nor
competence area to propose alternative names that would work properly on a global market
but wording that consumers would understand may include:
• Ready for mobile use;
• Mobile device adapted site;
• This content displays OK on mobile devices.
We believe that third party provisioning (or certification) is the only way to provide a reliable
trust mark information to consumers as often, products do not match qualities declared by
manufacturers, entailing a loss of consumer confidence. ANEC therefore encourages third-
party certification.
ISSUE-186
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1639
Commenter: Micah Dubinko <mdubinko@yahoo.com> (archived message)
Context: Status of this Document
assigned to Abel Rionda
Resolution status:

3.10 LINK_TARGET_FORMAT

Should this mention non-200 responses? 404, 500, etc..? In the case where the linked resource is a form submit with method="post", a GET request might properly fail.
192
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1585
Commenter: Timo Skytta <timo.skytta@nokia.com>
Context: 1 Introduction
Not assigned
Resolution status:

Hi,

This is kind of a stupid feedback, but I think I should mention it since
I have
now faced the problem several times.....

I have gotten a lot of feedback from people who have misunderstood that
the MOK Basic
test doc is setting requirements for a mobile web browser, like for
example people are
wondering why in 2.3.2 http://www.w3.org/TR/mobileOK-basic10-
tests/#http_request
we define such a limited HTTP Request etc....

So I have had to explain people that this doc is about defining how a
web site can be tested
for it's ability to deliver content based on the limitations set forth
by DDC and selected BPs
we chose to test. Meaning that the doc is about how to exercise a web
site with an imaginary
DDC client which MOK tester pretends to be to see if indeed the web site
can deliver MOK
content. Also I needed to make it clear to them that the doc is NOT
about testing a mobile
browser for MOK or setting any requirements to a mobile browser.....

I wonder if we should somewhere in the doc, like on the Abstract or on
the Introduction make it
clear that MOK is not about testing a mobile browser or setting any
requirements for it, but it is
about testing a web site and setting requirements for it.

Or maybe people providing me feedback are ignorant enough not to read
the doc in enough details...

-------------
Jo Rabin says:

I agree that if this is a common misconception then that misconception
should be put to rest. However, I think that what is missing is mainly a
statement of what mobileOK _is_ rather than a statement about what it is
_not_.

Also under 1.3 Claiming mobileOK conformance, we say "mobileOK does not
imply endorsement or suitability ... or is appropriate for children".

That statement is actually out of place (in that it is not about
claiming mobileOK conformance), so we should move it and put it with a
"not user agent test" disclaimer, to a proper section.

I think the right place is in section 1 Introduction. I suggest:

Current Text:

This document describes W3C mobileOK Basic tests, which are based on
Mobile Web Best Practices [BestPractices].

mobileOK Basic is the lesser of two levels of claim, the greater level
being mobileOK (W3C mobileOK?), described separately. Claims to be W3C
mobileOK Basic are represented using content labels, also described
separately.

The intention of mobileOK is to help catalyze development of Web sites
that provide a functional user experience in a mobile context.

Proposed Text:

mobileOK is a scheme for assessing whether Web resources (Web pages) can
be delivered in a manner that is conformant with Mobile Web Best
Practices [BestPractices].

This document describes W3C mobileOK Basic tests. mobileOK Basic is the
lesser of two levels of claim, the greater level being mobileOK (W3C
mobileOK?), described separately. Claims to be W3C mobileOK Basic are
represented using content labels, also described separately.

The intention of mobileOK is to help catalyze development of Web sites
that provide a functional user experience in a mobile context.

mobileOK does not imply endorsement or suitability of content. For
example, it must not be assumed that mobileOK content is of higher
informational value, is more reliable, more trustworthy or is
appropriate for children.

mobileOK is not a test for user agents and is not intended to imply
anything about the way that user agents should behave.

---------------------

Yes, thanks, I think there is an important aspect of Sean's proposal
that I missed out which is that the DDC needs significant mention. I
don't think that the tests 'emulate a request' as such. Rather they
describe how to emulate the DDC when making a request and how to assess
content delivered as a result.

So forgive me but I have a further elaboration:

Proposed Text:

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 [DDC].

This document describes W3C mobileOK Basic tests for delivered content,
and describes how to emulate the DDC when requesting that content.

mobileOK Basic is the lesser of two levels of claim, the greater level
being mobileOK (W3C mobileOK?), described separately. Claims to be W3C
mobileOK Basic are represented using content labels, also described
separately.

The intention of mobileOK is to help catalyze development of Web content
that provides a functional user experience in a mobile context. 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.

mobileOK does not imply endorsement or suitability of content. For
example, it must not be assumed that mobileOK content is of higher
informational value, is more reliable, more trustworthy or is
appropriate for children.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1606
Commenter: Loretta Guarino Reid <lorettaguarino@google.com> (archived message)
Context: 1.1 Levels of mobileOK
assigned to Jo Rabin
Resolution status:

We are concerned that the statement "Content which passes the tests
has taken some steps to provide a functional user experience for
users of basic mobile devices whose capabilities at least match those
of the Default Delivery Context (DDC)." would lead authors to conclude
that these guidelines will also meet the basic functional needs of
users with disabilities who use basic mobile devices. here is much in
common but these guidelines do not cover all of WCAG. We recommend
adding "To accommodate users with disabilities, WCAG should also be
met.", or "You should follow other guidelines that are applicable to
Web content, including the Web Content Accessibility Guidelines."
ACTION-440
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1631
Commenter: Bruno von Niman <ANEC_W3CRep_Bruno@vonniman.com> (archived message)
Context: 1.1.4 Beyond mobileOK
assigned to Ignacio Marin
Resolution status:

Comment #2: The above is a valuable statement to developers but, again, misleading to
consumers, who should understand the trust mark in the right way.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1607
Commenter: Loretta Guarino Reid <lorettaguarino@google.com> (archived message)
Context: 2.2 Testing Outcomes
Not assigned
Resolution status:

We like the similarity in approach to the descriptions of these test
and WCAG2 techniques. For MobileOK Basic Tests 1.0, the tests are
written in "programmatic" style. Test outcomes for MobileOK Basic 1.0
tests are pass, fail, and informative warnings. WCAG2.0 test outcomes
are "true", or "false". It would be worth exploring whether we could
use consistent language.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1611
Commenter: Carlos Iglesias <carlos.iglesias@fundacionctic.org> on behalf of ERT Working Group (archived message)
Context: 2.2 Testing Outcomes
assigned to Jo Rabin
Resolution status:

#3: Section "2.2 Testing outcomes"

The MWBP group have know made clear that warnings are _no_ test outcomes but it was also said that the group do not want to specify _which_ warning may be generated. In order for the tool developer to create a reasonable warning, it would help him to know at least the specific purpose why a warning has to be generated.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1632
Commenter: Bruno von Niman <ANEC_W3CRep_Bruno@vonniman.com> (archived message)
Context: 2.3 Conduct of Tests
assigned to Ignacio Marin
Resolution status:

Comment #3: In addition to the above information recommended for provision, the consumer
should be informed about the reason of failure in an understandable way. Additional
information relating to other functionalities should also be provided. Furthermore and in
addition, a technical reason or code may be provided to help the operator or creator of the
implementation to identify the source of the error.
Last but not least, consumers should be able to contact customer services through a single
point of access per modality (e.g. by calling the “usual�? number for all issues).
(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