Re: Generated Content draft

On Thu, 15 May 2003, Michael Day wrote:
>>
>> (The actual values/properties are -pr-flow(), right?)
>
> In my view, the argument for prefixing properties and selectors that are
> not defined in a CSS recommendation is weak, [...]

If the gencon draft is changed to use flow: and flow(), then documents
written for Prince will render unexpectedly in compliant implementations,
and vice versa.

IE4 implemented 'position: absolute' before 'position' reached REC. (At
the time there was no CR stage, and at the time the "rule" was "don't
implement this in release versions", not "if you implement this, use a
careful name". But the idea is the same.)

The result of IE4's premature implementation is that when the real spec
came out, with its slightly different semantics, authors ended up writing
documents that worked with IE4, and not with the spec. So later, when
Mozilla implemented the properties correctly, pages broke left right and
center. Because of this, the spec has, annoyingly, been repeatedly changed
to get closer and closer to what Microsoft originally implemented, rather
than what the spec says, with the only reason being that IE4's
implementation, which was in good faith, was based on an earlier draft.

Thus CSS has been effectively forced to switch back to an earlier draft
instead of using the (theoretically) better, more evolved version
originally present in the REC.


Another example: Mozilla implemented 'opacity' some time before the CSS3
Color module reached CR. Mozilla's implementation is slightly different:
it only acts on the element itself, and uses inheritance to affect
childron, while the spec is not inherited, and affects the entire stacking
context subtree. The spec's design is much better, but Mozilla's 'opacity'
property is in wide use.

Thankfully, Mozilla called the property '-moz-opacity' so there will not
be any problem of clashes with the 'opacity' property that is now in CR.


> 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.

Newer IE extensions (in particular, those in MS Office) are indeed
prefixed with 'mso'. Just check the output of Word's "convert to HTML"
feature.


>> 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).

I presume the elements are also removed from the flow? i.e. elements are
not duplicated?

Do you support moving elements to other elements, or just to headers/
footers? What happens to an element that isn't re-inserted?


> 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.

The gencon draft does not allow this -- all content has to be moved down
the document. In practice this doesn't reduce the possibilities. Given:

   <a/> <b/> <c/>

If you want to move <c> to before <a>, you can instead simply move <a> and
<b> to after <c>. Granted that is a little (sometimes a lot) more
complicated, but it means you never have any impossible-to-resolve
problems with moving content into itself, above itself, into it's
grandparent, or any such things.


> 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.

Work is on the CSS3 Paged Media Module is ongoing, although I cannot
pretend to speak for its editor.


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

top-far-left, top-left, top, top-right, top-far-right, left, (content),
right, footnote, bottom-far-left, bottom-left, bottom, bottom-right,
bottom-far-right, if I recall correctly. This is all subject to change, I
do not know what the current state of the Paged Media module is.


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

Cool.


> > 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.

Ooh, hmm, a policy. I suppose I could introduce a way of saying:

   @counter sentence {
     increment-at: final-position;
   }

   @counter source {
     increment-at: source;
   }

And for sanity's sake, quotes should always be done on the final rendering
tree.


One other thing that I was trying to solve is the arbitrary wrapping
problem. Take the following document:

   1: <dl>
   2:  <dt/> <dt/> <dd/> <dd/>
   3:  <dt/> <dd/>
   4: </dl>
   5: <blockquote/> <p> <cite/> </p>
   6: <p/> <p/>
   7: <blockquote/> <p> <cite/> </p>

I want to be able to put a border around the elements on lines 2, 3, 5,
and 7. That is, I want a border from a <dt/> to the last matching <dd/>,
and around a <blockquote/> and its following <p> <cite/> </p> block.

You can do that using the gencon draft as it stands:

   dt { content: none; }
   dt::alternate { content: contents; flow: terms; }
   dd { flow: definitions; }
   dd + dt, dl::after {
     display: block;
     content: flow(terms) flow(definitions);
     border: solid;
   }

...although the second case requires my :matches():

   blockquote:matches(# + p:matches(cite)) { flow: blockquote; }
   blockquote + p:matches(cite)::outside::before { content: flow(blockquote); }
   blockquote + p:matches(cite)::outside {
     /* this contains the blockquote and the cite */
     display: block;
     border: solid;
   }

However, both of these cases are rather convoluted. Indeed the first took
me a good 10 minutes to work out (you have to use ::alternate, otherwise
you end up nesting all the term/definition groups inside each other.)

I would love to find a better way of doing it, something like:

   body::group(dt, dd) { display: block; border: solid; }

...but this runs into the "can't easily disable them" problem and is also
quite hard to define usefully (what should the arguments be?).

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 15 May 2003 08:37:32 UTC