RE: [css3-page] LCWD issue 22 -- [22] Section 3.3.2 <length>

> [Original Message]
> From: BIGELOW,JIM (HP-Boise,ex1) <jim.bigelow@hp.com>
>
> You issue (#22) shown below has been rejected.
>
> > 
> > Why does the page context have no notion of fonts?  Couldn't this be 
> > the same as the notion held by ":root" exterior to this @-rule?  Or 
> > does this introduce some sort of loop that isn't apparent to me? 
> > Granted, specifying page margins with respect to font size may not be 
> > a good thing to do most of the time, but I fail to see why it is 
> > impossible.
> 
> The page context does not have a font associated with it.  The document's
> content as embodied in the body of the document has one or more fonts, but
> the page does not. I don't understand you comment about the ":root"
> exterior.

In your earlier response on this issue [1] you said:

"The page context comes before and is independent of content.
 You don't want to specify the width of the page in points. It's a
 physical sheet of paper, better suited to be described in absolute
 terms. "

However, what the size property is describing is not the size of a page
sheet which is physical, but the size of a page box.  Granted, the usual
intent will be to specify a page box that will occupy a page sheet
exactly, but that is not the only use for specifying the size of a page
box.  Therefore, an author might wish to specify an abstract page box
which the UA will then fit if his intent is to insure that a certain number
of
lines will be printed per page  The mechanism would in essence be no
different from having specified "size:A4" and the UA having to decide
how to print the A4-sized page box on a letter-sized page sheet.
Thus the physicality of the page sheet is not a relevant point.
The only relevant point is "Is there a reasonable interpretation for
the relative  units "em", and "ex" with respect to the page box?"

The root element (in XHTML that would the single occurrence of <html>)
has a font size as determined by the UA if there is no CSS rule that sets
the size or is defined by the cascade if it is not.  That was the font size
I was thinking that could be used to specify the dimensions of a page
box that used "em" or "ex".  Consider the following simple stylesheet:

@page {
size: 25em 17.5em;
margin: 2.5em;
}
:root {
font-size: 24pt;
}

This would make this effectively the same as if @page had been
defined as:

@page {
size: 600pt 420pt;
margin: 60pt;
}

which is allowed by the current interpretation.

The UA will have to determine the value of 'font-size' for the root
element of the document, and this does not involve any of the rules
contained in @page.  This is what I was referring to when I said,
"the same as the notion held by ':root' exterior to this @-rule".

Using this notion does not appear to cause any problems with
determining specified values in the cascade [2] as at this part
of the cascade the @page rule and the rulesets for the elements
do not interact.

At the computed values [3] stage we do have an interaction.
For elements, the computed values for 'height' and 'width' and other
related properties can depend upon the computed value of the
initial containing block which will depend upon the computed value
of the 'size' of the page box. The computed value of the 'size' of the
page box could depend upon the computed 'font-size' of the root
element.  This computed 'font-size' will be an absolute value and will
not depend upon anything other than the specified value of the 'font-size'
of the root element and maybe the default value chosen by the UA.

Thus the only requirement that I can see that is imposed by allowing
"em" and "ex" to be used to express the size of the page box, is that
when determining computed values, the following additional constraint
on the order of doing the determination is imposed.

   Determine the computed value of 'font-size' for the root element.
   before determining the computed value of 'size', 'margin', 'border',
   and 'padding' for the page box.

This does not appear to introduce any inefficiencies upon the
process, altho it does mean that the determination of some
computed values of the page box interact with those of the root
element. (See below for an alternative that avoids even this.)

So unless I am totally missing something here, it would seem that
it should not be impossible (or even difficult) to determine the size
of the page box with respect to font size.  For the page sheet, it
would be ridiculous to talk about specifying the size in terms of
font size, but the page sheet is not what is being specified in this
module.

As a final aside, the statement, "The page context has no notion
of fonts," while true for CSS2 would seem to no longer apply for
CSS 3.  In CSS 2 there was no provision for adding content to
the @page rule.  While it would not makes sense in CSS3 to
add content directly to @page, the margin boxes which are
defined inside the page box do have content which will require
a notion of fonts.  Unless the margin boxes are not considered
to be part of the page context, which would seem to be very 
strange, there is now text associated with the page box,
and there fore it would make sense for the page box to have
a notion of fonts.  After all, why wouldn't  one want to be able
to specify:

@page {
  font-size:9pt;
  counter-increment: page;

  @top-center{ content: "An Example" }
 
  @bottom-center { 
    content: "Page " counter(page);
    content: "Page " counter(page) " of " counter(pages); 
  }
} 

so that one wouldn't have to specify a 'font-size' for each
margin box instead.  If the page box had a notion of fonts,
It might be reasonable for it to have a notion independent
of the root element.  That would enable the page box
to retain its traditional independence from the properties
of the elements of the document tree, while providing
a definition of 'font-size' that could be used to determine
what the "em" and "ex" units refer to in the case of
'size', 'margin', 'border', and 'padding'.

[1] http://lists.w3.org/Archives/Public/www-style/2004Jan/0038.html

[2] http://www.w3.org/TR/CSS21/cascade.html#specified-value

[3] http://www.w3.org/TR/CSS21/cascade.html#computed-value

Received on Monday, 16 February 2004 00:40:39 UTC