Re: False positives with the mobileOK validator

Hi Kevin,

Sorry for the late response, and thanks for your comments. See some 
clarifications below.


Kevin Ghadyani wrote:
> If CSS is supposed to allow images to have height and width values 
> associated with classes or IDs, why does the mobileOK validator just 
> completely over look this? I always wind up having issues with the being 
> no height and width values even though I have them set in the stylesheet.
> 

That is a good point.

There are three reasons why it's usually better to precise width and 
height values for images in the markup itself:
- the device may not support CSS, but Most devices that support XHTML 
also have some basic support for CSS though.
- the user may have disabled CSS styles, but most mobile devices do not 
offer that possibility at all (many provide the option not to load 
images, which is not exactly the same thing).
- some mobile browsers may start rendering the content before the CSS 
stylesheet is available, but I suspect that's not the rule (plus note 
reflows would affect more than just images in that case).

In short, I do not think you are doing something utterly wrong here. It 
is a minor point, reported by the Checker as a low-level error to follow 
the IMAGES_SPECIFY_SIZE Mobile Web Best Practice:
  http://www.w3.org/TR/mobile-bp/#IMAGES_SPECIFY_SIZE

The important part of the best practice is indeed that the dimensions of 
the images should be explicitly available to the browser for rendering 
purpose. I note as a possible enhancement to the Checker that it would 
be useful to detect the case when the dimensions of the images are 
defined in the CSS rather than in the markup.



> I suddenly got another problem with one of my stylesheets showing up as 
> not syntactically valid, but when I use the CSS validator, it works just 
> fine as do all of my other stylesheets. In fact, the only thing I've 
> done thus far to change things on my website is add in a mobile.css file 
> along with the master.css file which is called whenever someone's on the 
> mobile site. Since it validates properly, I figure it shouldn't pull up 
> errors either in the mobileOK validator.
> 
> It noted this:
> The style sheets contain syntax errors, and thus are likely to create 
> problems with some browsers.
> Use the W3C CSS Validator to find and correct CSS syntax errors.
> Triggered  by http://m.kevinghadyani.com/mobile.css.
> 
> Related best practice:
> [CONTENT_FORMAT_SUPPORT]
>         Send content in a format that is known to be supported by the 
> device.
> But my CSS file is only 4 entries that properly validate:
[...]

I need to investigate here. There seems to be a bug triggered by the use 
of the UTF-8 BOM as your CSS starts with the "EF BB FF" UTF-8 
Byte-Order-Mask. This is absolutely correct, and I cannot reproduce the 
issue locally, which seems to indicate the error is linked to the server 
somehow. I'll keep you updated on that one!



> And then it goes ahead and makes a comment of about the set height and 
> width in my master.css which, surprisingly, has the height and width 
> values of the images it claimed I was lacking.

Yes, IMAGES_SPECIFY_SIZE and MEASURES are conflicting best practices as 
explained in the Mobile Web Best Practices specification:
  http://www.w3.org/TR/mobile-bp/#MEASURES
Since the Checker ignores the definition of the width and height of 
images in the CSS, it doesn't know that such properties are used for 
that purpose, and thus triggers the MEASURES low-level error.



> Then it warns me that I don't have the right character encoding or 
> something like that. It's actually quite confusing to understand: "The 
> resource does not specify UTF-8 as character encoding". The validator 
> for XHTML 1.1 and XHTML-MP 1.2 both don't throw up warnings for this, 
> and it's actually in my code <meta http-equiv="Content-type" content="<? 
> meta() ?>;charset=utf-8" /> so I don't know what the mobileOK validator 
> is complaining about.
> 

As mentioned in the HTML 4.01 specification, "META declarations should 
appear as early as possible in the HEAD element":
  http://www.w3.org/TR/html4/charset.html#h-5.2.2

