Re: [CSS3] Generated content: environment variables

fantasai wrote:
> In case you hadn't noticed, publications like books, manuals, and theses
> are increasingly on the Web, and the proportion of printouts that are Web
> pages is near 50%.
 > Why should their printouts have to either look junky or be offered via PDF?

> [X] Allow web pages to use their own headers and footers

That's a cop-out.  Unless you expect the user to keep flipping that preference. 
  I suspect based on a brief informal survey over here (of people who use 
computers but are not involved in web stuff) that what most users want is:

   [X] Allow web pages to use their own headers and footers unless
       they interfere with the headers and footers I care about; when
       that happens either
        ( ) allow their stuff to add to my stuff
        ( ) use my stuff

This should furthermore be the default for the UA, and the decision between 
those two either-or options should happen automatically.  That is, users 
shouldn't need to think about this stuff; it should Just Work.

One problem, of course, is that different users care about different 
headers/footers.  Some people want to make sure that the URL and timestamp are 
on all their printouts (so they can come back to the page and have evidence for 
when they printed it), while others may not care.  And some may want the 
url/timestamp on one-page printouts, but not on a book (which has other 
identifying information, like author/title/copyright year/ISBN).

Frankly, for a book a PDF may in fact be a better solution.  At least if you 
remotely care about things like your typography, where the floats end up 
relative to the text, etc, etc.  And I don't see a problem with that.

Of course you can give the site full control over fonts in CSS (including font 
embedding), full control over pagination, float positioning, headers and 
footers, copy/paste, etc.  But then you're reinventing PDF, and I have to wonder 

> Good information design maximizes the [useful] data-to-ink ratio.

Yes.  Our problem is that we seem to have different definitions of "useful".

> A crufty half-missing URL that nobody will ever type into their web browser is not
> useful data.

Yes, but not all URLs are like that.  From what I can see we're having a hard 
time coming up with a nuanced solution here.  Everyone is making some 
assumptions about what the "common" case is, whereas I think there is no one 
common case here.

> If the date of modification is available, the date of printing is hardly ever useful data.

That first is a huge if.  I'll take the date of modification over the date of 
printing any day, myself.  But I can see situations where the date of printing 
is in fact more useful.  It captures the fact that on that date a later 
modification had not yet happened, which the modification date does not capture.

Perhaps the right approach is to have metadata for the things the page considers 
important, and metadata hints for the things it feels would not be useful to the 
user.  Then the UA can do something like:

1)  Take set of all available metadata elements
2)  Drop the ones the user considers unimportant
3)  Drop the ones the page has hinted are not useful
4)  Add back the ones the page considers important
5)  Add back the ones the user considers important
6)  Drop the ones the user really never wants to see no matter what the page

That leaves the question of placing the resulting information in the headers and 
footers; I'm not sure I have a good proposal at the moment for how to do this in 
a sane way that would make both the user and the author usually happy and never 
make the user unhappy.


Received on Friday, 2 November 2007 20:15:23 UTC