W3C home > Mailing lists > Public > www-style@w3.org > May 2007

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

From: Ladd Van Tol <ladd@criticalpath.com>
Date: Mon, 7 May 2007 11:30:13 -0700
Message-Id: <4B5E402C-32DB-4AAE-878A-91F63AE0793F@criticalpath.com>
Cc: www-style@w3.org
To: Håkon Wium Lie <howcome@opera.com>


On May 7, 2007, at 8:13 AM, Håkon Wium Lie wrote:

> Also sprach Ladd Van Tol:
>
>> 4. Leaders
>>
>> "UAs should attempt to align leader patterns on a page." -- suggested
>> language: "User Agents should attempt to horizontally align
>> corresponding glyphs from the leader pattern between consecutive  
>> lines"
>
> I agree that your text is better. For horizontal text, that is.
> Leaders can also be vertical and the GCPM text was carefully written
> to avoid "horizontal" or "vertical".

Aha, I hadn't thought of vertical text. It makes it a little more  
obscure, but taking out the word "horizontally" would work, and I  
think is better than the original language:

"User Agents should attempt to align corresponding glyphs from the  
leader pattern between consecutive lines"

>> 5. Cross-references
>>
>> It would be helpful to provide a mechanism to treat external page
>> links differently. For many document types, it would be desirable to
>> append "(see page nn)" to only internal destination anchors
>> ("#someid"). An elegant mechanism for specifying this in CSS is not
>> immediately obvious.
>
> Right. A class name will do the trick, but it requires manual labor.
>
> A selector for internal links?
>
>   a[href^="#"]::after { content: "(see page " target-counter(attr 
> (href, url), page) ")" }
>
> However, it wouldn't catch links that are internal but look like they
> are external.

Cool -- I hadn't noticed the new substring matching attribute  
selectors in CSS 3 -- they will probably do the trick for my intended  
use case. Still, it would be nice if there were a shortcut for this  
that also handled the external-appearing internal links.

>> 9.1 Hyphenate properties
>>
>> Should specify allowed format(s) for hyphenation dictionaries -- is
>> this TeX-style dictionaries? Making this UA-dependent would be bad.
>
> Ideally, there would be one common format. In this case, I don't think
> it's realistic to achieve and -- more importantly -- it's not that
> important as hyphenation is a luxury. You can, however, specify a list
> of different resources in different formats.

Since TeX dictionaries have no header, I'm concerned that UAs might  
not be able to infer the hyphenation resource format in all cases. I  
notice that Prince uses TeX-style dictionaries, but does not allow  
for an exception table.

>> 23.2. Index
>>
>> In the example, the dfn tag should read: <dfn class="entry">
>
> In section 23.3, yes. Nice catch.
>
> Did you actually understand section 23? If so, you're among the chosen
> few. Is it useful?

I get the gist of it, and it seems that the prototype container  
mechanism could be very powerful.

The spec definitely needs to be more explicit about each property.  
For example, in the TOC example, is it necessary to specify  
"prototype-insert-position: current"? It seems like current should be  
the default, and the make-element property should cause the insertion  
of the content.

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? If so, the TOC example is wrong, as it  
will copy the header <h1>Table of contents</h1> in front of every toc- 
entry. The same holds for the Glossary example.

A few other comments:

	- The Glossary example should show the appropriate make-element syntax.
	- The Index example should, I think, quote the leader pattern
	- The Index example should show the prototype container
	- Is the content specification in make-element the same as the  
target-text value from Cross-references?
Received on Monday, 7 May 2007 18:31:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:50 GMT