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

On Fri, 24 Feb 2012 18:52:10 +0100, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> On Fri, Feb 24, 2012 at 5:06 AM, Erik Dahlstrom <ed@opera.com> wrote:
>> On Wed, 22 Feb 2012 18:35:48 +0100, Tab Atkins Jr.
...
>> 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.)

Ok, good to hear it's desired functionality. My point was that it's quite  
easy to create a DOM that you can't normally get through just parsing an  
html document. You wouldn't need to use CSSElementMap if you used js to  
create and insert an <svg:pattern> element, a simple 'id' attribute should  
be enough for element() to be able to reference it and I don't think that  
the <svg:pattern> element would occupy any space in the layout in that  
case. However I agree that using CSSElementMap is probably better and more  
convinient if you are using script anyway, but the CSS rules would perhaps  
be slighty more clear than if the svg fragment was outside the document.  
In Firefox if you with -moz-element() reference an <svg:pattern> that has  
no <svg> parent then it doesn't render as a background, which is another  
reason for me asking. I think it's clear that it must work from the way  
the spec is currently written.

An example using svg with CSSElementMap might be nice to have, especially  
since the referenced definition of CSSElementMap doesn't seem to allow svg  
fragments outside the document to be found this way:

[[ Each entry in the CSS ID overrides list, while it is in the list and is  
either in the Document or is an img, video, or canvas element, defines a  
CSS element reference identifier mapping the given name to the given  
Element. ]]

Also the reference to the whatwg html5 specification (for CSSElementMap)  
isn't listed in the references section.

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

Yes, that's fine.

>> In http://dev.w3.org/csswg/css3-images/#paint-sources:
>> 1. Please define what the 'painting area' that is referred to in the
>> defintions of userSpaceOnUse/objectBoundingBox is.

It looks a bit better, but it's confusing to use the top/left of a the  
'concrete object size' since that's just a width and height, not a  
position, right?

>> 2. In the definition of userSpaceOnUse please clarify how width and  
>> height
>> are setup.

That particular comment came from Dirk Schulze, so if he's happy with the  
changes you've made then you can consider this point addressed.

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

Thanks, that looks better.


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Monday, 27 February 2012 10:30:49 UTC