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

On Sat, Aug 21, 2010 at 2:39 PM, Doug Schepers <schepers@w3.org> wrote:
> 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==

Would a border of a child be able to have an effect on the bounding
box of its parent?

Otherwise, sounds fine.


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

It would seem kinda weird to me to have, say, a <rect> with a margin
affect stuff outside of the SVG.  Normally margins are bounded by the
root element; CSS is very specific about that in the case of
independent documents.  If box-model properties are to have no effect
on SVG positioning, though (a good choice), then a margin on an
internal SVG element is meaningless.

Margins on <svg> embedded in HTML would be just fine, and should act
as if the <svg> were a replaced element, as fantasai said.  (It's
kinda weird that it's a "replaced element" that nonetheless has
selectable structure, but whatever.)


> ==Padding==

So the padding is just transparent spacing between the bounding box
and the border?  Sounds fine, and useful.


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

This sounds good.  I suggest aliasing if possible; the only
incompatibility is the CurrentColor value it accepts.  (SVG's somewhat
bizarre separation between colors and other paint servers has long
baffled me; hopefully future work on CSS's background property will
let it be fully general about paint servers.  That's why we defined
the <image> type, after all.)

> A background raises the question of pointer events, which is also relevant
> to border.

Indeed.


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

I'm curious about what knobs you think might be necessary here.  There
was a discussion on the CSS list in June 2008 about it (you've
probably already seen it, thus the reference to "how CSS is defining
'pointer-events').

Doing this 'properly' could get relatively complex, though, since both
borders and backgrounds can be arbitrary images which you may want
hit-tested either by their simple geometry or by their per-pixel
opacity.


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

So you're saying that <svg> should normally be pointer-events:none?
The current SVG default is visiblePainted, and I doubt that can be
changed.

~TJ

Received on Sunday, 22 August 2010 09:21:47 UTC