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

> > 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"
> 
> I don't think they are completely orthogonal. The resolution of one 
> determines the effect on the other.

Actually, I kind of agree on that point.  The two issues may be very, very closely tied to each other.  It's actually what brought me to ask about it in the first place.
 
> > 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.)
> 
> I don't agree (see above).
Despite, the way they may be closely tied together, the only point I was trying to make is that webmasters won't really care if some browsers allow a border on the svg element and some don't.  That is very easy to work around.  Howevering, not having the ability to use a non-blocking svg element/canvas basically prevents the uses of a whole range of cool possibilities for SVG in html.
 
> > 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.
> 
> I am strongly opposed to CSS behavior of SVG in HTML being different 
> than in pure SVG.
in html the topmost SVG element is considered flow and phrasing content.  Would this imply that it can have CSS properties non in the SVG spec?  That is all I was suggesting.
 
> > 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 think this is unnecessarily restrictive.
(note my explanation above)  The reasoning was that the topmost svg element is the only "contact" with html and the only element that is considered to be flow and phrasing content (which it's chidrent are not).
 
On the other hand if you are suggesting adding new CSS properties to SVG, I have no arguments.  However, the contact with html was my reasoning for why the topmost svg element has additional properties.
 
> 
> 
> > I'm guessing that maybe this explanation might not be a good way to do
> > it? :)
> 
> In general, I agree with most of your suggestions, other than 
> restricting the box model properties to root SVG elements, and having 
> different behavior for SVG and SVG-in-HTML.
> 
> Regards-
> -Doug
> 

Am I correct in that you are proposing that a new spec be written up to cover these issues (or a section in the SVG 2 spec)?  ... and that there is not any other way to explain things using current specs?  (BTW, if you are wondering, all my explanations were an attempt to explain things without having to write a new spec -- but that's probably not the cleanest way to do things)