RE: display:none and mixed SVG and HTML

Hi Brian,

> -----Original Message-----
> From: Brian Birtles [mailto:birtles@gmail.com]
> Sent: Friday, 3 February 2012 2:04 PM
> To: www-svg@w3.org
> Subject: Re: display:none and mixed SVG and HTML
>
> Thanks everyone for your feedback here.
>
> Firstly, sorry if my previous mail sounded like I was pushing an agenda.
> I'm not heavily invested in any solution (hence the "feel free to contest this"),
> rather, like you all, I just want to clear up what authors should expect and
> implementors should aim for on this issue.
>
> I am most certainly the least knowledgeable about CSS in this discussion,
> maybe this whole mailing list, but I'll make an attempt at summarising what I
> think are the issues that have been raised so far.
>
> Consider the following example,
>
> <svg>
>    <g style="display:none;fill:green;stroke:yellow">
>      <pattern id="pattern">
>        <circle cx="5" cy="5" r="5"/>
>      </pattern>
>    </g>
>    <g style="fill:orange;stroke:red">
>      <rect fill="url(#pattern)"/>
>    </g>
> </svg>
>
> In this example, the <circle> inherits its fill and stroke from the parent <g>
> where it is defined, i.e. it is green with a yellow stroke.
I agree with you that's what the SVG spec requires as of today. I don't think it should stay like that. It doesn't allow for efficient implementations since you have to recompute the pattern and gradients. For gradients, the situation is a bit simpler since the only gradient properties (stop-*) that you can actually affect by inheritance are defined as "inherited: no". So one would have to write something like to have the inheritance applied:

<svg>
<g style="display:none;stop-color:green;stop-opacity:0.5">
<linearGradient id="myGradient" stop-color="inherit" stop-opacity="inherit" ...>
<stop offset="0%" stop-color="inherit" stop-opacity="inherit"/>
<stop offset="100%" stop-color="red" stop-opacity="1"/>
</linearGradient>
</g>
<g>
<rect fill="url(#myGradient)" .../>
</g>
</svg>

So, I doubt that:
a) it is really a useful case. Why would you need to inherit from the parent of the linearGradient and not from the rectangle itself?
b) there is a lot of content using it. I would agree to change that in the SVG spec and I think (but I don't know enough about CSS) it would simplify the problem.

> That is to say, the pattern is not just a shadow dom tree in the sense of a copy
> of the pattern's content, but rather it inherits its style from where it is defined.
Exactly, why not change that?

Regards,
Cyril


>
> As SVG says:
>
>    Properties inherit into the 'pattern' element from its ancestors; properties do
> not inherit from the element referencing the 'pattern'
> element.[1]
>
> This, of course, means computing style inside the display:none subtree.
> That's fine for SVG but for HTML computing style on display:none subtrees can
> be problematic. As Boris points out, at least counters, quotes, and animations
> will be affected by computing styles. In future there may be others. Tab has
> suggested workarounds for these cases. I don't think we've yet reached
> agreement about the suitability of the workarounds.
>
> Putting this all into one monstrous test case:
>
> <html>
>   <style>
>    #main {
>     counter-reset: section;
>    }
>    h1:before {
>     counter-increment: section;
>     content: counter(section) ": ";
>    }
>   </style>
>   <body id="main">
>    <h1>A</h1>
>    <p style="display:none">
>     <svg>
>      <pattern id="pattern">
>       <foreignObject>
>        <body><h1>B</h1></body>
>       </foreignObject>
>      </pattern>
>      <foreignObject>
>       <body><h1>C</h1></body>
>      </foreignObject>
>     </svg>
>    </p>
>    <p>
>     <svg>
>      <rect fill="url(#pattern)"/>
>      <rect fill="url(#pattern)"/>
>     </svg>
>    </p>
>    <h1>D</h1>
>   </body>
> </html>
>
> What is the expected result here?
>
> Thanks again everyone for your help on this.
>
> Best regards,
>
> Brian
>
> [1] www.w3.org/TR/SVG11/pservers.html#PatternElement

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Sunday, 5 February 2012 22:17:37 UTC