Re: How does the svg element handle CSS border and background-color?

Hi, Tab-

Thanks for your thoughtful comments.  Replies inline...

Tab Atkins Jr. wrote (on 8/22/10 5:20 AM):
> On Sat, Aug 21, 2010 at 2:39 PM, Doug Schepers<schepers@w3.org>  wrote:
>
>>  ==Borders==
>
> Would a border of a child be able to have an effect on the bounding
> box of its parent?
>
> Otherwise, sounds fine.

My intuition says no, nor would padding of a child affect the border of 
its parent.  That accurately reflects the fact that padding and margins 
have no effect on the positioning of SVG elements.

However, if this seems like it would be difficult or computationally 
expensive/slow, or if it is really unintuitive to content creators, I 
could be flexible on this point.  I'd like to see examples and use cases 
either way.


>>  ==Margin==
>>  No effect on SVG content, but may affect HTML content around that SVG
>>  content.  So, an <svg>  element with 'margin: 20px;' has a 20px gap around
>>  the SVG content, just as if it were<img style="margin: 20px;"/>
>>
>>  Alternately, maybe margin only has an effect for<svg>  elements; that might
>>  be simpler to specify, implement, and understand for content authors.
>
> It would seem kinda weird to me to have, say, a <rect> with a margin
> affect stuff outside of the SVG.  Normally margins are bounded by the
> root element; CSS is very specific about that in the case of
> independent documents.  If box-model properties are to have no effect
> on SVG positioning, though (a good choice), then a margin on an
> internal SVG element is meaningless.

I can get behind that.  I wouldn't want to mess with the CSS model, and 
that seems like a sensible approach.

We still need to consider the case of HTML nested in SVG, however.

I would be perfectly happy if 'margin' only applied to the <svg> 
element, FWIW.


> Margins on <svg> embedded in HTML would be just fine, and should act
> as if the <svg> were a replaced element, as fantasai said.  (It's
> kinda weird that it's a "replaced element" that nonetheless has
> selectable structure, but whatever.)

A little odd, yeah, but not absurd.


>>  ==Padding==
>
> So the padding is just transparent spacing between the bounding box
> and the border?  Sounds fine, and useful.

Transparent if there isn't a background, yes.


>>  ==Background==
>>  A background is different than a fill.  Background is much the same as
>>  border; it is a rectangle (modulo the border-radius effects) around the
>>  shape, based on its geometric bounding box, taking into account padding.
>>
>>  By default, there is no background color, including for the<svg>  element.
>>
>>  SVG Tiny defines a 'viewport-fill' and 'viewport-fill-opacity'.  I think
>>  those should be deprecated in favor of 'background' properties; I have no
>>  opinion on which should have precedence... maybe they should be seen as
>>  aliases of 'background', if that makes it simpler.
>
> This sounds good.  I suggest aliasing if possible; the only
> incompatibility is the CurrentColor value it accepts.

I will suggest aliasing, with a special case, then.  In truth, I don't 
expect that there will be much overlap between SVG 1.1/2 and SVG Tiny 
1.2 content.


>(SVG's somewhat
> bizarre separation between colors and other paint servers has long
> baffled me; hopefully future work on CSS's background property will
> let it be fully general about paint servers.  That's why we defined
> the <image> type, after all.)

I'm not sure I understand what you mean here.  We should talk about this 
sometime.


>>  ==Pointer Events==
>>  Should pointer events on the border or background fire on the element
>>  itself?  I think that the default should be "no", just to be safe and
>>  consistent with older SVG content, but I could easily be persuaded to
>>  reverse that.  Either way, there should be a new property or set of
>>  properties that can modify this, in a manner consistent with how CSS is
>>  defining 'pointer-events'.
>
> I'm curious about what knobs you think might be necessary here.  There
> was a discussion on the CSS list in June 2008 about it (you've
> probably already seen it, thus the reference to "how CSS is defining
> 'pointer-events').

Yes, where is that in the CSS roadmap?


> Doing this 'properly' could get relatively complex, though, since both
> borders and backgrounds can be arbitrary images which you may want
> hit-tested either by their simple geometry or by their per-pixel
> opacity.

Interesting point.  In general, we simply need to specify a simple but 
comprehensive set of values, including transparency, non-filled areas, 
and variations on fill and stroke.  We've had feedback that the current 
relationship between visibility and pointer-events is a little 
confusing, so we need to look at that.


>>  This touches on the question, asked in a related thread, on whether the
>>  <svg>  element, by default, should be a proximal event target for pointer
>>  events.  My answer on that is a pretty firm "no"; if you want to have it as
>>  an event target, give it a background, or change the 'pointer-events' value.
>
> So you're saying that <svg> should normally be pointer-events:none?
> The current SVG default is visiblePainted, and I doubt that can be
> changed.

I don't think we need to change that... we just need to correct 
implementations that think that somehow the <svg> element has visible 
rendered area other than the contents of its children (it doesn't).

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 23 August 2010 16:51:15 UTC