Re: pause-before property for presentations

On Fri, 12 Jul 2002, Ian Hickson wrote:

> Dave Raggett wrote:
> > The most common build effect is to reveal the 
> > next bullet point upon user action (hitting the space bar etc).
> 
> True, so the property would need a way to automatically get
> numbered sequentially.

Why so?  I don't see a need to number the sections implied by the
pause property. There is an implicit sequence to them, but that
would work in the same way that the existing page-break mechanism
works.

> > In the interest of keeping things simple, and building solidly on
> > the existing page semantics in CSS, I would suggest something like:
> > 
> >   pause-before:  [auto|avoid|always|inherit]
> > 
> > with a default of "auto". The semantics of pause is to subdivide
> > pages into visual sections with the intent of allowing users to 
> > progressively reveal sections on an implementation dependent 
> > user action.
> 
> I don't understand how 'auto', 'avoid' and 'always' differ. (FYI:
> 'inherit' is now defined at the declaration syntax level and need
> not be mentioned in property definitions.)

I took these values from the existing definition of the
page-break-before property, so there should be no surprises.

There needs to be a way for authors to explicitly preclude a section
break being placed before the current element, for that you would
use "avoid". If the reverse is true, i.e. you explicitly want a
section break before this element, you would use "always". A smart
implementation might provide its own default sectioning for
projection mode. The "auto" value allows the author to leave it up
to the implementation. It's not difficult to imagine a simple rule
of thumb such a smart implementation could use (but may be that's
because I am used to hacking HTML Tidy :-)

> I also don't understand what this property _does_. Does it make
> elements invisible? How? What order do elements reappear? etc.

It breaks pages up into sections. When you are in projection mode
(as defined my the @media mechanism), the browser would require the
user to take some implementation dependent action (e.g. to hit the
space bar) before it would reveal the next section. The process is
repeated until the end of the page is reached and the page is
flipped to the next one. The hidden sections would still take up the
same screen real estate as when they are revealed. The hard work for
the implementation is dividing the document into pages and
supporting navigation between them. Once you have that, the section
mechanism by contrast is comparatively simple to support.

Note that I have used the term "section" but another term might be
more appropriate to avoid confusion with larger scale document 
structure, "build sections" perhaps?

It's Friday evening now (in the UK) and time for me to stop ...
-- 
 Dave Raggett <dsr@w3.org> or <dave.raggett@openwave.com>
 W3C lead for voice/multimodal. http://www.w3.org/People/Raggett 
 tel/fax: +44 1225 866240 (or 867351) +44 771 213 7629 (GSM)

Received on Friday, 12 July 2002 13:08:55 UTC