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

Dear Stephen,

thanks a lot for your reply, but your final conclusion ("Right now it 
seems best to clear up the wording of the spec.") was not what I 
intended with my post ... I will tell you, why - and describe my 
"use-case" which made me discover the inconsistent behaviour of various 
browsers:

As we know, there is no third dimension (no "z-index") in SVG ... 
overlapping of elements is made up by the sequence the elements get 
drawn. If I have a three-dimensional scene represented in SVG, and when 
I want to turn the scene in various directions, some elements might 
disappear behind other elements, from time to time, and some reappear 
which had disappeared, before.

Just now, you need to make that appearing and disappearing of elements 
(by being overlapped from others) in SVG by reordering the elements via 
JavaScript. This is not feasible in my case since the simple elements 
are grouped in "logical containers", and events are being added to such 
groups of objects - one such group must not be divided in two or more 
different groups (according to their actual "z-index") - reordering and 
resampling would be a mess, besides the need of declaring each event 
probably several times!

Or, since I do have in my use-case just two relevant layers, I might 
copy (clone) the elements via JavaScript to a second instance, and 
display the first and the second instance in different ways (make some 
elements on one and some other elements on the other instance invisible, 
color them differently, ... by appropriate CSS rules). This is what I 
do, actually, in my app.

Or (and this is the solution which would be possible with my 
understanding of standard behaviour, or also with the incorrect Firefox 
behaviour, but not with the actual behaviour of most browsers) would be 
to re<use> that first instance to a second one, and also (like in the 
former solution) make it look different with appropriate class 
definitions outside (and especially for the <use> element itself), and 
appropriate CSS rules, which might lead to a performance advantage 
compared to JavaScript cloning, among other possible structural 
advantages of the SVG code ...

... thanks for reading so far :-) Any further opinions?

Juergen

Stephen Chenney wrote:
> Thanks for an extremely thorough set of experiments.
> 
> Based on your tests, it is clear that WebKit was modified at some point 
> between Chrome versions 12 and 27 to match the behavior of other 
> browsers. All of the browsers you describe as correct are using an old 
> version of WebKit. Given the Windows Safari and Android browsers, we 
> could probably narrow it down much tighter, but it would be extremely 
> hard to verify exactly what caused it to change, unless it was a 
> specific patch with an obvious change log.
> 
> Regardless, given that all the browser vendors seem to have converged on 
> a particular interpretation, it is unlikely that the spec will be 
> modified away from that interpretation. Not impossible, just unlikely. 
> As a browser vendor, I like it when everything converges to the same 
> behavior - that's good for the web.
> 
> Right now it seems best to clear up the wording of the spec. I'll leave 
> that for someone else to consider.
> 
> Stephen.
> 
> 
> On Thu, Jul 25, 2013 at 10:41 AM, 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 16:16:28 UTC