Re: Generated Content draft

> (The actual values/properties are -pr-flow(), right?)

No. Prince does not accept identifiers beginning with hyphen, and
properties that begin with underscore look like typing mistakes to our
users when they see them in the documentation.

In my view, the argument for prefixing properties and selectors that are
not defined in a CSS recommendation is weak, as CSS recommendations are
few and far between. If you develop a new property, give it the most
obvious possible name, try to coordinate your work with other
implementations and specifications, and leave it at that.

For example, we now support line-break-before / line-break-after
properties. They've been proposed a dozen times by different people, and
they are so *obviously* the right names, that we have no intention of
calling them "prince-line-break-before" or "_pr-line-break-before".

The only possible problem could be if some years down the track, the W3C
issues a recommendation stating that "line-break-after: always" does some
wild crazy thing rather than breaking a line. Is that likely?

On the other hand, if W3C recommends "line-break: after-always" instead,
we will support the new recommended property and maintain backwards
compatibility for our own non-standard property, exactly what we would
have to do if we supported "_pr-line-break-after".

In short, I see no convincing justification to mangle new property names
until they are blessed by the W3C, nor do I see the need to support
<_prince_section> instead of <section> if we add support for XHTML2, and
I'm definitely not going put up with the perpetual duplication of every
single keyword in CSS.

Does Internet Explorer still support:

#myDiv {
    left:  expression(document.body.offsetWidth  - 110 + "px")
}

Perhaps when the expression function is given a new, more suitable name,
prefixed with _microsoft-this-will-be-recommended-when-hell-freezes-over,
the argument will seem more convincing :) Sorry for the diatribe.

> This is indeed quite similar. Does it work well? Where there unfortunate
> implementation problems worthy of note?

It is convenient for authors. It allows content from the document to be
placed in the headers and footers, which the current Paged Media draft
does not (excluding the use of named strings, which only allows you to cut
and paste text, but not tables for example).

However it does complicate layout, at least when content can be taken out
of the flow and put *earlier* on the page than it would have naturally
appeared, requiring recalculation. This should not be a problem with
footnotes, at least.

A new Paged Media draft would be a great help (the current one is what,
four years old?) as it is the primary reason that CSS is considered by
some to be unsuitable for print.

> Yes, IIRC the page bits are now:
> 
>     |  |      |  |
>   --+--+------+--+--
>     |            |
>     |            |
>     |            |
>     +------------+
>     |            |
>   --+--+------+--+--
>     |  |      |  |
       ^^        ^^
What are these bits? Could you please label this diagram? :)

> I have to say, I quite like the idea of using 'flow' instead of 'move-to'
> and 'pending'.

Me too. Particularly pending :)

> My main problem with the current draft is the interaction with
> inheritance. For technical reasons, inheritance has to happen along the
> original document tree, so move-to content doesn't blend in, font and
> colour wise. So 'width:100%' is relative to the containing block, but
> 'width:inherit' is not, when used with move-to. I don't really see a
> solution to this. Similarly, I have to define when counters and quotes
> take effect -- and there are arguments from doing them at the source just
> like there are arguments for doing them at the inclusion point.

Thorny issues, but as you say I don't think they can easily be solved
within the framework of CSS as it stands, they just need to have well
defined policy.

Michael Day

-- 
YesLogic Prince prints XML!
http://yeslogic.com/prince

Received on Thursday, 15 May 2003 07:46:40 UTC