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

Received on Saturday, 21 August 2010 21:39:43 UTC