Re: [css3-gcpm] New WD: Generated Content for Paged Media

Also sprach Kelly Miller:

 > - - There should be a more specific description of how to get to the text.
 > For example, should all white space be preserved?
 > 
 > I imagine this would be best done with another property related to the
 > strings.  There are situations where both options would be useful.

Perhaps. Could you describe some convincing scenarios? I'd hate to add
a new interdependent property without good reasons.

Another option would be to preserve white space in the content and let
'white-space' property decide how to treat it. E.g.;

  @page { @top-center { content: string(header); white-space: pre }}
  h1 { string-set: header content() }

 > - - However, if the leaders contains any non-white-space characters, white
 > space characters at the beginning and end of a leader must be removed.
 > 
 > If this is so, then leader(dotted) would not be equivalent to leader(".
 > "), because the latter's space would be collapsed.  So I suspect
 > preserving whitespace would be a better option.

Yes, it's also simpler.

 > - - The 'leader()' value accepts an optional second argument to determine
 > from which element property values are borrowed from. The argument can
 > be one of these:
 > 
 >     * 'current': Property values are borrowed from the (pseudo-)element
 > where the 'leader()' value is used. This is the default value.
 >     * 'root': Property values are borrowed from the root element.
 > 
 > Is there a better element to use than the root element? Perhaps the
 > initial value of the various properties?
 > 
 > There was a discussion about adding some sort of naming system to
 > elements.  Maybe use that here?  Also, I'd suggest allowing some sort of
 > id() function, for targetting styles of elements with certain id's.

I like ID's better than introducing named elements. As you see in the
section on Generated Lists, ID values are use on the right side.
However, the current issue (getting uniform sizes for leaders on the
same page) may not in itself require such (relatively) complex
solutions.

 > - - There has been a number of proposals for these names. Instead of the
 > 'position' property, these properties have been proposed: 'flow',
 > 'float', 'display'.
 > 
 > In this case, I believe position is the right option.  Setting something
 > as a footnote IS changing its position in the document, after all.

Agreed, it feels right.

 > - - Should there also be a footnote border style to achieve that solid
 > line that partially extends across the top from the left?
 > 
 > That's the first question that popped into my head after reading that
 > section.  I dunno if using a specific property for that is a fantastic
 > idea, though; more properties = more complex spec...

Yes, I'd rather have it as a value.

 > - - The reason for having a predefined "footnote" counter is to avoid
 > having to set "counter-increment: footnote" every time one sets
 > "position: footnote". However, is this a good enough reason?
 > 
 > In any situation in which counting is expected, I believe there should
 > be an automatic counter built in, and an implied counter-increment.

Agreed.

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

Received on Friday, 16 June 2006 09:19:22 UTC