Re: [css3-images] Referencing <svg> element directly with element()


On Feb 24, 2012, at 9:52 AM, Tab Atkins Jr. wrote:

> On Fri, Feb 24, 2012 at 5:06 AM, Erik Dahlstrom <> wrote:
>> On Wed, 22 Feb 2012 18:35:48 +0100, Tab Atkins Jr. <>
>> wrote:
>>>> If I understand the spec correctly, elements that are "paint sources"
>>>> (e.g
>>>> <img>, <canvas> and <video>) can still be used when referenced via
>>>> element()
>>>> even if they are not rendered. Please clarify what "not rendered" means.
>>>> Would display:none be included in that definition for example?
>>> Yes, display:none is included in that.  I've clarified the term now -
>>> it's defined as any element that does not generate a box, or which is
>>> a descendant of <defs> in SVG.
>> The new definition of "not rendered" seems to allow creating arbitrary svg
>> elements in script (without an enclosing <svg>) and inserting them into the
>> document and then referencing them with element(), because they won't get
>> boxes then as far as I know. Is that ok? I mean I could just create the
>> <svg:pattern> element and insert it for example.
> Yes, that's explicitly desired.  You don't even have to insert it into
> the document.  Just create it in script, and jam it into the
> CSSElementMap (if you're in HTML).  Because it knows how to render
> itself, it doesn't need to generate boxes for anything to work.  (This
> already works for <canvas> and <img>, and maybe <video>, in the
> -moz-element() function.)
>> In svg, if you had a <pattern> inside a <metadata> it wouldn't render
>> either, and same if it wasn't inside a <defs>. None of the paint servers
>> render by themselves in svg. It would be enough to set display:none on the
>> <svg> parent.
>> [[In SVG, the descendants of a <defs> element are also considered to not be
>> rendered. Other host languages may define additional ways in which an
>> element can be considered not rendered.]]
>> That makes it sound like SVG isn't allowed to change what is considered as
>> "not rendered", and I'm not really convinced that <defs> is the only case.
>> I'd suggest making the <defs> part a note, and also "s/Other host
>> languages/Host languages/".
> Good point.  I've editted the paragraph you quoted to:
> # Host languages may define additional ways in which an element
> # can be considered not rendered; for example, in SVG, any descendant
> # of a <code>&lt;defs></code> element is considered to be not rendered.
> Is this acceptable?
>> In
>> 1. Please define what the 'painting area' that is referred to in the
>> defintions of userSpaceOnUse/objectBoundingBox is.
>> 2. In the definition of userSpaceOnUse please clarify how width and height
>> are setup.
>> 3. Please consider using the term "user coordinates" instead of "user
>> units", and for clarity please add a link to the definition of each term
>> (just to be clear on whether it's an svg term or a css term).
> I have done all of these.  Let me know if the edits are okay,
> particularly for #3.  If they're not, please give me the correct
> incantations.  ^_^
With the current change objectBoundingBox and userSpaceOnUse are identical (just different wording, which should be fixed). Is that intended? userSpaceOnUse is important to make relative units (like length) relative the viewport, while they are relative the object on 'objectBoundingBox'. I have nothing against this change. But in this case you should say that you always use objectBoundingBox and userSpaceOnUse gets ignored. Would that match you intention?


Received on Friday, 24 February 2012 22:36:40 UTC