Re: CSS selectors with elements and/or classes outside and inside a <use>

Do we have to distinguish between "class" and "CSS display property"? In 
my understanding, "belonging to a class" is a property as well, and the 
later quoted sentence from the spec says that properties from parents of 
the "original" element are not being inherited for the <use>d element. 
And I would assume that, finally, with all those given (and not-given) 
classes and additional styles, the browser finally has to decide for 
each element on its own, how it is being outlined ... so the <use>d 
element would not have any style (besides that given by attribute style, 
explicitly, which is not the case, here) before it is being displayed as 
a <use>d element, finally, and then the applicable CSS rules decide upon 
the actual outline, the rule with the simple "use" within class "bggrp" 
being the only one applicable, in our case ... no? Any "real experts" 
(to quote your term, Paul ;-) ) available?

Juergen

Paul LeBeau wrote:
> I think the newer browser behaviour is correct - ie. the circles should 
> *not* be yellow.
> 
> The first section of the specification you quote is really just saying 
> that the referenced elements' position under the <use> element should be 
> considered "virtual" and can not be used for CSS rule matching.  For 
> example, you could not have a rule that says:
> 
> use circle { fill: purple; }
> 
> So the referenced circles get their styling from their original document 
> tree position and not via the <use>.
> 
> You added:
>  >Property inheritance, however, works as if the referenced element had 
> been textually included as a deeply cloned child of the ‘use’ element. 
> The referenced element inherits properties from the >‘use’ element and 
> the ‘use’ element's ancestors. An instance of a referenced element does 
> not inherit properties from the referenced element's original parents.
> 
> The circles are not inheriting the yellow because the properties gained 
> from the CSS rules on the original (referenced) elements are copied 
> across to the cloned subtree and thus over-ride the yellow..
> 
>    "the conceptual deep cloning of the referenced element ... also 
> copies any property values resulting from the CSS cascade ... on the 
> referenced element"
> 
> So essentially you have:
> 
>   <g style="fill: yellow"> <!-- use is replaced with a g conceptually -->
>     <g id="theobj1">
>       <circle style="fill: white">
>       <circle style="fill: grey">
>     </g>
>   </g>
> 
> This is spelled out more clearly later in the <use> section.
> 
>     Additionally, the copy (deep clone) of the referenced resource
>     carries along with it the "cascaded" property values resulting from
>     the CSS cascade on the original (i.e., referenced) elements. Thus,
>     the result of various CSS selectors in combination with the ‘class’
>     <http://www.w3.org/TR/SVG/styling.html#ClassAttribute> and ‘style’
>     <http://www.w3.org/TR/SVG/styling.html#StyleAttribute> attributes
>     are, in effect, replaced by the functional equivalent of a ‘style’
>     <http://www.w3.org/TR/SVG/styling.html#StyleAttribute> attribute in
>     the generated content which conveys the "cascaded" property values.
> 
> 
> Paul
> 
> PS. Not I am new here also, so I am prepared to be corrected by the real 
> experts. :)
> 
> 
> 
> 
> On 26 July 2013 02:41, Juergen Roethig <roethig@dhbw-karlsruhe.de 
> <mailto:roethig@dhbw-karlsruhe.de>> wrote:
> 
>     Sorry, but in my original posting, I forgot to mention a very
>     important sentence from the standard ... I've put it in below ...
> 
>     Juergen Roethig wrote:
> 
>         Hello world,
> 
>         I do have an issue with selectors which are made of several
>         selectors (especially class selectors) referring to outside and
>         inside some re-<use>d SVG <g>roup.
>         Just as an example, assume the following CSS selectors:
> 
>         circle.fgobj { stroke: blue; }
>         circle.bgobj { stroke: green; }
>         .fggrp circle.fgobj { fill: white; }
>         .fggrp circle.bgobj { fill: grey; }
>         .bggrp use { fill: yellow; }
>         .bggrp circle.bgobj { fill: red; }
> 
>         .bggrp rect.fgobj { fill: red; }
> 
>         and the following SVG code:
> 
>         <g class="fggrp">
>         <g id="theobj1">
>         <circle cx="-25" cy="0" r="20" class="fgobj" />
>         <circle cx="25" cy="0" r="20" class="bgobj" />
>         </g>
>         </g>
> 
>         <g class="bggrp" transform="translate(-100 0)">
>         <g id="theobj2">
>         <circle cx="-25" cy="0" r="20" class="fgobj" />
>         <circle cx="25" cy="0" r="20" class="bgobj" />
>         </g>
>         </g>
> 
>         <g class="bggrp" transform="translate(100 0)">
>         <use id="theuse" xlink:href="#theobj1" x="0" y="0" />
>         </g>
> 
>         You might get this example (with a few additional components)
>         online on
>           http://www.ladenkirche-__senfkorn.de/test.svg
>         <http://www.ladenkirche-senfkorn.de/test.svg>
> 
>         According to the spec, SVG 1.1, especially "5.6 The ‘use’
>         element" on
>           http://www.w3.org/TR/SVG11/__struct.html#UseElement
>         <http://www.w3.org/TR/SVG11/struct.html#UseElement>
>         we read
> 
>             For user agents that support Styling with CSS, the
>             conceptual deep cloning of the referenced element into a
>             non-exposed DOM tree also copies any property values
>             resulting from the CSS cascade ([CSS2], chapter 6) on the
>             referenced element and its contents. CSS2 selectors can be
>             applied to the original (i.e., referenced) elements because
>             they are part of the formal document structure. CSS2
>             selectors cannot be applied to the (conceptually) cloned DOM
>             tree because its contents are not part of the formal
>             document structure.
> 
> 
>     And additionally, in the next paragraph, the standard says:
>     ***
>     Property inheritance, however, works as if the referenced element
>     had been textually included as a deeply cloned child of the ‘use’
>     element. The referenced element inherits properties from the ‘use’
>     element and the ‘use’ element's ancestors. An instance of a
>     referenced element does not inherit properties from the referenced
>     element's original parents.
>     ***
> 
>     With that last sentence ("An instance of a referenced element does
>     not inherit properties from the referenced element's original
>     parents."), you need to read my following conclusion:
> 
>         Am I right that for the <use> element in the above example
>         (making the two circles at the right side in the above example),
>         the value of the property "fill" should be "yellow" for both
>         circles, and nothing else? Neither a selector of ".fggrp
>         circle.fgobj" nor ".fggrp circle.bgobj" nor ".bggrp
>         circle.bgobj" should fire in that case - only the selector
>         ".bggrp use" matches. So the color of the six circles should be
>         (from left to right): Black - red - white - grey - yellow -
>         yellow. But the result on various browsers is different (we will
>         mention just the two critical circles at the right side):
> 
>         Firefox (rather old "Iceweasel" 3.0.6 on rather old Debian, as
>         well as actual 2x.0 on Windows, MacOSX, Android 4.0) combines
>         the classes from outside the use and inside the g, making the
>         right circle "red" which is wrong. The left circle of the two is
>         "yellow", which is correct. The bug with the wrong inheritance
>         of classes outside the <use> object had been reported several
>         times, before.
> 
>         Opera (rather old 12.02 on a rather old Debian, as well as
>         actual 12.16 on Windows, and 12.15 on MacOSX, as well as Opera
>         mobile 12.10 on Android 4.0.3) makes the two circles similar to
>         the two original circles in the middle from which it is a reuse
>         of, making them "white" and "grey". The same for IE 9
>         (9.0.8112.16421 on Windows, to be exact). So, the browser
>         inherits class information from outside the original <g> which
>         is then re<use>d elsewhere, and this is also a bug, according to
>         the spec. But I did not find information about this, so far. And
>         lots of browsers do it like that.
> 
>         Chrome 12.0.742.124 on a rather old Debian shows both circles
>         "yellow", thus behaving correct - hooray! But an actual Chrome
>         28.0.1500.72 m on Windows, as well as Chrome 27.0.1453.116 on
>         MacOSX, as well as Chrome on Android 4.0.3, behave like the
>         above group of Opera, IE9, and several versions of other
>         browsers ...
> 
>         Safari 5.1.7 on Windows behaves correct - hooray, again! But
>         well, Safari 6.0.5 on MacOSX as well as Safari on Ipad (iOS
>         6.1.3) has again the "usual" wrong behaviour of Opera, IE9, and
>         several versions of other browsers ...
> 
>         And finally, another browser with correct behaviour - the
>         built-in browser of Android 4.0.3.
> 
>         That's all browsers I have hands on to check ... anyone else?
>         And more important: Is my understanding of "what should be
>         correct" according to the standard, correct at all?
> 
>         Opinions? Thoughts? Or even links to other sources with
>         reference to this problem?
> 
>         Best regards,
> 
>         Juergen Roethig
> 
>         P.S.: Hopefully I did not mention any circle or browser in a
>         wrong way ... to many circles are flickering in front of my
>         eyes, now ;-)
>         .
> 
> 
> 
> 
> 
>

Received on Thursday, 25 July 2013 17:15:36 UTC