Re: [Fwd: Questions on Checker]

I'm not sure that this is in tune with the logic of avoiding absolute 
positioning and size ... I think that in any case, on reflection, that 
setting an absolute height on an hr is something that is likely to have 
unforeseeable effects - I'm not sure of the meaning of an hr that is has 
a non-default height ... though perhaps there's some documentation 
somewhere ... but on the whole I regret having raised this and think we 
should drop it.

Jo

On 10/07/2008 09:10, Abel Rionda wrote:
>> I am still sceptical that an absolute pixel measure on the height of an
> 
>> hr element is unacceptable. However an absolute width would be. To fix 
>> it would mean going to version 45 of mobileOK, which I am reluctant to 
>> do ... but ...
> 
> Yes, I agree that an absolute height value should not raise a FAIL
> (since the DDC only specifies a maximum width)
> A quick solution would be exclude the height property from MEASURES
> tests
> (as we are currently doing with border, margin and padding properties).
> 
> Abel.
> 
> -----Mensaje original-----
> De: public-mobileok-checker-request@w3.org
> [mailto:public-mobileok-checker-request@w3.org] En nombre de Jo Rabin
> Enviado el: jueves, 10 de julio de 2008 9:44
> Para: Francois Daoust
> CC: Sean Owen; public-mobileok-checker
> Asunto: Re: [Fwd: Questions on Checker]
> 
> 
> Hello Sean! And thanks Francois for pointing out that the wrong document
> 
> was being checked.
> 
> I am still sceptical that an absolute pixel measure on the height of an 
> hr element is unacceptable. However an absolute width would be. To fix 
> it would mean going to version 45 of mobileOK, which I am reluctant to 
> do ... but ...
> 
> Jo
> 
> On 10/07/2008 08:17, Francois Daoust wrote:
>> Sean Owen wrote:
>>> (Is the document returned to a desktop browser the same as what is
>>> returned to the checker? maybe so, but I have not checked this.)
>>>
>>> I wonder, do we check for "UTF-8" in a case-insensitive way? well
>>> there's a bug if we don't.
>> We are, AFAICT. I see checks with "equalsIgnoreCase" all over the
> place...
>>
>>> The error is on a style with selector ".hr" which isn't used in the
>>> main doc. Is that still an error?  yeah I think so. If it's not used,
>>> it shouldn't really appear anyway in the response to a mobile
> request.
>>> I don't think it's necessary to get into deciding whether the rule is
>>> used. It's still valid to flag this one.
>> I think so as well.
>>
>>> On Wed, Jul 9, 2008 at 5:21 PM, Jo Rabin <jrabin@mtld.mobi> wrote:
>>>> I just ran
>>>>
>>>>
> http://validator.w3.org/mobile/?docAddr=http%3A%2F%2Fwapreview.mobi%2F
>>>> and was surprised to see the character encoding error. Looks to me 
>>>> like the
>>>> xml declaration does specify utf-8.
>> The checker that is at http://validator.w3.org/mobile is still the
> beta 
>> version. There's one bug in there about redirections that was fixed
> not 
>> so long ago.
>>
>> http://wapreview.mobi/
>> ... returns a 302. The HTML body response of this 302 triggers the
> error 
>> (Apache typically sends 302 responses encoded in ISO-8859-1 IIRC, and 
>> there's no easy way to change that behavior). But the checker should
> not 
>> check the response.
>>
>> Typically, the error is not returned when checking:
>>
> http://validator.w3.org/mobile/?docAddr=http%3A%2F%2Fwapreview.mobi%2Fwp
> -mobile.php 
>>
>> Dom fixed the bug in the library.
>> I'll update the checker used http://validator.w3.org/mobile when we
> get 
>> a v0.99999 version. Hopefully today.
>>
>> Francois.
>

Received on Thursday, 10 July 2008 11:34:24 UTC