Core Presentation Attributes

I have read the document titled "Core Presentation Attributes:
Requirement and Use Cases" (CPP) [1] with interest. Since my company
is shipping browsers on many types of devices, including phones and
set-top-boxes, the topics discussed are of interest to me. I'm also a
co-author of the CSS specifications [2][3] and Media Queries [4].

My favorite part CPP is use case #1 in section 5.1 where the UA wishes
to fetch a static image, but not necessarily the version offered by
default. This is a real problem for devices with limited bandwidth:
images on the web are often too large to be displayed. Although the
device can scale images, too much bandwidth is wasted in the process.
Therefore, it is important that UAs can request image variants.
Opera's experience is that the UA's most important request is: send me
image Z, but it would be no wider than X pixels. I suggest adding
maximum widths (and for the sake of symmetry, maximum heights as
well) to the list of requirements.

Target image colors is also, in our experience, useful.

Alternative textual alternatives would be great, but I doubt it's a
realistic scenario. HTML's longdesc attribute hasn't seen much use.

I'm unsure how useful it is to request certain image formats: GIF and
JPEG are the VHS of the web, and I'm not terribly keen on seeing
JPEG-2000 introduced.

My least favorite part of CPP is use case #4 where "a document has
attributes that express its delivery expectations". Further, "an HTML
document has may express to conditions under which this document
should be considered suitable for a particular device context".

This case seems to be very close to what Media Queries already can
express, namely presentational constraints in the documents that flow
"downstream" from the server to the client which makes the final
presentation. The abstract of CPP states that the purpose is to
describe "presentational capabilities of a presentation device". I was
therefore under the impression that the description would flow from
the device "upstream" to the server.

I would find it awkward if CPP takes on the design of a system which
will be completing with Media Queries as long as Media Queries is in
CR stage, and I therefore suggest limiting CPP to upstream uses.

Another use case I have problems with is #2 which describes a "request
for a static formatted (HTML) resource". By definition, HTML is not
static and we should not try to make it static. E.g., it should still
be left to the UA to determine where line breaks should go. Also, I
don't see a compelling use case in the UA requesting an HTML document
with a certain fonts. If devices have limited font resources (which
indeed is the case) they should display documents with the fonts they
have. There is absolutely no need for the UA to request a document in
"sans-serif" or "serif" -- the UA will happily make this choice in the
device.

Use case #3 seems compelling if it can be realized.

Another feature which may seem compelling, but which may end up being
too complex, is the requirement "to group attributes hierarchically".
Having argued for an hierarchical system of properties in CSS, I am
now happy that we ended up with a flat name space.

In general, I think there is important work to be achieved in this
area. The low-hanging fruit is very accessible and the apple tree is
very tall. I therefore suggest aiming for a very simple "upstream"
specification, no more than 10 pages.

[1] http://www.w3.org/2001/di/public/cpa-req
[2] http://www.w3.org/TR/REC-CSS1 
[3] http://www.w3.org/TR/REC-CSS2
[4] http://www.w3.org/TR/css3-mediaqueries/

-h&kon
              Håkon Wium Lie                          cto °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Wednesday, 29 January 2003 10:01:59 UTC