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: Kevin Ar18 <kevinar18@hotmail.com>
Date: Mon, 23 Aug 2010 12:14:29 -0400
Message-ID: <SNT110-W45B36B705D8B60F0157811AA820@phx.gbl>
To: <public-fx@w3.org>

> > (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).
> 
> We also have to consider HTML-in-SVG, and other similar variations.

Which are handled by the rules in SVG?
 
> >(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)
> 
> Patching the SVG 1.1 spec around this issue is problematic from a 
> standardization process POV, and is unlikely to result in ultimately 
> satisfying behavior. I suggest we simply solve the real problem in teh 
> right way.
> 
> SVG 1.1 is done. Changes to behavior (as opposed to clarifications of 
> ambiguous behavior) really belong in SVG 2.

I am not 100% convinced that this issue can be resolved entirely in SVG ... or that it even should be.
 
First, off, let be clear that I am ONLY talking about the svg element (not object, image, etc...): http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#svg-0
The svg element seems to be a special case slightly different than the others: object, image, etc....
 
 
---------------------
A repeat of what we know from SVG:
* the svg element is non-graphical
* because it is non-graphical it cannot "dispatch" events
* it does not block access to anything underneath (does not act like an invisible layer)
This applies to the base svg element a well as svg elements nested within other svg elements.
------------------------------
 
HTML comes along and defines the svg element to be embedded, phrase, and flow content within html.  However, to fit into html, the svg element must be "contained" within the box model for purposes of positioning it within the html page, deciding on dimensions, how it affects flow, etc....  (by extension, we can assume all the properties that affect the box model apply: like border and background... otherwise we need clear rules why this is not true).
For lack of a better term, this "container" can be styled just like other box model elements.  However, it's contents follow the svg spec.  In this particular case the "container" and the topmost svg element are the same.  The concept here is that it seems like the topmost svg element could be styled the same way you would style other html elements so that it can fit into html correctly.
 
While SVG may have it's own rules that it can define in great detail, HTML could always come along and say that the container svg element does all kinds of crazy things to the content it is containing (without ever violating the SVG specs).
 
I'm wondering if just maybe a lot of this could be clarified in HTML -- since a lot of the issues stem from HTML integration and the need for HTML type CSS styles to apply.... 		 	   		  
Received on Monday, 23 August 2010 16:15:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 August 2010 16:15:05 GMT