Re: [css3-gcpm] Comments on Generated Content for Paged Media 2007-05-04

Also sprach Ladd Van Tol:

 > > I believe exceptions can be encoded into the TeX format. Can someone
 > > help me out here?
 > 
 > I believe that hyphenation exceptions are currently an external  
 > mechanism in TeX, although it's been a long time since I've used TeX.
 > 
 > As far as I understand hyphenation rules, there are supposed to be  
 > two kinds of exceptions:
 > 
 > 1. Positive exceptions that show how to hyphenate particular words,  
 > ignoring the more general rules found in the pattern list (aka  
 > "dictionary")
 > 2. Negative exceptions that show words that can never be hyphenated,  
 > generally due to having more than one proper hyphenation (dependent  
 > on grammatical context)

Right. My hypothesis is that both these exceptions can be encoded as
general rules. In any case, the 'hyphenate-resource' property is
general enough to host both exception lists, generic rules and
dictionaries with embedded hyphenation points.

 > >> One question I had was about the treatment of elements within the
 > >> prototype container that are not prototype entry elements. Are they
 > >> copied for each list item?
 > >
 > > No. For example, in this example, the h2 element is only showed once.
 > >
 > >   ...
 > >   <style>
 > >   #index {
 > >     prototype: container }
 > >   #index-marker {
 > >     prototype-insert-position: sorted
 > >     prototype-insert-policy: unique;
 > >     text-transform: uppercase }
 > >   #index-entry {
 > >     prototype-insert-position: sorted }
 > >   #index-entry::after {
 > >     content: leader(". . ") source-counter(page) }
 > >   dfn.entry {
 > >     prototype-insert: index-marker first-letter, index-entry content }
 > >   </style>
 > >   ...
 > >
 > >   <div id="index">
 > >   <h2>Index</h2>
 > >   <div id="index-marker"></div>
 > >   <div id="index-entry"></div>
 > >   </div>
 > >   ...
 > 
 > So what happens to an ordinary element placed between the index- 
 > marker and the index-entry divs?

Let's see. Say, we now have:

  <div id="index">
    <h2>Index</h2>
    <div id="index-marker"></div>
    <p>foo</p>
    <div id="index-entry"></div>
  </div>

The rendering of the initial state is:

  Index
  foo

Now, say the formatter encounters this element:

  <dfn class="entry">shark</dfn>

two GLEs (generated list elements) are inserted, first one of type
#index-marker and then one of type #index-entry.

After the #index-marker has been inserted, the generated list looks
like this:

  Index
  S
  foo

because only the first-letter (of "shark") is used, and the
'text-transform' specifies uppercase. The "S" appears above "foo"
because the that's where the prototype elements (#index-marker) is
found.

The spec should say that the first GLE element is inserted where its
prototype element is found.

Next, a GLE of type #index-entry is inserted. It also has
'prototype-insert-position: sorted'. The question becomes: sorted
relative to which elements? There are several options:

 a) elements created with the same prototype element
 b) elements created with the any prototype element
 c) any block-level element
 d) any element

I think b) is the correct answer. You want to be able to sort
elements, even if they have diffent styling.

Let's assume b). Then the #index-entry is entered after the "S" (as
"shark" comes after "s" in assumed sorting order). So, we get:

  Index
  S
  shark
  foo

This result may be counter-intuitive as the <p> element comes before
#index-entry in the structure.

The benefit of this approach, however, is that we allow non-prototype
elements inside and don't need to create dummy elements only
consisting of prototype elements. For headings (like "Index") this is
useful -- you will have a <div> arount the whole index (including the
heading), but don't really want a <div> with everything except the
heading.

Does it make sense?

 > > BTW, I have changed the name of the 'make-element' to 'prototype- 
 > > insert'.
 > 
 > This seems better.

Good.

 > > (I'm looking for a better name for the 'prototype' property as well --
 > > now it looks like a shorthand propertye. Calling it
 > > 'prototype-container' would make sense, but I want to avoid yes/no
 > > values. Hmm.)
 > 
 > One possibility might be to call it "prototype-container" and have a  
 > value of "list" to indicate the list-like nature of indexes,  
 > glossaries, and tables of contents. This may also provide expansion  
 > opportunity if somebody comes up with another way to utilize  
 > prototype containers.

Interesting. So, "list" would be the only value in addition to "none".

  prototype: list | none

I like it. I've changed it in my internal version.

I'd like to ask your advice on another proposed name change:
"content" -> "self" or "contents". In the example you quote, one finds:

  prototype-insert: index-marker first-letter, index-entry content

the problem with 'content' is that it's also the name of a property.
I'd like to avoid that, if possible. I see two possible alternatives:
"self" and "contents". "self" is shorter and has not singular/plural
dilemma. "contents" may be more descriptive -- we're copying the
contents of the element, but necessarily its style or structure.

Any advice?

 > >> A few other comments:
 > >>
 > >> 	- The Glossary example should show the appropriate make-element  
 > >> syntax.
 > >
 > > Right. How about this example:
 > >
 > >   ...
 > >   <style>
 > >   #glossary { prototype: container }
 > >   #glossary-term { prototype-insert-position: sorted }
 > >   #glossary-definition { prototype-insert-position: current }
 > >   dfn { prototype-insert: glossary-term self, glossary-definition  
 > > attr(title) }
 > >
 > >   </style>
 > >   ...
 > >   <div id="glossary">
 > >   <h2>Glossary of terms</h2>
 > >   <dl>
 > >     <dt id="glossary-term">...</dt>
 > >     <dd id="glossary-definition">...</dd>
 > >   </dl>
 > >   </div>
 > >   ...
 > >
 > >   <p>The <dfn title="Leading paragraph">introduction</dfn> comes  
 > > first.</p>
 > 
 > Seems good, although this example does assume that each term is only  
 > defined once.

Right, if a term is defined twice, it would end up twice in the
glossary. This is better than deleting the first entry, no?

 > > Thanks for your (continued) review -- it's inspiring to have someone
 > > look into this.
 > 
 > No problem -- it's very interesting, and relates closely to my  
 > current work.

If so, would you know someone who could implement it? I think it's
possible to do it in a preprocessor without doing all the formatting.
That is, you would not resolve page numbers, but create the necessary
links so that a true formatter could resolve them later.

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

Received on Wednesday, 9 May 2007 12:54:31 UTC