W3C

Disposition of comments for the Mobile Web Best Practices Working Group

Single page view

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

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-1723 Anne van Kesteren <annevk@opera.com> (archived comment)
> One sub-point I'd like to make is that it's not wrong for the user
> agent to say nothing about what it accepts. It's also not wrong to
> list everything it accepts every time, according to HTTP. If a request
> for a CSS file retrieves a text/html document, well, sounds like the
> site is quite broken. This is not a user agent problem.

I think I interpret this rather different from you. That is, the user
agent indicates which types it supports for a particular request. So if it
says text/html when it fetches a style sheet it indicates it can process
text/html as a style sheet for the current page. Or if it fetches an image
that it can show text/html resources as images.
We don't agree that the HTTP RFC requires this interpretation. We believe that if a user agent includes an accept header that specifies text/css in a request, that is an indication not that text/css is an acceptable response for an image but that it can process text/css in some circumstances. In general the User Agent does not know what type of resource to anticipate when it makes a request. It is a special case when it does, as a result in this case of making a retrieval linked to a specific element in a resource already retrieved. yes
LC-1700 Henri Sivonen <hsivonen@iki.fi> (archived comment)
> * 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.xhtml+xml;q=0
> .1,text/css,image/jpeg,image/gif

The main request should not include the CSS type. The requests for
style sheets should only list the CSS type. Requests for images
should only list image types.

It is rather sad that the supported image formats do not include PNG.
We think that the request headers indicate general capabilities not specific capabilities for any particular request. In the case of the "main" request, it cannot be said for sure that the resource under test is not a css resource. The tester takes no view aobut the format of a resource under test when it requests it, it is only after it receives it that it checks that it is valid HTML etc. In general we believe this is consistent with User Agent behaviour which is not to assume that a resource is of any particular format.

PNG is not included in the request header because it is defined as being unsupported by the DDC. That in turn results from support not being as widespread as other formats.
tocheck
LC-1701 Henri Sivonen <hsivonen@iki.fi> (archived comment)
> * Check for consistency with HTTP headers, as follows:
> For each meta element with an http-equiv attribute:
> If a matching HTTP response header does not exist, warn
> If a matching HTTP response header exists but its value differs
> from the content attribute value, warn

These two should not apply at all to Refresh as Refresh is not used
on the HTTP level in the real world. On the other hand, they should
both be failures for the cache control because caching proxies should
be able to work on the HTTP level without looking inside payload. For
XML media types, the meta charset is always bogus so both cases
should fail to avoid people depending on the bogus meta charset. For
text/html, the case where the real HTTP header and the meta charset
disagree should be a failure, because the disagreement is a symptom
of something being wrong in the content production or serving process.
Our experience shows that Refresh is indeed used as an HTTP header.

We note under CACHING that using meta http-equiv is undesirable for the reasons you state. We have taken the view that it is undesirable to FAIL implementations that cannot change their http headers but that make some attempt to indicate their preference using meta http-equiv.

Your point about meta and charsets we believe is reflected under the rules specified at 3.3 character encoding.
tocheck
LC-1702 Henri Sivonen <hsivonen@iki.fi> (archived comment)
> In the course of assembling the CSS Style:
> * observe the CSS Level 1 cascade

Specs written today should probably reference CSS 2.1 instead of
Level 1.
We encourage people to use CSS 2.1 where they know it is supported. If they do not know it is supported then the DDC profile is defined to only support CSS 1 and @media. tocheck
LC-1705 Henri Sivonen <hsivonen@iki.fi> (archived comment)
> If any cache related header contains an invalid value, warn

Why not fail?
Many of the cache-related headers, like Cache-Control, can take on new values in the future. Expires, for example, has defined behavior even on values that are not dates. So 'invalid' is hard to define; all values have a defined behavior and no known adverse effect, so we wish to be conservative and not fail. tocheck
LC-1708 Henri Sivonen <hsivonen@iki.fi> (archived comment)
> If the HTTP Content-Type header specifies an Internet media type
> starting with "text/":

This should apply to text/html.
The text is appropriate as it stands as "starting with text/" includes text/html. tocheck
LC-1709 Henri Sivonen <hsivonen@iki.fi> (archived comment)
> If there is no meta element with http-equiv attribute that
> specifies
> UTF-8 character encoding, FAIL

Note that the current HTML 5 draft uses an attribute called charset.

