W3C home > Mailing lists > Public > public-cdf@w3.org > May 2006

[WICD Core 1.0] Size Negotiation for Scalable Background Images

From: Jeff Schiller <codedread@gmail.com>
Date: Fri, 5 May 2006 12:44:06 -0500
Message-ID: <da131fde0605051044q7464d28di76aade9464201dd9@mail.gmail.com>
To: public-cdf@w3.org

My apologies if this has already been stated or otherwise addressed or
if this is a stupid question.  Ok, enough caveats ;)

Section 3.2.2 of WICD Core 1.0 talks about scalable backgrounds and
Section 3.3 talks about scalable child element layout.  I still had
some doubts/questions about how the size of the background image is
ultimately determined so I thought I'd lay out some scenarios and see
if it all makes sense.  In these examples, I've just focused on the
ultimate width of the SVG background image when rendered.  The SVG 1.1
spec, Section 7.2
(http://www.w3.org/TR/SVG11/coords.html#ViewportSpace) states:

"The width attribute on the outermost 'svg' element establishes the
viewport's width, unless ... there are CSS-compatible positioning
properties specified on the referencing element or on the containing
document's outermost 'svg' element that are sufficient to establish
the width of the viewport."

To reiterate: the width attribute on the 'svg' element gets overridden
if there are CSS positioning properties specified on the 'svg' element
or (in the case of a background image) on the HTML "containing block".

1) The SVG spec doesn't seem to address what happens if CSS
positioning properties are specified on both the 'svg' element and the
HTML 'containing block'.  Am I mistaken here?  If it's not specified,
is this considered a user error and the behavior is UA-defined?  The
SVG content may have been written by one web author and the HTML
content by another - this could be a common scenario.  Does the WICD
Core 1.0 spec need to be explicit about the following scenario:

index.html:
<html>
  <body>
  <div style="background-image:url(background.svg); position:absolute;
width:400px;">
    <p>This in foreground</p>
  </div>
  </body>
</html>

background.svg:
<svg width="100%" style="width:600px;">
...
</svg>

In this scenario, the width attribute on the 'svg' element is ignored
since it's overridden by CSS positioning properties.  The only
question is whether we need to be explicit:  In this scenario, I would
think that SVG image is scaled to 600 pixels wide.  The CSS overflow
property on the 400-pixel-wide HTML 'containing block' determines if
the "extra" 200 pixels of the image are displayed or hidden.

2) Let's try only a slightly trickier scenario:

index.html:
<html>
  <body>
  <div style="background-image:url(background.svg); position:absolute;
left:100px; right:0px;">
    <p>This in foreground</p>
  </div>
  </body>
</html>

background.svg:
<svg width="100%" style="width:600px;">
...
</svg>

In this case, the HTML containing block's dimensions are variable
depending on the browser window's size. Nonetheless, this containing
block dimensions doesn't really impact the size of the rendered
background (which is still 600 pixels).  The overflow property on the
containing block will determine how much of the 600 pixel background
is visible based on the actual pixel size of the HTML containing
block.

Note that both of the above scenarios are not really "scalable
backgrounds" because the size is explicitly set as CSS properties of
the 'svg' element.

3) Now into a scalable case:

index.html:
<html>
  <body>
  <div style="background-image:url(background.svg); position:absolute;
left:100px; right:0px;">
    <p>This in foreground</p>
  </div>
  </body>
</html>

background.svg:
<svg width="50%">
...
</svg>

In this scenario, the width attribute of the 'svg' element says "make
me half the width of the containing block".  This will happen
regardless of whether the size of the containing block is implicitly
determined or explicitly determined by CSS positioning properties.  In
this case, the background image is handled as per Section 3.3.1 of
WICD Core 1.0.

Have I covered the possible scenarios?  Are my assumptions correct?

Thanks,
Jeff
Received on Friday, 5 May 2006 17:44:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:41 GMT