W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2010

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 22 Aug 2010 02:20:54 -0700
Message-ID: <AANLkTim6dnL4wzpUFQTvWrg8bHqWh3aMMMd_VFOMu3Ti@mail.gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: Jeff Schiller <codedread@gmail.com>, Tony Schreiner <tonyschr@microsoft.com>, Kevin Ar18 <kevinar18@hotmail.com>, Chris Lilley <chris@w3.org>, public-fx@w3.org
On Sat, Aug 21, 2010 at 2:39 PM, Doug Schepers <schepers@w3.org> wrote:
> I think it's pretty clear that the intent of the SVG 1.1 spec was that those
> box-model CSS properties must not apply to any SVG elements.  In addition to
> what the spec states on the subject, my conversations with participants from
> the SVG WG at the time are unambiguous in that respect.
> The question is, is that the behavior we want?  How hard or easy is it to
> change that in modern SVG+HTML+CSS implementations?  What is most useful and
> intuitive for content authors?
> In my opinion, we could specify that some aspects of the box model apply
> without screwing with SVG's coordinate-based placement system too much.
>  Here are my initial thoughts on some specific properties:
> ==Borders==

Would a border of a child be able to have an effect on the bounding
box of its parent?

Otherwise, sounds fine.

> ==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.

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.)

> ==Padding==

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

> ==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.  (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.)

> A background raises the question of pointer events, which is also relevant
> to border.


> ==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

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

> 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

Received on Sunday, 22 August 2010 09:21:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:44 UTC