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

CCing public-fx for now.
Should I continue the "non-blocking svg canvas" issue on public-fx instead?
 
BTW, let me clarify a few things.  This issue regarding borders and backgrounds on the svg element was a really only minor question I asked in an order to gain some understanding about a more pressing issue: "non-blocking svg canvas in html"
First post: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027659.html
Rationale and detailed explanation: http://lists.w3.org/Archives/Public/www-svg/2010Aug/0041.html
 
My concern is that browsers need to have a way to declare an svg element that does not block access to HTML items underneath, does not trigger events, and generally does not act like an invisible blocking layer.  It is my opinion that this single issue is key to many great things that might be possible with SVG in the future.  (By comparision, the question regarding CSS border and background would have little effect on webmasters if it was never settled.)
 
What really concerns me is that the browsers end up with an inconsistant non-blocking svg canvas... Without this feature in all browsers, webmasters would be unable to create a whole range of new designs that SVG could make possible.  ... and if IE9 doesn't support it, then that might pretty much kill off many SVG possibilities for years to come.  So, waiting years for a new SVG spec to define this particular feature does have me worried.
 
-----------------------
 
Here's why I even asked about borders and backgrounds:
As I understand it, the svg element is non-graphical and unable to trigger events.
I thought, great, that means the svg element should not act like an invisible blocking layer in html: and browsers can update to reflect this.  Problem solved right? Nope. :)
Problem is, if you add borders and backgrounds to the svg element, this line of reasoning no longer makes sense.
By adding a background, the svg element suddenly turns into some weird graphical element that no longer has any defined way that it should act regarding events (in any of the specs).
 
Howver, on the issue of borders and backgrounds, Tony made a very compelling argumet as to why they should be supported.  His reasoning:  embedding the svg element into html requires the svg element to take on layout, positioning and box model properties so that it fits into the rest of the html content.  You can position it inline, absolute, block, set margins, etc...  These are all CSS properties that are not supposed to be possible for the svg element.  Thus, if you can apply these properites, it is pretty natural to assume that adding a border or background would also be possible.  In fact, I recall using border on the svg element myself in the past.
 
The question, then, is what do about events in this new situation.  Should the svg element now block access to items underneath when it has a background or border?  Should the svg element now trigger events when it has a background or border?  What about when it has no border or background -- should it act like an invisible blocking layer like other html elements?
 
 
 
In an effort to try to come up with a reasonable explanation that would allow for a non-blocking svg element, and also accomodate borders and backgrounds... here is one proposal that I seriously considered:
 
1. When included in html, the svg element becomds a sort of hybrid.  In some sense, it is already is a hybrid -- it can take on flow and positioning properties to regulate where it fits into html content.
2. Under normal conditions, the svg element itself does not act like an invisible blocking layer.
3. When the svg element takes on other CSS properties (like background) that afffect it graphically, then the svg element acts like you would expect of other html elements:
     - the graphical part (like the background or the border) blocks access to content underneath and can now "dispatch" events
     - any area that is still transparent (like the inside of the svg canvas when using the border property) still causes events to "fall through" to items underneath
4. This "hybrid" approach only applies to the topmost svg element inserted into html -- as that is the only element that needs this mix of properties.  (Children of the topmost svg tag, like rect, g, or other svg elements would not support any non-SVG properties like border, margin, background, etc...; they would all remain "pure" SVG.)
 
