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

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-1710: Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message); Context: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE; Status:
assigned to Sean Owen; 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:
> 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?; Related issues: (space separated ids); WG Notes:; Resolution: XHTML Basic 1.1 is what's assumed and required, which should be served as application/xhtml+xml, but may be served as these other types. That's the reasoning behind the warn.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1713: Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message); Context: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE; Status:
assigned to Sean Owen; 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:
> 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?; Related issues: (space separated ids); WG Notes: Here, it's because the DDC isn't defined to assume PNG support, and the reason for that is noted above. (JR) Proposed Resolution: The DDC is defined as not supporting PNG consequently it does not indicate support for PNG in the request. Consequently receipt of PNG causes a FAIL.; Resolution: The DDC is defined as not supporting PNG consequently it does not indicate support for PNG in the request. Consequently receipt of PNG causes a FAIL. At the time the DDC was specified there was consensus that PNG was not widely enough supported on devices.; (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; Status:
assigned to Sean Owen; 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:
> 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?; Related issues: (space separated ids); WG Notes: Right, we're asking content to go ahead and specify the default to give every possible hint to the UAs, and stop them from ever trying to second-guess the default and choose another encoding. JR: Plus if the encoding is not specified in the HTTP Header then that can mean that a non-UTF-8 default could be inferred. So we require explicit definition of the encoding somewhere.; Resolution: Right, we're asking content to go ahead and specify the default to give every possible hint to the UAs, and stop them from ever trying to second-guess the default and choose another encoding. Plus if the encoding is not specified in the HTTP Header then that can mean that a non-UTF-8 default could be inferred. So we require explicit definition of the encoding somewhere.; (Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-1698: Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message); Context: Document as a whole; Status:
assigned to Sean Owen; 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:
> 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.; Related issues: (space separated ids); WG Notes: It doesn't actually prescribe tests or expectations on user agents of course, so I'm not worried that anyone will get too far when looking for mobileOK user agent requirements. But you are saying that by defining what a minimal mobile user agent looks like, a profile which is safe to assume, and then what content for that minimal profile is like, you in turn imply what it's safe to assume a device needs to support -- and possibly disincentivize manufacturers from creating more capable devices. For example, by declaring that sites should be able to deliver UTF-8 content foremost, you maybe send a message that it's not as important to support other encodings. That could be so, though it's probably not true that saying sites should only assume a display 120px wide would ever discourage someone from making a phone with a bigger screen. It's necessary to pick some baseline. We've tried to make it clear throughout that there are no tests on user agents here and that the tests merely determine whether you seem to be able to accommodate a really minimal phone when you see one. Too true. We create the badge as an incentive for following the guidelines, to reward adoption. That's OK -- the problem comes when passing the tests requires doing something actually harmful in the end. I hope this doesn't happen. It's for this reason that we've been a little more inclined to create warnings rather than failures. If practice shows that some of the tests are causing this problem, well, they will be fixed. For what it's worth, the labeling part of the specification will come later. For now, there is no real badge.; Resolution: Proposed Resolution: 1. In practice, the draft is implying expectations about UA behavior. In order to test Web sites some UA behaviour must be exhibited, there is no implication that ALL UAs should exhibit this behavor. 2. 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. That is a concern. We make it clear that enhanced experience should be made available and that all experiences should be tested on real phones. Neither of those considerations devalues the need for a test for suitability for a very basic device.; (Please make sure the resolution is adapted for public consumption)

Comment LC-1719: Commenter: Ben Cerbera Millard <cerbera@projectcerbera.com> (archived message); Context: Document as a whole; Status:
Not assigned; 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:
> 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.; Related issues: (space separated ids); WG Notes: The reason the recommendation talks about XHTML Basic is not because it's XHTML, but because of the "Basic" part. XHTML Basic defines a subset of XHTML that is suitable for the mobile context (and yes here I acknowledge the debate about whether XHTML Basic should even exist). It's convenient to advocate use of this existing standard because of it's mobile-oriented nature, not because of any XML-related features. The alternative is to, I suppose, define HTML Basic, which seems unnecessary. As you note, many browsers are just parsing XHTML (Basic) as HTML anyway. > 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? Maybe -- the focus here is on the content side rather than user agent side. I believe user agents have matured a little faster than the content -- it's not that we're lacking decent mobile browsers but that we're lacking plenty of good, usable mobile content. Hence the focus on content rather than user agents. > 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. Advise against HTML or PNG? nothing in the specification says this. The spec advocates XHTML Basic (Basic being the key part there, not the X) and GIF and JPEG since PNG isn't as widely supported.; Resolution: Our understanding and experience is that XHTML Basic delivered with the content type application/xhtml+xml succeeds in the largest number of cases. Our objective is not to specify improvements to mobile devices, though we hope that happens, it is to help content providers achieve a functional user expeirences on the widest range of mobile devices. We encourage content providers to work towards a harmonised experience on devices that have more advanced capabilties.; (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; Status:
assigned to Sean Owen; 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:
> 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. :-); Related issues: (space separated ids); WG Notes: I don't think this is true -- like you and other power users I usually have a pretty advanced phone but in developing nations (like, ah, the United States), the DDC reflects about what brand-new entry level phones can do. See for example the Nokia 6215i (http://www.nokiausa.com/phones/6215i/0,7747,feat:1,00.html) Yes, this profile doesn't reflect the latest and most capable mobile phones today, far from it. It reflects roughly mid-level phones from the past 5 years to entry-level phones of today -- what "most" mobile users in the world might have available to access the web. Again i think it's entirely reasonable to say "these devices just aren't viable web user agents". They aren't. They need special consideration. I believe it's reasonable to talk about how to use existing standards to bring some access to these devices, especially given that it most benefits parts of the world where mobile access is more prevalent than PC access, and that is often the developing world. (JR) Proposed Resolution:; Resolution: The DDC is defined as the minimum specification for a device which can provide a usable user experience of the Web. As such it has enduring value irrespective of considerations of availability of increasing capabilities of devices in some markets. Our understanding is that such devices represent the only means of access to the Web in some areas of the world. It it arguable that even in markets in which more capable devices are common, people will choose not to carry such devices all the time and may wish to use alternative lighter weight solutions more appropriate to the context (sport, leisure etc.); (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; Status:
assigned to Sean Owen; 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:
> 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].; Related issues: (space separated ids); WG Notes: cHTML didn't take off? I think Japan begs to differ, and I think it's an example of how very limited access can still be useful. I believe we're seeing the same adoption finally start to sink in in Europe (with XHTML MP / Basic content). I don't think it's true that the mobile devices that are in most people's hands now can handle anything like full HTML. My relatively not-ancient Motorola V710 sure doesn't. I don't think this distinct "mobile web" will exist indefinitely -- usable full-web devices will become more common -- but it will be here in 5 years. Please push for these full-web portable devices, since it's the long-term future. The short-term future concerns what people have now, and those are little WAP phones. The W3C can and should have a role and voice in this phase of mobile web evolution, even if it's just a phase.; Resolution: Proposed Resolution: We perceive a need for use of Basic today - note that cHTML is an example of successful mobile markup. It's possible that this need will disappear in the future. If it does, then the need for that specification will diminish.; (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; Status:
assigned to Sean Owen; 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)