Having a meta charset in a document that is served using an XML type
(text/xml, application/xml and */*+xml) should probably be a warn at
minimum considering that a charset meta in XML is bogus.
Under 3.3 we specify that meta is only considered in respect of charset if the content is served as text/html in which case it is required for the benefit of non-XML processors. We think it is unreasonable to penalize its presence in documents served as XML media types as it will be ignored in practice and the content provider may have no knowledge or control over the content type attached to their content. tocheck
LC-1714 Henri Sivonen <hsivonen@iki.fi> (archived comment)
> If the element's value attribute is missing or empty, and an
> inputmode
> attribute is not present, warn

This seems excessive as it is quite likely that things will be just
fine without content micromanaging the input mode on the UA.
The test is based on the Best Practices. We warn (not fail) in the absence of an inputmode attribute. tocheck
LC-1715 Henri Sivonen <hsivonen@iki.fi> (archived comment)
> If an alt attribute is not present or consists only of white space,
> FAIL

This is a bad idea because it encourages badge hunters to include
bogus alt text that actually harms accessibility. Tests like this
only lead to an arms race where the placeholder data always gets a
step more complicated than what the testing tools can detect as a
placeholder.
The test specifically allows empty ALT tags which is the accepted way of indicating that there is no appropriate ALT text. tocheck
LC-1717 Henri Sivonen <hsivonen@iki.fi> (archived comment)
> If the document contains any basefont, bdo, center, del, dir, font,
> ins, menu, s, strike or u elements, FAIL

del and ins are legitimate in both HTML 4.01 and in the current HTML
5 draft. menu is legitimate in HTML 5.
These tags are not defined in XHTML Basic or MP and therefore not supported by the DDC or mobile phones in the marketplace. tocheck
LC-1718 Henri Sivonen <hsivonen@iki.fi> (archived comment)
> If the document contains any b, big, i, small, sub, sup or tt
> elements, warn

These elements are relatively common and harmless in practice. This
warning seems excessive.
We encourage people to use CSS and hence a warn is justified. tocheck
LC-1781 Jonathan Jeon <hollobit@etri.re.kr> (archived comment)
3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

The DDC is defined to support only UTF-8 encoding, which means that this test fails if a resource cannot be encoded in UTF-8. It is reasonable to recommend that default character encoding should use UTF-8. But it is not good that all of another character encoding except UTF-8 should be FAIL.

In many cases, if some country does not use English as a native language, they are using various character encoding schemes. For example, EUC is a multibyte character encoding system used primarily for Japanese, Korean, and simplified Chinese. The EUC-KR and EUC-JP(ISO-2022) encoding is heavily used in Korea and Japan. [1]

UTF-8 is not widely used in Korea. EUC-KR is more popular character encoding scheme in Korea (maybe more than 90% of Wired and Mobile web contents). It is the most widely used legacy character encoding in Korea on all three major platforms. Therefore, if we support only UTF-8, more than 90% of sites and contents will be ‘FAIL’.

So, it is proposed to consider additional character encodings. It is proposed to modify the section 3.3 as below:

PROPOSED TEXT:
------------------------
If the HTTP Content-Type header specifies a character encoding:
If character encoding is default-character-encoding, PASS
If character encoding is not default-character-encoding, warn
If the HTTP Content-Type header does not specify a character encoding:
If there is no XML declaration, or default character encoding or any character encoding is not specified in the XML declaration, FAIL
If the HTTP Content-Type header specifies an Internet media type starting with "text/":
If there is no meta element with http-equiv attribute that specifies default character encoding or any character encoding, FAIL
If character encoding is specified in more than one way, and not all values are the same, FAIL
If the document is not valid default character encoding or any character encoding (see 2.3.9 Validity), FAIL
For each resource specified by 2.3.6 Included Resources:
Request the resource
If the HTTP Content-Type header value of the response starts with "text/" but does not specify default character encoding or any character encoding character encoding, warn
PASS
------------------------

[1] http://lists.w3.org/Archives/Member/member-bpwg/2007Jul/0047.html
mobileOK Basic does not require use of UTF-8 in all cases; the test only verifies that you *can* use UTF-8 when requested. At this point we are not in a position to revise the DDC description in Mobile Web Best Pratices, and mobileOK Basic is intended to reflect what is in MWBP. It is useful to encourage all sites to support globally-interoperable encodings like UTF-8, even if they also support a more appropriate local encoding. tocheck
LC-1782 Jonathan Jeon <hollobit@etri.re.kr> (archived comment)
3.6 EXTERNAL_RESOURCES

Currently, the condition value is too small. So it is hard to support normal UI with this condition.

It is proposed to increase the value, about 50 (this value derived from the statistical results of Korean CPs)

PROPOSED TEXT:
------------------------
For each such resource:
Request the resource, and add one to a running count
Add to the count the number of HTTP redirects (HTTP 3xx status responses) that must be followed and authentication requests that must be made until the resource itself is successfully retrieved
If this total exceeds 20, warn
If this total exceeds 50, FAIL
PASS
------------------------

[1] http://lists.w3.org/Archives/Member/member-bpwg/2007Jul/0047.html
1) mobileOK Basic is supposed to be based on Best Practices doc and so we must reflect its values, 2) nothing precludes delivering a 'fancy' experience; mobileOK only asks you be able to create a 'non-fancy' experience, 3) based on Google mobile web data the current numbers are reasonable; we don't yet have data in support of higher limits tocheck
LC-1783 Jonathan Jeon <hollobit@etri.re.kr> (archived comment)
3.16 PAGE_SIZE_LIMIT

Currently, the condition value is too small. It may not appropriate to use in some countries such as Korea.

It is proposed to increase the values, about 50K (this value derived from the statistical results of Korean CPs)

PROPOSED TEXT:
------------------------
If the size of the document's markup exceeds 20 kilobytes, FAIL
For each included resource, as defined in 2.3.6 Included Resources:
Request the referenced resource
Add the size of the response body to a running total (for nested object elements count only the first object that matches the headers specified in 2.3.2 HTTP Request, if there is one)
If the total exceeds 50 kilobytes, FAIL
PASS
------------------------

[1] http://lists.w3.org/Archives/Member/member-bpwg/2007Jul/0047.html
1) mobileOK Basic is supposed to be based on Best Practices doc and so we must reflect its values, 2) nothing precludes delivering a 'fancy' experience; mobileOK only asks you be able to create a 'non-fancy' experience, 3) based on Google mobile web data the current numbers are reasonable; we don't yet have data in support of higher limits tocheck
LC-1693 Laurens Holst <lholst@students.cs.uu.nl> (archived comment)
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.
We allow users to specifiy for the requested document which encoding should be used to nonetheless attempt conformance to mobileOK. In the specific cases that are noted - character set, caching the detail of the test itself makes sure that this is the least preferred option and that a warn in issued if it is the only means by which the authors intentions are indicated. tocheck
LC-1695 Laurens Holst <lholst@students.cs.uu.nl> (archived comment)
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*
> <http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_character_encoding_support>)
> with the |Accept-Charset| header in *2.3.2 HTTP Request*
> <http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#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.
This test covers external resources, which are
possibly outside the author's control. Some members of the group felt strongly that one shouldn't FAIL on account of an external
resource. Whether the resource displays usefully is a difficult question for a machine test to answer, and it may be that checking this aspect becomes a mobileOK Pro test.
tocheck
LC-1696 Laurens Holst <lholst@students.cs.uu.nl> (archived comment)
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.
There are a couple of use cases which are admittedly marginal where this makes sense. It does not seem acceptable to exclude those use cases, no matter how marginal, since they are valid and out of scope for a test on pop-ups. tocheck
LC-1732 Nir Dagan <nir@nirdagan.com> (archived comment)
"3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP

...If (regardless of its stated DOCTYPE) the document does not validate
against the XHTML Basic 1.1 DTD:

If it does not validate against the XHTML-MP 1.2 DTD, FAIL"

Comment:
This does not allow for valid HTML documents. In HTML end tags for elements
declared EMPTY is forbidden, while XHTML requires end tags for all elements.
We do not allow HTML documents, only those that validate as XHTML Basic 1.1 (or XHTML MP). tocheck
LC-1742 Shadi Abou-Zahra <shadi@w3.org> (archived comment)
COMMENT B.2:
- comment nature: [substantial]
- location: All the tests
- current wording: There is no reference to the applicability condition
or prerequisites (when relevant) in the pseudo-code
- suggested revision: Include this applicability rules in the algorithms
when relevant
- rationale: Some times could be not clear when to produce a N/A output
vs. a Pass/Fail one. This is also a good practice for the shake of
completeness in the algorithm
There is no N/A outcome from mobileOK. tocheck
LC-1751 Shadi Abou-Zahra <shadi@w3.org> on behalf of ERT Working Group (archived comment)
COMMENT B.10:
- comment nature: [clarification]
- location: 2.3.10 White space
- current wording: "Several tests refer to white space. White space has
the same definition in this document as in XML. For XML 1.0 [XML10] it
is defined in http://www.w3.org/TR/REC-xml/#sec-common-syn as being:
S ::= (#x20 | #x9 | #xD | #xA)+ i.e. the characters SP, TAB, CR and LF"
- suggested revision: Should &nbsp; entities (#xA0) be considered?
- rationale: This entity is frequently used (and abused) and having a
look at the related test (3.15, 3.17 and maybe 3.12) it makes even more
sense
No change is required as nbsp is used by authors to indicate non-redundant white space, that it has semantic content. Detecting whether its abused or nonsensical gets difficult and is beyond the scope of the current test. tocheck

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


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:43:46 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org