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

On 11/30/2010 08:16 PM, Tab Atkins Jr. wrote:
> On Tue, Nov 30, 2010 at 4:57 PM, Ian Hickson<>  wrote:
>> On Mon, 23 Aug 2010, fantasai wrote:
>>> On 08/23/2010 03:06 PM, Ian Hickson wrote:
>>>> On Mon, 23 Aug 2010, fantasai wrote:
>>>>>> As far as I can tell, HTML5 does not consider the SVG element to be this
>>>>>> kind of replaced content:
>>>>> I don't really know what "replaced element" means in HTML
>>>> It's the CSS term -- that section is the part of HTML that defines how
>>>> HTML maps to CSS.
>>> I see. It might help to link to the definition, then. :) Although I'm
>>> a little concerned that this is not connecting up very smoothly.
>> What URL should I use to link to the definition? There doesn't seem to be
>> a public editor's draft of CSS 2.1 and the CSS3 drafts on the topic do
>> seem to be mature enough to warrant deep linking (not because of the
>> content, but because the links are likely to break without my noticing).
> Can't really help on this issue, unfortunately.  The ED of CSS 2.1 is
> still member-private for some reason.  :\

>>> Wrt CSS, any element whose rendering is outside the scope of CSS
>>> rendering rules is considered a "replaced element". This would include
>>> embedded SVG and MathML.
>> HTML tries to stay out of defining how SVG and CSS should interact since
>> that's a problem that exists without HTML. Whatever rules apply when HTML
>> is absent still apply when HTML is present. If there's any magic text I
>> need to include to make sure HTML doesn't "turn off" those rules, let me
>> know. I try to avoid saying things like "The requirements of the Foo
>> specification apply" since that tends to imply that there might be some
>> reason to believe that without that statement, they might not apply.
> The idea is that embedded SVG and MathML should act like embedded
> documents, just like an<iframe>.
> I don't think that's strictly required, though.  We could instead
> treat them like normal elements in the tree, just like an<iframe
> seamless>, I guess.

No, that's not the idea at all.


Received on Wednesday, 1 December 2010 17:28:14 UTC