Comment LC-1697: Commenter: Henri Sivonen <hsivonen@iki.fi> (archived message); Context: Document as a whole; Status:
assigned to Sean Owen; 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:
> 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.; Related issues: (space separated ids); WG Notes: This is a central question indeed. The very existence of the Best Practices Working Group assumes an answer to this question, that the Mobile Web does need to be approached differently, if at all. If you disagree with this, I think you'll disagree completely with all group output. My personal view is that we will not be able to bring anything really like the full web to a device with a tiny screen, no pointer, and no keyboard -- regardless of server-side magic. We are talking about low-end phones, not elite smartphones. Either you believe that the web simply shouldn't come to such devices at all, or you believe in approaching it differently, in designing specifically for this context. There are in fact areas of the world where people have phones more often than they have PCs, and so would like to think about ways to support these users, at the least. In the meantime, yes, let's talk about how portable we can make a full web experience. I further do not believe that talking about designing specifically for lesser mobile devices harms this effort in practice. At least, I would hope to convince everyone here that the BPWG is not dangerous.; Resolution: The draft does not require mobile-specific content. It describes certain requirements for content (which can be served to the web at large) in order for that content to work even on basic mobile devices. Whether this is achieved by having simple content (one possible approach) or by adapting server side adaptation, or by use of client side capability like @media rules and object elements, or some other mechanism is left completely open to the content provider. This allows the content provider to choose the approach to ensuring their content works on mobile that best suits their situation, without forcing them to develop a specific mobile version.; (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; Status:
assigned to Sean Owen; 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:
> 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.; Related issues: (space separated ids); WG Notes: For what it's worth, the labeling part of the specification will come later. For now, there is no real badge.; Resolution: There is work in progress which will create guidelines for the usage of mobileOK logos and trustmarks. For now, there is no real badge. We create the badge as an incentive for following the guidelines, to reward adoption. That's OK -- the problem comes when passing the tests requires doing something actually harmful in the end. It's for this reason that we've been a little more inclined to create warnings rather than failures.; (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; Status:
assigned to Sean Owen; 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:
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.; Related issues: (space separated ids); WG Notes:; Resolution: We accept that real browsers have to adopt many heuristics and take a pragmatic approach. The intention of mobileOK Basic is to point out to content providers that mislabeling the content is an error. We certainly do not endorse the mislabeling.; (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; Status:
assigned to Sean Owen; 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:
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.; Related issues: (space separated ids); WG Notes: mobileOK Basic tests whether a resource can be delivered in a way that is compatible with an abstract baseline device profile, the "Default Delivery Context". This profile only assumes GIF and JPEG support, so it would be undesirable for a mobileOK Basic tests implementation to send a header that says that PNG is supported. The test demands that you demonstrate support or GIF or JPEG, so it doesn't help to add more types. But this is not to say that mobileOK resources can't return PNG or SVG images to other real devices! mobileOK Basic says nothing about what you do for more capable devices. It merely wants to see that you can support a certain basic device that only knows JPEG and GIF.; Resolution: The basis on which the spec is written is that a checker emulates a hypothetical device - the DDC - which has exactly the capabilities specified. The tests ensure that a Web site is capable of responding to the needs of such a device. We encourage content providers to support more than the needs of the basic device and take advantage of greater functions and capabilities where they can.; (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; Status:
assigned to Sean Owen; 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:
> 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.; Related issues: (space separated ids); WG Notes: I don't follow this point -- this part is just describing what is considered whitespace for purposes of counting extraneous whitespace.; Resolution: Proposed Resolution: If a document describes itself as XML 1.1 and passes the other tests then it is eligible for mobileOK. (status changed to resolved partial to reflect resolution on LC-1716); (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; Status:
assigned to Sean Owen; 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:
> 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.; Related issues: (space separated ids); WG Notes: No DOCTYPE means the document can't distinguish itself as mobile, which goes back to the first point here I suppose. It is at the very least required by XHTML Basic so should be kept for that reason. Dollar substitution -- you're referring to WML? that's out of scope. Only XHTML Basic 1.1-like documents here.; Resolution: It is not in our remit to alter existing specifications or to create new specifications. Since XHTML Basic and XHTML MP both require a DOCTYPE to be specified so do we. If dollar-substituion is a reference to WAP 1.x and WML, then that is out of scope for mobileOK at the moment.; (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; Status:
assigned to Jo Rabin; 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:
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; Related issues: (space separated ids); WG Notes:; Resolution: Change GET to POST in this section as indicated; (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; Status:
assigned to Jo Rabin; 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:
| 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.; Related issues: (space separated ids); WG Notes:; Resolution: That is a typo, thanks for pointing it out.; (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; Status:
Not assigned; 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:
| 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.; Related issues: (space separated ids); WG Notes:; Resolution: That is a typo, thanks for pointing it out.; (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; Status:
assigned to Sean Owen; 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:
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:; Related issues: (space separated ids); WG Notes:; Resolution: Thanks that was indeed a typo; (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; Status:
assigned to Jo Rabin; 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:
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:; Related issues: (space separated ids); WG Notes:; Resolution: Thanks, yes.; (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; Status:
assigned to Jo Rabin; 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:
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"; Related issues: (space separated ids); WG Notes:; Resolution: Change GET to POST in this section as indicated; (Please make sure the resolution is adapted for public consumption)

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

Add a comment.