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

Hi, Kevin-

Kevin Ar18 wrote (on 8/21/10 10:00 PM):
> CCing public-fx for now.
> Should I continue the "non-blocking svg canvas" issue on public-fx instead?

No, that's not necessarily an issue for the CSS WG to worry about 
(though they may be interested in the implications for 
'pointer-events').  As I mention in my blog post, these issues are 
closely yoked, but it all has to do with how the SVG spec defines things 
on that end (though again, we may need to talk a bit with the HTML WG).


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


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


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

I think it's unlikely that we would change the behavior of SVG 1.1 here. 
  We are much more free to define this in SVG Integration and SVG 2.

SVG 2 might take years.  SVG Integration should take much less time. 
But while it's important for vendors to show some caution when 
implementing an immature spec, the reality is that most of SVG is very 
stable, so when we do decide as a community to change things, it's 
pretty safe for a vendor to go ahead an integrate what even a draft spec 
says.

Look at HTML5; it's probably years from being done, but many parts of it 
are shipping in browsers today.  So, I wouldn't worry about that aspect 
of it.  The important thing is arrive at the right behavior and define it.


> Here's why I even asked about borders and backgrounds:
...

I go through the implications of borders and backgrounds on SVG element 
in my blog post.


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


> 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

Yes, this is all pretty much where I stand, too.  (Though be careful 
about the word "transparent", and don't forget that 'pointer-events' may 
allow visibly opaque shapes to be invisible to mouse events.)


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


> 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

Received on Sunday, 22 August 2010 02:32:01 UTC