mobileOK goes beyond that recommendation and only takes into account a 
character encoding declaration when the "meta" element is the *first* 
child of the head element. The reason behind this is that characters 
that may appear in a "title" element for instance need to be decoded as 
well in order to reach the character encoding declaration, and thus the 
character encoding declaration might be missed if the title contains 
"weird" characters. Whenever possible, declaration of the character 
encoding at the HTTP level should be preferred.

That said, the error message needs to be clarified, to be sure! I added 
that to the Checker's TODO list.


> Most other validators and analyzers have this problem too, but it seems 
> like it should be corrected.
> 
> It notes my master.css file has position:relative in there 3 times. 
> That's correct. I'm unsure if I actually need those in my master.css 
> anyway, but since my site works fine on all devices I've tested on, I do 
> not know if it's safe to remove it. This warning is repeated when it 
> states: "The CSS Style contains at-rules, properties, or values that may 
> not be supported" and shows me the 3 lines that says "position" in the 
> master.css file.

The first warning alerts you that using position, display or float on 
mobile devices with limited screens may not be a good idea.
The second warning alerts you that the "position" property is not 
defined in CSS Level 1 and may not be understood by some mobile devices 
(the property should be ignored in that case). The reason why CSS Level 
1 is used instead of CSS Level 2.1 is that many mobile devices only have 
support for a restricted set of CSS properties that more or less matches 
CSS Level 1.



> There's an image error because my images are PNG instead of GIF or JPEG. 
> I'm fine with that because out of the multitude of devices I've used, 
> PNGs work fine if only a bit messy if transparency is used so this error 
> I'd prefer to see as a warning but it's fine.

There is no planned revision of the mobileOK specification for the time 
being, but this topic is definitely on the table. Some mobile devices in 
Japan still don't support PNG though, AFAICT.



> It has another complaint about character encoding: "The HTTP 
> Content-Type header does not specify a character encoding and no UTF-8 
> encoding or a non-UTF-8 is specified in the XML declaration". I assume 
> my lack of an <?xml ?> character encoding declaration is the problem 
> even though I have UTF-8 specified in the HTML? From reading the W3C's 
> reports, it seems like the <?xml ?> header is negligible and a problem 
> to IE uses of all kinds, that's why the standard was rectified to allow 
> the DOCTYPE first. If needed, I can use PHP to fix it so only IE doesn't 
> display it since I have IE to render the page as text/html anyway.
> 

The complaint is more generic and just says no character encoding 
declaration could be found. See discussion above.



> I get an error that says I am using "no-cache" or "max-age=0". In fact, 
> that's wrong: <meta http-equiv="Cache-Control" content="max-age=64000" 
> />. It complains about Pragma, but I don't even use that or know it's 
> usage. It says my Expires header contains a date in the past even though 
> I don't use it either. Both say "Triggered  by the resource under test." 
> I have no clue what that means.

Your page contained was served with a Cache-Control HTTP header on top 
of the meta declaration. The HTTP header has precedence over the meta 
declaration. There should have been another warning along the lines of 
"An HTTP response header that matches the meta http-equiv element exists 
but their values differ".

Note that whenever possible, prefer caching directives that use HTTP 
headers to caching directives defined using meta elements, as network 
caches often operate at the HTTP-level and will not "see" the meta elements.



> The page is served as:"application/vnd.wap.xhtml+
> xml" but it asks for "application/xhtml+xml". Is it wrong to serve 
> XHTML-MP 1.2 as "application/vnd.wap.xhtml+xml"?

"application/vnd.wap.xhtml+xml" has not been officially registered 
within IANA:
  http://www.iana.org/assignments/media-types/application/
... and should be replaced by "application/xhtml+xml". That said, it is 
not wrong to serve your content as "application/vnd.wap.xhtml+xml" and 
the Checker only reports a warning.



> I'm pretty sure it's just me, and that I've done something screwy on my 
> end, but truth be told, if I don't say anything, an actual validator 
> issue could go overlooked.

It's not just you, many thanks for your comments! :-)

Francois.

Received on Tuesday, 28 July 2009 10:14:57 UTC