Re: Validator

On Thu, Aug 27, 2009 at 12:47 PM, Francois Daoust <fd@w3.org> wrote:
 >style.asp is served with a "text/html" content-type. I suspect your
 >server is configured to map ".asp" files to "text/html" and ".css"
 >files to "text/css". You can check that yourself with a browser
 >extension such as Firebug for Firefox or with a network packet
 >sniffer such as Wireshark.
 >
 >All desktop browsers and most mobile browsers probably ignore
 >the content-type because they expect CSS and will try to parse
 >the file as CSS anyway. That would still be better to set CSS
 >content-type as "text/css".

This may be true, since I'm using a hosting service, which I have no control
over how they configure their IIS Server.

 >The mobileOK Checker fails to identify the doctype because it is invalid.
 >It is invalid because you are using a "PUBLIC" doctype, and in that case,
 >a system identifier must follow the public identifier, as defined in the
 >XML spec:
 > http://www.w3.org/TR/xml/#NT-ExternalID
 >
 >The error in the doctype is returned by the mobileOK Checker as a
not-so-clear
 >markup validation error: "White spaces are required between publicId and
 >systemId". Not finding a valid DOCTYPE, the mobileOK Checker also triggers

 >the "no doctype found" error, which is a bit awkward, I must say.
 >
 >Two things are worth noting here:
 >1. I do not know at this point why the markup validation service does not
 >complain about your doctype declaration. It may be that such doctype
 >declarations are possible in HTML 4.01, but I couldn't find any
 >information in the relevant section of the HTML 4.01 spec:
 > http://www.w3.org/TR/html4/struct/global.html#h-7.2
 >I need to investigate.
 >
 >2. It is extremely hard to report error messages as they should be
 >reported so that a human being can understand them :(

It doesn't like PUBLIC?  I went to google.com/m to see how they use it, and
they are using public.  I copied their line and pasted it in place of mine
and I think it breaks MobileOK.  The results ani-image is moving, but it
never goes to the next page.  I removed the DOCTYPE and it works, added it
back and it freezes again.   Google uses:
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "
http://www.wapforum.org/DTD/xhtml-mobile10.dtd"><http://www.wapforum.org/DTD/xhtml-mobile10.dtd%22%3E>
Now, this completely messes my site up, so I removed it again.
I thought I understood the meaning of doctype, but I must be missing
something, even still.

 >Neither the HTML page nor the CSS page contain any character encoding
 >declaration. This means browsers need to "sniff and guess" the encoding.
 >Most of the time, they will just get it right, in particular when
 >documents are written in English because they won't contain any
 >"weird" character.
Ok, after that being said along with the information mentioned above, I'm
noticing that MobileOK is looking at more of what the server says, rather
than the code within the page says.  I'm not so sure this is a good idea or
why we have HTML tags that are ignored, since most people like myself use a
hosting provider and have no control over how the server is configured.
That being said, I added a Header of ContentType within my server side code
and it cleared up some of the errors.   I did this for all my pages as well
as the style sheet.

Note: MobileOK, has the message of:
The document is not served as "application/xhtml+xml"

No where do I specify it is, so why would it be looking for ASP pages to be
served as an application?   If I set my pages to this, it prompts to
download the page instead of displaying them.

 >Any text file transmitted on the network should define its encoding,
 >be it a CSS file or an HTML document. Probably something like 99.99%
 >of all styles written in CSS files use regular ASCII characters that
 >happen to be encoded the same way in most encodings, so that's not
 >such a big deal as far as CSS is concerned.

 >The CSS specification explains that other encodings may be used when
necessary:
 > http://www.w3.org/TR/CSS21/syndata.html#escaping

I got another error, before MobileOK stopped working all together for me.

Received on Thursday, 27 August 2009 18:55:44 UTC