- From: Tantek Celik <tantek@cs.stanford.edu>
- Date: Thu, 18 Nov 1999 16:28:00 -0800
- To: David Perrell <davidp@earthlink.net>, "www-style" <www-style@w3.org>
David Perrell wrote: > Tantek Celik wrote: >> >> possibilities: >> >> - have BODY "bleed" its tiling of its background-image into >> the :root and/or >> canvas area - this will typically result in ugly partial >> background-images >> being drawn along the top and left of the page. > > The logic of this statement eludes me. How is it that partial > background-images at top left are ugly and and partial > background-images at bottom right are not? Um, common asthetic sense? I believe there have been studies about how readers tend to look at a layout (whether textual or graphical) starting at the top left and make their way towards the bottom right. Certainly people do that with user interfaces. Oh wait, I have a reference: Disclaimer: such studies may have been l-to-r, t-to-b language/culture biased. > I believe that background-image should always be positioned > relative to the padding of the element, because that behavior > allows design possibilities that any variance will eliminate. 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. Markup something like this: <html> <body> <div class=body> <!-- insert "body" content here --> </div> </body> </html> Then your documents won't have to worry about any backward compatible quirky behavior specific to <HTML> or <BODY> in user agents. > Examples: > > Let's say I have a tiled background in BODY and BODY has > different margins on three sides. Further, let's say the most > important alignment factor is that the background edge align > with the padding edge, not the canvas edge. And let's also say > that I want this background to repeat all the way to the edges > of the canvas and that I don't consider partial images ugly. > Unless the alignment of the background-image is relative to > the top left of the padding, how could I ever hope to get the > effect I want? 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; } on markup similar to the above example: <html> <body> <div class=canvas> <div class=body> <!-- insert "body" content here --> </div> </div> </body> </html> > 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 with > BODY's padding, how could I get this effect? See above example for how to do embedded DIV alignments. > 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. > It seems to me that any other positioning possibilities can be > had by applying background to HTML, or by using DIV. So I > argue that background-image should always be positioned > relative to padding, because an exception would create > limitations. No limitations - just use the relatively quirk-free DIV tag instead of the quirky-tradition-laden HTML and BODY. > Should backgrounds be implemented counter to the spec for > backward compatibility if current implementation denies what > adherence to the spec would allow? I don't think so. 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. Tantek
Received on Thursday, 18 November 1999 19:29:07 UTC