|
List Info
Thread: Re: please reivew mobileOK Basic Tests 1.0
|
|
| Re: please reivew mobileOK Basic Tests
1.0 |
  Japan |
2007-06-07 17:01:03 |
|
Hi MobileOK working group.
Upon request by Dan Connoly in the HTML WG, I’ve looked at your
specification, and have a couple of remarks.
First, section 2.3.2 HTTP Request states:
I think this is incorrect, text/css should NOT be included in the
Accept header, and image/jpeg and image/gif ONLY if the UA is expected
to support showing these images independantly of a document (the
mobileOK tests should explicitly check whether this is supported). The
client after all does not know how to handle a text/css file
independently of XML markup.
Instead, it should send an "Accept: text/css" header when the CSS files
that are linked using <link rel="stylesheet">,
<?xml-stylesheet?> or include. Similarly, images referenced from
<img> should send an "Accept: image/jpeg,image/gif" header. Aside
from checking the Accept header for the main page, the mobileOK tests
should also check that Accept headers send these values for stylesheet
and image requests.
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.
Third, in that same section, there is a requirement that only HTTP GET
methods can only be used. What about form submissions with POST?
Forcing forms to be sent with the GET method seems undesirable and
impairs the HTTP functionality. It seems a silly limitation too,
because if a mobileOK Basic application must support HTTP and HTTPS,
and Basic and Digest HTTP authentication, then surely support for POST
would be trivial. The mobileOK tests should provide tests for checking
proper cache clearing after a POST request has been done on a URL.
Fourth, section 2.3.4 Meta http-equiv Elements: why are these supported
at all, especially Content-Type and Cache-Control? In section 3.3, a
<meta> element is listed as an option to indicate character
encoding, given that there is an XML declaration and this <meta>
only complicates character set detection, I do not see a reason for
allowing this.
Fifth, in 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP it does not
distinguish included resources by type, that is, if it’s a stylesheet
include, only the text/css media type should be accepted (otherwise
FAIL), and if it’s an image include, only image/gif or image/jpeg is
accepted and not text/css. If it’s an object include, unless the UA is
expected to support CSS there by showing it somehow, text/css should
also not be accepted.
Sixth, in 3.10 LINK_TARGET_FORMAT, it states:
If the Content-Type header value
of the HTTP response is not consistent (determined in the same way as
specified in 3.3
CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE) with the
Accept-Charset header in 2.3.2
HTTP Request, warn
This should be a FAIL condition. Character set mismatches are very
undesirable (especially from an i18n perspective) and will create
significant hindrances for most non-English users, whose languages have
accents or even do not use our alphabet at all.
If you want to support ISO-8859-1 in some way to make it easier for
existing sites to server with the mobileOK label, ISO-8859-1 should
simply be processed appropriately and added to the Accept-Charset
header.
Seventh, in section 3.18 POP_UPS, target attributes on links with
values "_self", "_parent", or "_top" are accepted. All of these should
FAIL, however, since their presence does not make sense (and is a waste
of bandwidth) considering the requirements put forth in 3.13 NO_FRAMES.
That is it, I hope these comments were useful, and you will modify the
specification where necessary.
~Grauw
Dan Connolly schreef:
pav" type="cite">
I recently realized that this spec has various things
to say about how people should use HTML, so this working
group should be looking at it:
W3C mobileOK Basic Tests 1.0
http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/
W3C Working Draft 25 May 2007
comments due to w3.org">public-bpwg-comments w3.org by 22 June 2007
That's a 2nd last call; earlier releases pre-date the launch
of this WG, so they didn't hit my radar.
Everyone is welcome to take a look and send any comments
you have directly to w3.org">public-bpwg-comments w3.org .
If you have any comments that you think should be endorsed
by this Working Group, also send them here. If there's a critical
mass of support, I'm interested to make a formal decision
an notify the Mobile Web Initiative Best Practices Working Group.
Note that if we don't say anything, some will assume our
endorsement.
--
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.
|
|
| Re: Re: please reivew mobileOK Basic
Tests 1.0 |
  United States |
