Re: [svgwg] SVG2 spec means elements within a <use> tag can not be targeted for styling

We just found our way to this thread after the breaking change killed our site in the newest versions of Firefox.  I'd like to express my dismay at this change to the spec and strongly ask/suggest/beg/implore that it be reconsidered in the SVG 2 spec.  

The V1 approach was significantly better.  The V2 approach essentially violates the underlying premise and value of CSS, largely eliminates the value of <use>, and, I would argue, makes it impossible to do interesting and complex things with SVG. 

I can see why the implementation would be significantly simpler, but the new approach has the potentially to largely undermine SVG as a useful tool, and 100% of the browsers already had working implementations of the SVG 1 approach (albeit not quite standardized).

CSS was intended to allow you to style objects based on their context.  Unless I'm missing something, the new 'improvement' is styling a template statically and then reinstantiating the styled element.  If we've learned anything in the last decade, it's that styling elements based on their context is a good thing.  CSS was such a bit hit because we could now put the same HTML in two places and have it do wildly different things based on styling rules.  It largely fulfilled the dream of separating structure from style.

SVG2 appears to eliminate this possibility for SVG elements that are instantiated with <use>, which kills the usefulness of <use>, which then leads to having to repeat code everywhere just so you can style it.  This is demonstrated in the codepen solution.  The structure of the chevron is repeated twice just to get two different styles.  

To use a mediocre analogy of cookie cutters and cookies, SVG 2 appears to allow us to only style the cookie cutters but not the cookies.  And if you've ever decorated cookies, you know that the interesting part is that each cookie shares a structure but can be decorated with different styles on a per cookie basis.  We might have a cookie cutter for a star, and a moon, and a little man (structure).  But from those three cutters, we then instantiate many cookies and with unique icing and M&M decoration (style).

With SVG 2, now we appear to have to create 1000 cookie cutters.  Further, having them adjust based on the dynamic nature of web pages is now impossible.  This is truly a step backward.  For styling to be useful, you need to be able to style each individual element based on its position and context in the DOM.  If styling has been handicapped to the point that it can't cross the shadow DOM barrier, it's no longer useful since we can't use the DOM context to determine the style.  

Cookies that appear in a "Christmas" div should have red and green stripes and cookies that appear in an "Easter" div should have pink and blue stripes, and sometimes pink and yellow stripes if the cookie has been marked as "selected" by the user.  

Without complex selectors that cross the DOM boundary, <use> is reduced to acting like a server-side include. Yes, if I want 1000 cookies, 500 of which are identical to one template and 500 of which are identical to another (the chevron example), then the SVG 2 spec makes sense.  But this is not the common or interesting case.  

If I've missed something and there's a way to style an individual sub-element within a <use> instantiation based on where that <use> appears in the DOM, then forgive my passionate plea.  But if SVG 2 just made basic CSS styling based on context impossible, then please (!!) reconsider, particularly given that it was already implemented and working in every major browser.

-- 
GitHub Notification of comment by markofca
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/367#issuecomment-350438115 using your GitHub account

Received on Saturday, 9 December 2017 09:33:08 UTC