Re: Validator

 Actually I had:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"*http://www.w3.org/TR/html4/loose.dtd*<http://www.w3.org/TR/html4/loose.dtd>">


However, it change my whole site. All the font went to tiny, but only with
some pages.  No matter what I did to the style sheet, it didn't changes all
the pages. It's as if based on data within the page, parts the style sheet
were ignored.  However, they all use the same header info since it's a
shared include file. I got frustrated after about 20 minutes and quit trying
and went back to what worked.
On Mon, Aug 31, 2009 at 2:22 AM, Francois Daoust <fd@w3.org> wrote:

> Gavin Landon wrote:
> [...]
>
>> It doesn't like PUBLIC?
>>
>
> It does like PUBLIC but, when PUBLIC is used, the system identifier (the
> HTTP address at the end of the DOCTYPE) must be set. In your case, the
> correct DOCTYPE would be:
>
>  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "
> http://www.w3.org/TR/html4/loose.dtd">
>
> instead of:
>
>  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>
>
> I went to google.com/m <http://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.
>>
>
> If you say your page follows the XHTML Mobile 1.0 DTD whereas it follows
> the HTML 4.01 Transitional DTD in practice, things are likely to break, yes.
>
>
>
>
>  >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.
>>
>
> I note I should complete the error description to explain that authors may
> not have access to internal server configuration settings, but I'm not so
> sure I understand why it would not be a good idea to alert authors about
> things that could have an impact on the final user experience on mobile
> devices. Even if you do not have any kind of control over the server
> configuration, you could:
>  1. talk to your hosting service.
>  2. switch to another hosting service that allows you to change some
> settings.
>  3. at the very least, know why, say, your content takes some time to be
> displayed on mobile devices if caching is not allowed in the HTTP headers.
>
>
>  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.
>>
>
> In the desktop world, IE does not support this media type, which probably
> explains why you are prompted to download the page. Other browsers usually
> support this media type.
>
> The message is a warning. A warning may mean: please have a look, this may
> *or may not* be relevant to your content. In your case, it does not make any
> sense to serve HTML content with an XHTML content type.
>
> I will try to detect when the underlying content is HTML content and come
> up with a clearer warning description.
>
>
> [...]
>
> Francois.
>



-- 
Gavin

Received on Monday, 31 August 2009 14:11:51 UTC