Re: The canvas

> A repeated background is typically used as a texture, and the
> less obvious its tile boundaries the better.

I can see cases where that may be true.  Typically such textures are
designed so that no matter what the offset, they don't appear to have a
boundary - so picking a non 0,0 offset is not important.

>> Certainly people
>> do that with user interfaces.  Oh wait, I have a reference:
>
> Not necessary. There's a big difference between UI elements
> and a background texture. BODY is an element, not BODY's
> background-image.

Yes, they are different - I was drawing a parallel.

>> Then in your HTML documents use
>>  HTML { margin:0;padding;0;border:none }
>>  BODY { margin:0;padding;0;border:none }
>>  DIV.body { /* whatever you would have styled for the "body"
> */ }
>>
>> And then always use a synthetic BODY constructed from a DIV.
>
> With margins, DIV.body's background would not bleed onto the
> canvas.

Then you need the two DIV solution I outlined with DIV.canvas containing
DIV.body.

>> Use two DIVs.  DIV.canvas and DIV.body.  Assuming you want
> 10,15,20px
>> margins on your "body":
>>
>> DIV.canvas {
>>   margin:0;padding:0;border:none;
>>   background: url(bg.png) 10px 15px
>> }
>>
>> DIV.body {
>>   margin:10px 15px 20px; background: transparent;
>> }
>
> Yes, that would work for pixel-sized margins. But if history
> is any guide, display quality will not remain static, and a
> pixel from your display might cover 4 on mine.

Both the background-position and margin properties take <length> units,
check CSS1.  The px were simply one example - not a limitation.

> I prefer to use
> relative measurements for margins.

"em" units.  or do you want % units?  or, do you want to make one property
dependent on the value of another property - see dynamic properties as
implemented in WindowsIE5.

> Unless I can
> correspondingly resize the background image then I don't see
> how your suggestions can help.

stylistically resizing images via a CSS mechanism has been brought up and
would be useful.

>> > A second scenario: As above, but I want to put a DIV in
> BODY
>> > that has a de-saturated, hue-altered version of the
> background
>> > image, so that the appearance is of a tinted translucent
> panel
>> > over the background. The backgound-images in BODY and DIV
> must
>> > align perfectly. If the background-image does not align wi
> th
>> > BODY's padding, how could I get this effect?
>>
>> See above example for how to do embedded DIV alignments.
>
> Again, no help. I want the background image to 'bleed' onto
> the canvas, but I want it aligned relative to the element's
> padding boundary.

Right, that's why you have a DIV which simulates the canvas, onto which you
specify the background such that it appears to bleed out of the inner DIV
which simulates the body.

>> > A third scenario: As above, but I want the image pattern
>> > centered in the content + padding area. Again, unless
>> > alignment is relative to padding, how can I get this
> effect?
>>
>> Again, just have 0 margin, border, padding on BODY and HTML.
> Then do what
>> you want with DIVs.
>
> Again, no help if I want the tiled images to bleed onto the
> canvas.

Why limit yourself to the "canvas"?  Why not the ability to bleed the
background of any element onto whatever happens to be adjacent - whether
that is margins or a nearby element.

If you really want support for "bleeding backgrounds", write up a brief
property proposal.

>> No limitations - just use the relatively quirk-free DIV tag
>> instead of the
>> quirky-tradition-laden HTML and BODY.
>
> Sorry, but I don't see that DIV will do what I want, given the
> background treatment you suggest.

I'm fairly certain that any example you construct with HTML and BODY as far
as background bleed can be easily reconstructed with two DIVs.

>> Should we create an implementation that breaks thousands,
>> perhaps millions
>> of pages out on the web right now just for the sake of blind
>> literal
>> interpretation when it does not provide any additional
>> capabilities?  I
>> don't think so.
>
> I'm trying to recall pages with backgrounds that would be
> broken by an altered reference point. I can't think of any.
> My impression is that most repeating backgrounds are not
> dependent on any reference point.

Having implemented this both ways I can tell you that almost every page that
has a background image looks quite broken when you alter its reference
point.  This is because it turns out most pages with background images use
them to simulate some sort of vertical background color bar (or bars) to
which then the rest of the markup (tables typically) is carefully aligned.

If you really want to have fun with this - try creating a user style sheet
with only the background-position with strange offsets set on BODY with !
important and see how many pages with backgrounds start to look wrong.

> Any specification of
> backgrounds with CSS would hopefully have been by authors
> aware of the spec and understanding of the fact that browser
> builders have had a somewhat difficult time implementing it
> correctly.

My experience has been that authors using CSS (or HTML or any other web
authoring language) rarely read the actual spec, and typically learn by
experimenting with a particular browser. Once they get something to look the
way they want it to, they expect that to not break.

More often than not authors will also check to make sure things look ok in
at least one more browser.  But if they just happen to make use of something
which two or more browser implementations implement the same (even if it is
not to spec), they come to believe that that behavior is "correct" and if
some other browser doesn't exhibit this "correct" behavior, then it is
"broken".  Note: I'm not saying that's necessarily my opinion, just the
predominant impression I have gotten from web authors.

Tantek

Received on Friday, 19 November 1999 01:34:34 UTC