4.78 KB, image/svg+xml
521 bytes, image/svg+xml
547 bytes, image/svg+xml
Two things: (1) I think you're missing "data:text/html;base64," at the beginning of your iframe src attribute here. (in comment 0 and in the attachment) (2) What do you mean by "strips HTML"? Just that the iframe fails to load? The rest of the HTML renders fine to me.
(Ah, sorry -- I see what you mean now about "strips HTML". I'd been testing the source in comment 0, and hadn't tried using the actual attached file as an image.) I think things are working as-expected here. If you have a requiredFeatures attribute which requires script, then things inside of that tag will not render. (It looks like we *do* render the SVG 'background' property. Not sure if that's a bug or not. But it's absolutely correct that we skip rendering its contents (including the HTML) when its requiredFeatures check fails.) See https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/requiredFeatures
As for #SVG, that feature is currently marked as "Unsupported" internally: http://mxr.mozilla.org/mozilla-central/source/dom/svg/nsSVGFeaturesList.h#57 ...so that requiredFeatures check fails, regardless of whether you're in an image. (unlike #Script, which only fails if you're in an image) I'm not sure why that's marked as unsupported -- that likely just needs an update.
The spec text on this is http://www.w3.org/TR/SVG/struct.html#RequiredFeaturesAttribute # If all of the given features are supported, then # the attribute evaluates to true; otherwise, the # current element and its children are skipped and # thus will not be rendered. The "otherwise" is what's happening here -- the children (including all the HTML descendants) are skipped & not rendered.
(In reply to Daniel Holbert [:dholbert] from comment #7) > The spec text on this is > http://www.w3.org/TR/SVG/struct.html#RequiredFeaturesAttribute > > # If all of the given features are supported, then > # the attribute evaluates to true; otherwise, the > # current element and its children are skipped and > # thus will not be rendered. > > The "otherwise" is what's happening here -- the children (including all the > HTML descendants) are skipped & not rendered. Ok, it’s the behavior of Webkit or blink based browsers which confused me *(where HTML is rendered)*.
Created attachment 8647674 [details] testcase 2 (seeing whether requiredFeatures works at all in other browsers) Gotcha. Yeah, I just noticed Blink/WebKit seem to be less strict here -- they behave as if the requiredFeatures test passed. I think that's because they simply don't honor requiredFeatures at all. (i.e. requiredFeatures seems to be useless in Blink/WebKit -- it doesn't seem to actually test for anything). Here's a testcase demonstrating this, using <switch>, which renders the first child without a failing requiredFeatures test. In Firefox, this testcase renders like so: > We correctly failed requiredFeatures test for #BogusFeature. In Chrome, this testcase renders like so: > Um... somehow we PASSED a requiredFeatures test for nonexistant #BogusFeature.
There's a proposal that for SVG 2 all features would return true. I'm not sure that makes sense for Script but it does seem to be what Chrome have implemented.
I don't really see much valid in this bug TBH.
(In reply to Robert Longson from comment #10) > There's a proposal that for SVG 2 all features would return true. I'm not > sure that makes sense for Script but it does seem to be what Chrome have > implemented. Ah, ok. That makes Chrome's behavior on my attached testcase with a bogus feature make more sense. (They seem to be the only browser with this behavior; I tested Edge 0.11 and Safari 9.) Anyway -- yeah, per comment 8 I think this bug report was just inspired by confusion from Firefox differing from Chrome on this. (and we're correct per SVG 1.1)
Ok, then it’s definitely a bug if ᴄꜱꜱ is rendered in my example.
I don't think so. (I was wondering about that in comment 2 -- but the spec says the children are not rendered, and <style> elements don't directly have anything to render. <style> impacts how *other* elements render, but it already doesn't have anything to render itself.) Moreover, all browsers that usefully support requiredFeatures (Edge 0.11, Safari 9 (WebKit), Opera 12.16 [Presto], and Firefox) behave like we do in this respect. So it's unlikely that we'd change away and switch to being un-interoperable with everyone else on this point -- and if the spec does require that we do that [which isn't clear to me], then it may be better that the spec should change. Moreover, it seems like requiredFeatures may change soon anyway so that it'll always pass (per comment 10). All of which I think makes this still INVALID.
Created attachment 8647719 [details] testcase 3 to see whether <style> inside of failing requiredFeatures test is honored For illustration purposes, here's a simple testcase with <style> inside of a failing requiredFeatures test. As noted above, all browsers which usefully support requiredFeatures behave interoperably on this & render it the same. [Chrome renders it slightly differently than everyone else, in that it also renders the "BUT:" text because it spuriously passes the requiredFeatures test.]