2007-09-29 10:51:26 |
Dear Laurens Holst ,
The Mobile Web Best Practices Working Group has reviewed the
comments you
sent [1] on the Last Call Working Draft [2] of the W3C
mobileOK Basic
Tests 1.0 (2nd Last Call) published on 25 May 2007. Thank
you for having
taken the time to review the document and to send us
comments!
The Working Group's response to your comment is included
below, and has
been implemented in the new version of the document
available at:
http://www.w3.org/TR/2007/WD-mobileOK-basic10-test
s-20070928/.
Please review it carefully and let us know if you agree with
it or not
before 19 October 2007. In case of disagreement, you are
requested to
provide a specific solution for or a path to a consensus
with the Working
Group. If such a consensus cannot be achieved, you will be
given the
opportunity to raise a formal objection which will then be
reviewed by the
Director during the transition of this document to the next
stage in the
W3C Recommendation Track.
Thanks,
For the Mobile Web Best Practices Working Group,
Michael(tm) Smith
W3C Staff Contact
1. http://www.w3.
org/mid/4668801F.2090006 students.cs.uu.nl
2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests
-20070525/
=====
Your comment on 2.3.2 HTTP Request:
> First, section 2.3.2 HTTP Request states:
>
> > *
> >
> > Include an |Accept| header indicating that
Internet media
> types
> > understood by the default delivery context
are accepted by
> > sending exactly this header:
> >
> > Accept:
>
application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xh
tml+xml;q=0.1,text/css,image/jpeg,image/gif
> >
> >
>
> I think this is incorrect, text/css should NOT be
included in the
> Accept
> header, and image/jpeg and image/gif ONLY if the UA is
expected to
> support showing these images independantly of a
document (the mobileOK
>
> tests should explicitly check whether this is
supported). The client
> after all does not know how to handle a text/css file
independently of
>
> XML markup.
>
> Instead, it should send an "Accept: text/css"
header when the CSS files
>
> that are linked using <link
rel="stylesheet">, <?xml-stylesheet?> or
> include. Similarly, images referenced from
<img> should send an
> "Accept: image/jpeg,image/gif" header. Aside
from checking the Accept
> header for the main page, the mobileOK tests should
also check that
> Accept headers send these values for stylesheet and
image requests.
Working Group Resolution:
We do not think it is wrong to specify the headers in the
way we do,
however we accept that we do not properly check that the
right sort of
content has come back in response to the request. In other
words, if the
request is made because of an img tag then the response
should be an
image. We did not test for that in the draft you reviewed
and we will
amend accordingly. In particular, in 3.4, <img> tags
that retrieve valid
CSS delivered as text/css should for example FAIL too.
----
Your comment on 2.3.2 HTTP Request:
> Third, in that same section, there is a requirement
that only HTTP GET
> methods can only be used. What about form submissions
with POST?
> Forcing
> forms to be sent with the GET method seems undesirable
and impairs the
>
> HTTP functionality. It seems a silly limitation too,
because if a
> mobileOK Basic application must support HTTP and HTTPS,
and Basic and
> Digest HTTP authentication, then surely support for
POST would be
> trivial. The mobileOK tests should provide tests for
checking proper
> cache clearing after a POST request has been done on a
URL.
Working Group Resolution:
We will insert a reference in 2.3.2 referring to 2.3.8 to
make it clearer
that POST is definitely allowed as a form action in mobileOK
content but
that it is simply not tested, for fear of the tester causing
unwanted side
effects.
----
Your comment on 3.4 CONTENT_FORMAT_SUPPORT and
VALID_MARKUP:
> Fifth, in 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP
it does not
> distinguish included resources by type, that is, if
it’s a stylesheet
>
> include, only the text/css media type should be
accepted (otherwise
> FAIL), and if it’s an image include, only image/gif
or image/jpeg is
>
> accepted and not text/css. If it’s an object include,
unless the UA
> is
> expected to support CSS there by showing it somehow,
text/css should
> also not be accepted.
Working Group Resolution:
We will add that if the resource is expected to be a
stylesheet, it must
be text/css (and be valid CSS), and likewise for images and
FAIL if it is
not - also that Objects need to be images in this case.
----
|
|
| Re: Re: please reivew mobileOK Basic
Tests 1.0 |
  United States |
2007-10-02 22:13:02 |
|
|
[1-3]
|
|