I'm guessing that maybe this explanation might not be a good way to do it? :)
 
 
Kevin
 
 

 
> Date: Sat, 21 Aug 2010 17:39:38 -0400
> From: schepers@w3.org
> To: codedread@gmail.com
> CC: tonyschr@microsoft.com; kevinar18@hotmail.com; chris@w3.org; public-fx@w3.org
> Subject: Re: How does the svg element handle CSS border and background-color?
> 
> Hi, folks-
> 
> (Moving this to the FX Task Force list, with a BCC to the SVG list; this 
> is a coordination issue, and should be handled there. If you are 
> interested in such topics, please do subscribe to the low-traffic 
> public-fx list.)
> 
> I've also posted this, in slightly expanded form, on my blog, in the 
> hopes of getting comments from a different part of the community that 
> doesn't subscribe to these email lists:
> http://schepers.cc/css-in-svg
> 
> Jeff Schiller wrote (on 8/21/10 3:16 PM):
> > On Thu, Aug 19, 2010 at 3:08 PM, Tony Schreiner <tonyschr@microsoft.com
> > <mailto:tonyschr@microsoft.com>> wrote:
> >
> >> The list of CSS properties Jeff referenced are the ones that apply
> >> to the SVG content itself, but I would argue that when the outermost
> >> SVG element is embedded in HTML it must behave on equal footing with
> >> similar HTML elements. Going even further, when embedded in HTML the
> >> outermost SVG element should also support being directly styled a
> >> block or inline block, positioned as absolute, relative, or fixed,
> >> and so on. None of these styles are in that list, and none of these
> >> make sense for the SVG content itself, but they do make sense on the
> >> root SVG container element in HTML.
> >
> > I actually have no strong opinion one way or another here. It's just
> > been my understanding that SVG elements can't be styled with border
> > properties (for instance). It seemed a logical conclusion to draw since
> > there is no box model concept in SVG. I didn't think about the CSS
> > ramifications of the fact that an <svg> inline in a HTML context does
> > create a page-aligned box.
> >
> > My main concern in this matter is the following: Will it be more
> > confusing to new authors to say 'SVG elements cannot be styled with a
> > CSS border' or 'SVG elements cannot be styled with a CSS border except
> > for the outermost <svg> element inline in a HTML context' ?
> >
> > If the specs are updated for the latter and it's clear to authors in
> > practice and we don't get fifty emails to www-svg saying "Why can't I
> > have a CSS border around my <circle>?" then I'm fine either way. I'll
> > probably still wrap my <svg>s in a <div> though ;)
> 
> 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==
> A borders is different than a stroke. An SVG element, including any 
> graphical (<rect>, <circle>, <path, etc.) or container element (<svg>, 
> <g>) can have both a stroke (which conforms to the geometry) and a 
> border (which conforms to the element's bounding box). A common use 
> case is setting the graphics apart from other content, or doing 
> mouseover highlights of an SVG element; for example, when I mouse over 
> or focus a circle, it would be much nicer, and just as semantic, to 
> simply have a CSS property draw a rectangle around that element as a 
> highlight than for me to generate a rectangle based on the bbox and 
> insert that into the DOM, keep a pointer to it, then remove it when I 
> mouse out.
> 
> Paint servers and similar resources (gradients, filters, etc.) would not 
> have any border. Note: <defs> is a non-rendering element, akin to 
> <head>, so no border would be visible for that either, but if the 
> content of a <defs> is <use>d, any border properties would apply in the 
> same manner as for other properties.
> 
> The border would not have any effect on the layout or rendering; it 
> would be strictly visual.
> 
> 
> ==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.
> 
> 
> ==Padding==
> 
> Again, this has no effect on SVG content, but it does affect how the 
> border is drawn. This would be a nice way to compensate for thick 
> stroke widths.
> 
> 
> ==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.
> 
> 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'.
> 
> 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.
> 
> ==Questions==
> A few high level questions:
> 
> Is this a change from SVG 1.1 and SVG Tiny 1.2? Yes.
> 
> Is this backwards compatible? Kind of. It introduces new behavior that 
> is not consistent with past behavior, but doesn't explicitly change very 
> much.
> 
> Does this break existing content? Very doubtful.
> 
> Is this intuitive for content authors? My intuition says yes.
> 
> Does this match existing implementations? Some, at least.
> 
> Does this provide value for content authors? Yes.
> 
> Does this make it harder to implement? I don't know; I suspect it makes 
> it easier for at least some implementations.
> 
> Does this improve interoperability? Yes.
> 
> 
> ==Conclusion==
> I propose we change SVG 2 to explicitly define this behavior. Hixie 
> seems to imply that this is not for HTML to define, and I tend to agree 
> with that, though maybe some informative mention in the HTML5 or CSS 
> specs for how SVG treats margins and padding might be appropriate.
> 
> I don't think this should be any different in standalone SVG files than 
> in SVG files referenced or inlined in HTML. That would be very 
> unintuitive, in my opinion.
> 
> If this is not controversial, I would be happy to put any or all of this 
> in the SVG Integration spec, which is one of the foundations of SVG 2 
> [1]. If someone disagrees with this, we'll have to talk about it before 
> I start editing the spec. In either case, it would need to be fleshed 
> out some... I'm probably glossing over some possible stumbling blocks in 
> the box model, which I'd appreciate feedback on.
> 
> [1] http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
> 
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>