Re: print page number /= current page number in Braille paginatio n.

to follow up on what Pawson, David said:

> 
> If I recall the page numbering discussion came up a while back.
> I objected at first (being print impregnated), but came to accept
> the common sense of the view expressed above.
> 

I know it's not a capability to die for.  But it illustrates a
possible pattern of limitation in the CSS design.  Until I
understand better how pagination and numbering more generally are
going to work in CSS2, I don't really know if this is that hard.

My memory is always suspect.  The way I remember this being left
was various people agreeing that we would use some attribute that
accepts appropriate values in HTML tags to record the print page
number.

I should admit, in a priority sense, this is not a burning issue.
There are lots of functions that other user groups would like
that are of a comparable criticality (nice to have) and don't
work in CSS2 at the present.  Yet I am finding the discussion
with Howcome very instructive for me, and I think he is learning,
too.

> Page numbers support navigation, no more.  Embossed braille is
> weak on navigation, lets leave it at that and seek to support
> navigational access 'on screen'.

Page numbers support passing references with peers using the
print version.

At present the print version of the HTML Specification is not
competitive with real publishing standards because the page
number references are missing in the indices.  We should
recognize that we, as beneficiaries of the superior accessibility
of online hypertext text, want the HTML medium to be accepted as
a competitive "first" medium for authoring over a wider and wider
range of activities.  To get there, the associated print
capabilities including navigation references by page number (as
the CSS2 spec illustrates, n.b.) are an absoute requirement.

While we are doing pagination, I don't yet see why we can't
support inclusion of secondary indices in appropriate places.  
For print-page-number it would be sufficient to have two
things:

     first: add an "index" variable as a peer of "title, chapter,
     section" in the header formatting infrastructure. 

     second: add a capability for dereferencing attributes of
     selected elements, and not just their contents.  The
     definition of the "index" variable in CSS would be 
     an attribute value lifted out of the HTML just as
     the other three variables are now lifted (modulo the
     addition of attribute dereferencing in the "copy" part
     of a variable definition).

The attribute extraction is clearly on the table for discussion
for many other reasons.

The big argument will be about whether HTML+CSS will ever sell
with 100% system-defined names for things like the "title,
chapter, section" variables used in header formatting.  It is
clear that one gets more capable formatting if the user can
define new variables under user-supplied names.  But that makes
the CSS processor more of a compiler.  We have to look at all the
places where you would really rather have a variable declaration
capability, and see if it's worth the heavy hit is processor
complexity.

-- Al

Received on Friday, 7 November 1997 09:52:06 UTC