Re: [CTG] Draft 2008-11-07 / inconsistencies / validation

I think that Rotan captured the reason for the SHOULD in the existing 
text but I think also that unless we can think of examples where 
well-formedness breaks existing devices that we should consider 
Eduardo's suggestion carefully. However, when we step away from XML, 
doesn't that lead us into a number of problems? For example, on the same 
point in mobileOK, we had to dance around a little on CSS, GIF, JPEG and 
even UTF-8 ...

http://www.w3.org/TR/mobileOK-basic10-tests/#validity

and what do we mean by well-formed HTML (this time without the X)?

Jo

On 11/11/2008 12:17, Eduardo Casais wrote:
>> Consequently, in order to satisfy the need to give
>> excellent end-user experiences, we must (sadly) adjust
>> our adapted output to suit the quirks of the requesting
>> device, thus addressing the bugs/features that
>> we know to be present.
> 
> You are actually raising two points:
> a) extensions to existing standards (i.e. additional features that are not captured by standard W3C, IETF, etc formal specifications);
> b) errors, i.e. deviations from the supposedly supported formal specifications.
> 
> Regarding point (a), vendors usually make available a formal definition of their extended features (otherwise how would developers use them?), but we can admit that there is no general guarantee that there is a published formal specification that can be used for validation.
> 
> Regarding point (b), you are thinking about issues like, say, a browser that accepts <p> inside <div> but not otherwise, although this is possible as per (X)HTML DTD. This is the nasty part, and I agree this is usually deduced from  testing, not from some formal spec. 
> 
> Can we state that the transformed content returned to the terminal must at least be well-formed (following XML terminology)?
> 
> E.Casais
> 
> 
>       
> 
> 
>

Received on Tuesday, 11 November 2008 12:43:24 UTC