RE: [css3-page]: Comments on pages media -- issues 40, 41, 32, an d 43

Werner, 

The following comments that you wrote in [1] have been assigned issue
numbers 40 - 43 and will be addressed in the coming days:
 -- Jim Bigelow, Editor

[1] http://lists.w3.org/Archives/Public/www-style/2003Sep/0114.html

Issue 40:
> 1) Printable and non-printable areas
> 
> The size of the non-printable area is user agent defined. In 
> some cases this will cause text to really stick to the edge 
> of the paper. It does in any case make the page layout less portable.
> 
> I think that the margin boxes should not be in the page 
> margin. The margin boxes should be region boxes and what is 
> now the page-area should be the body region. The page-area 
> would then contain all the regions and the margins would be around it.
> 

Issue 41
> 2) Media Queries
> 
> I'm not sure if expressing page layout in terms of a 
> conditional page size has so much added value. I assume this 
> is for page sizes which are set from outside by the user 
> agent. One can cope with that using relative values. The 
> cases where this is not good enough are, in my opinion, 
> locale related. Wouldn't it therefore be more useful to 
> combine this with the pseudo class :lang for @page rules?
> 

Issue 42
> 3) Margin at-rules
> 
> It is not clear to me which are the properties that apply to 
> these rules. The examples seem to suggest that only the 
> content property is allowed. This is confirmed by the way the 
> margin box sizes are determined. As I understand it this is 
> driven by the actual content of the boxes. This is a 
> bottom-up approach. Wouldn't it be useful to also provide 
> top-down constraints such as the width for top-boxes? How 
> else can one deal with situations where the pieces of text 
> are somewhat longer and might overlap?
> 

Issue 43
> 4) Populating margin boxes
> 
> The string-set property, combined with the page-policy, can 
> be used to provide content for the margin boxes coming from 
> the document itself. The content function, which is available 
> in the string-set property, is however not specified. My 
> understanding is that it can capture text from within an 
> element. This is not enough for the margin boxes, because 
> then it is impossible to say how this text should layed out 
> in the margin boxes. It is also not an option to take over 
> the properties that apply to the text which was captured, 
> because very often the style is different in the running 
> headers and footers from the style in the document itself.
> 
> I propose to introduce the formatted-set property. It could 
> be applied to any element. The effect would be that it would 
> be set with the formatted result of that element, even if its 
> display type is "none", which would be the case in practice 
> if the destination is a margin box. In the latter case the 
> element would not be visible in the document flow, but would 
> contribute to formatting elsewhere. The "formatted" function 
> would produce the formatted result, just like the string 
> function produces the captured string. In this proposal the 
> string-set property and string function would remain very 
> useful to populate these special elements.
>

Received on Sunday, 8 February 2004 00:08:31 UTC