Re: Difficult to implement CSS1 bits

On Jan 3,  3:15pm, Douglas Rand wrote:

> I've spent awhile reading the description of the various background
> attributes in the style sheet.  What particularly concerns me is the
> notion of "fixed" backgrounds.  This appears to be meaningless (or at
> least pretty useless) with the exception of the toplevel of the
> document,  i.e. a BODY or HTML background.

It can also be handy on DIV and on TABLE and on OBJECT

> Was it really the intention
> to allow fixed, non-scrolling backgrounds on things like EM?

It is tricky to write a spec that disallows it while remaining general.
Similarly, HTML allows a document to have 10,000 individual different
tiny inline images which is also slow, inefficient and useless and also
difficult to explicitly prohibit in the spec.

> Even for a BODY background acting as a watermark, there it is somewhat
> inefficient requiring constant recompositing and redrawing for small
> scroll increments.

This was a concern earlier on, but in test implementations this was not
found to be a problem. Pick up the Arena browser and try it out, preferably
with a window manager that allows opaque window resizing. You will find it
fairly fast even when stressed.

>  For any UA which does not do it's rendering
> offscreen (c.f. ours doesn't yet) this leads to a constant flashing as
> the user attempts to scroll the display.  The effectively requires that
> the UA allocate offscreen memory for it's rendering to avoid the
> flashing and recomposite the page for every increment.

Yes, Arena does that. Offscreen recomposition is also handy for dealing
with images that have alpha channels and for advanced non-scrolling
containers, z-ordering, and so on.


> This increases
> memory needs from 256K (400x600 1 byte per pixel) to around 1 Mb for
> us with 600x800,  3 bytes per pixel.

Depends where you allocate the memory. I recommend taking a creative look
atthe sort of things 3D hardware (or 'virtual' hardware as in the O2) is
good at and dusting off your GL manuals. But even so, doubling pixmap
storage (or using X backing store) is not really a problem, is it?

> Another area I simply don't understand very well is the notion of
> carrying margins/border/padding into inline text.  I understand how it
> could be used for atomic inline elements (e.g. IMG)  but elements like
> text,  which can be broken across line boundaries are pretty nasty to
> have this sort of capability,  which appears to be a unique capability
> as compared to any other text processing package.

Padding is essential otherwise text with different background colors is
hard to read because the eye merges the edges of the text with the edges
of the colored background. You can try this out in any paint package that
can create rectangles and text.

I would also direct you to the distinction between block and inline elements
and the fact that a full implementation can transform an inline element into a
block element or vice verca. For example, lists like this:

  * one * two * three * four

Again, it is hard to write a spec that restricts certain effects to certain
elements in a way which is general and forwards compatible with future changes
in the HTML specification.

> Disclaimer: These are my views,  SGI's views are in 3D

With alpha blending, z-ordering and compositing, the 3D expertise for
which SGI is known should be very useful to your implementation.

-- 
Chris Lilley, W3C                          [ http://www.w3.org/ ]
Graphics and Fonts Guy            The World Wide Web Consortium
http://www.w3.org/people/chris/              INRIA,  Projet W3C
chris@w3.org                       2004 Rt des Lucioles / BP 93
+33 (0)4 93 65 79 87       06902 Sophia Antipolis Cedex, France

Received on Sunday, 5 January 1997 14:47:49 UTC