W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > November 2008

Re: [CTG] Draft 2008-11-07 / http-equiv

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 11 Nov 2008 09:52:15 +0000
Message-ID: <491955CF.1040705@mtld.mobi>
To: casays@yahoo.com
CC: public-bpwg-ct@w3.org

Some comments below

On 11/11/2008 09:32, Eduardo Casais wrote:
> a)	HTML
> Section 4.2 states:
> 	"In the following, proxies must check for 
> 	the presence of equivalent <meta http-equiv> 
> 	elements in HTML content, if the relevant 
> 	HTTP header is not present."
> This comes too short, as XHTML and WML content may
> contain such a meta-tag as well. In the case of WML,
> the presence of http-equiv attributes and their 
> processing is actually specified in the corresponding
> standards (notably WAP-191-WML 19 February 2000, and
> WAP-WML 16 June 1999).

It may be worth expanding upon the point that by HTML content we mean 
any content in the HTML family, including XHTML but not including WML. I 
think WML is out of scope of this document - but it's worth having a 
discussion on that.

> b)	Page components
> The http-equiv meta-tag is necessary because there are
> situations where application developers cannot tailor
> the HTTP header returned by the WWW server (e.g. shared
> hosting). However, it must be clear that the meta-tag,
> and the HTTP header field as well, apply to all components
> of the page -- i.e. including images, style sheets, scripts,
> and other dependent content.
> In effect:
> 1. It does not make much sense not to transform the markup,
> but to transform its components.
> 2. Most of the dependent content (in fact everything 
> excluding HTML, XHTML, WML markup) has no way of 
> expressing the directive no-transform with a meta-tag 
> (e.g. a GIF image or a ringing tone).
> 3. Much of these dependent components may not be identifiable
> as mobile-optimized independently; hence, an HTTP request
> accessing them after loading their enclosing markup may not
> provide sufficient context for applying the heuristics in
> the appendix (e.g. GIF/PNG/JPEG images).

Hence clause 3 under 4.1.5 and especially


For symmetry and clarity it would be worth putting a similar clause 
under 4.2 response.

> a)	Link element
> Section 4.2.7 addresses the alternate "handheld" representation
> for HTML markup. This is restrictive:
> 1. This should apply to XHTML as well.
> 2. Ignored are external style sheets.

see above ref "HTML"
> In the case of external style sheets, it is pretty clear that
> those declared as 
> <link rel="stylesheet" type="text/css" href="..." media="all"/>
> <link rel="stylesheet" type="text/css" href="..." media="handheld"/>
> also refer to mobile-compatible, resp. mobile-optimized ones,
> and should be handled accordingly.

Mobile compatible and mobile optimized are not the same thing are they?

> E.Casais
Received on Tuesday, 11 November 2008 09:53:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:30 UTC