It’s just data

SVG Interop

Dean Hachamovitch: I think it’s important to not just do SVG but have complete tests so SVG works the way developers want it to

I am a fan of SVG.

On the lower right of this page is a “watermark”.  If you are viewing this page using IE, you won’t see it.  If you are viewing this web page using a recent, released version of Opera or Firefox, you will see it in its entirely.

If you are viewing this post using WebKit (either through Chrome or Safari), it will be clipped oddly on two sides.  Apparently if I resize the image to precisely match the window size (taking in consideration the font size used), I can kinda sorta get this to work — but in the process I lose the “S” in SVG.

Perhaps this is just a run of the mill bug, but the point is that it is entirely too easy for me playing with SVG using vim to hit such bugs.


Remove footer svg {opacity: 0.3;} and it works...
Strange

Posted by Alkarex at

And if you put your SVG block in a div, it works too...

footer #svg {
...
}
<div id="svg">
 <svg ... />
</div>
Posted by Alkarex at

Since you didn’t specify the height and width of the SVG, what implicit process are you expecting is determining them?  Where is that process documented?

Posted by Patrick Mueller at

Patrick: When the SVG’s @width and @height are 100%, the SVG’s viewBox will match the HTML’s parent container based on @preserveAspectRatio value.

"The size of the SVG viewport (i.e., its width and height) is determined by a negotiation process (see Establishing the size of the initial viewport) between the SVG document fragment and its parent (real or implicit)."

On this page, the dimensions of the SVG are set in CSS with a “em” unit.

Posted by Alkarex at

Since you didn’t specify the height and width of the SVG

Actually, I did specify the height and width, in my CSS, thus:

footer svg {
  position: fixed;
  bottom: 2em;
  right : 1em;
  width: 14em;
  height: 14em;
  opacity: 0.3;
  overflow: visible !important;
}

The last line was an unsuccessful attempt at a workaround.

Posted by Sam Ruby at

To speak to Dean’s points regarding which version of SVG:

Also, I’ve been hearing this line from Microsoft for a couple years now, but I have yet to see any participation on the public www-svg mailing list.  If they are really trying to figure this out, then shouldn’t they have raised at least a question on that mailing list? 

Personally, I don’t think there’s any question now - all browsers have been targetting SVG 1.1 Full for years now.  IE9 should target that spec as a starting point.  The test suite for 1.1 is not as complete as the one for 1.2T, but Microsoft could definitely use the 1.2 test suite as a starting point.

Note that there are some nice things in SVGT 1.2 that Opera has started to experiment with (textArea, video, audio, focus), and I’m not sure when (if) we’ll see the first implementations of SVG Transforms show up.

Posted by Jeff Schiller at

Also, I’ve been hearing this line from Microsoft for a couple years now

We will know that Microsoft is serious when they contribute test cases.

Posted by Sam Ruby at

Weasel words. The man should be running for Governor of Alaska, I’ve never read so many weasel words.

I’m assuming you tried your logo with pixels, and found it works, and the point you’re making is how the different browsers handle em units?

Posted by Shelley at

I tried it with pixels, and it improved but still cut off. I mentioned about the em, because I know there’s an old bug on this at WebKit, and not sure if it was fixed. Assumed it was, but you never know.

I’m with Alkarex above — I put your SVG in a DIV element at my site, and then applied the CSS to the div. I do the same with any of my background SVG elements, specifically because I typically have sizing problems with Safari/WebKit. More importantly, I can get some painting problems with Opera without doing this.

The problem with the test cases is that all of them are stand alone SVG, if I remember correctly, which means that SVG embedded in a web page isn’t getting tested. There’s only been a few folks using SVG for decoration. Most people won’t because IE still has so much market share.

Posted by Shelley at

Sorry, I meant SVG inline in a web page isn’t getting tested...

Posted by Shelley at

Sorry about so many comments, but I like debugging SVG.

I now have the SVG without an enclosing DIV, and the following style:

position: fixed; bottom: 20px; right: 50px; width: 140px; height: 140px

But, again like Alkarex mentioned, I had left off the opacity, which is why it worked. Wow, now that is a really strange error. You might want to submit that one to WebKit.

(Tried to post with other info, and got this)
traceback:Traceback (most recent call last):
  File “gateway1.cgi”, line 47, in <module>
  identity.validate(dict(cgi.parse_qsl(os.environ['QUERY_STRING'])))
  File “/home/rubys/mombo/identity.py”, line 63, in validate
  file = writeComment(session['parent'],title,body)
  File “/home/rubys/mombo/post.py”, line 244, in writeComment
  raise Exception(message)
Exception: POST limit exceeded

Posted by Shelley at

I’m assuming you tried your logo with pixels, and found it works, and the point you’re making is how the different browsers handle em units?

Actually, not.  I got something that worked in Firefox.  At that point I began testing the result in other browsers.  It was not a surprise to me that it didn’t work the first time.  The fact that I don’t have that expectation is the problem I would like to be solved, not a workaround.

I’m with Alkarex above — I put your SVG in a DIV element at my site, and then applied the CSS to the div.

I will note that this page has zero div and span element today, and I would like to see how long I can continue with that approach.

SVG inline in a web page isn’t getting tested

An obvious area of potential improvement.

Exception: POST limit exceeded

That’s my throttle logic misbehaving.  I try to limit the number of consecutive posts made by a single individual in a brief period of time, but that’s implemented partially at different layers, and at the top layer, those that are OpenID enabled get a lot more leeway.  Apparently, that means that ultimately the lower level safeguard ultimately triggers, and an a way that isn’t user friendly.

On the good news, I’m told that Passenger (a.k.a. mod_rails) is now installed on Vanadium on Cornerhost, meaning that my mythical Rails rewrite may become significantly less mythical sometime soon.

Posted by Sam Ruby at

Well, I do tend to over-comment when I get engaged with something interesting. And you might say your error message is friendly...to a geek.

I more or less know how to work around most problems with inline SVG now, knock on wood. So much of SVG is changing now, as new browser versions implement new SVG features by leaps and bounds. Still one can typically tell why something has gone wrong. The thing with opacity and sizing with your logo is completely new one — would make a good test case, eh?

Agree that test cases for inline SVG would go a long ways to encouraging the use of SVG for decorative purposes. But then, this really challenges the purpose for SVG. I don’t think the creators of SVG foresaw the day when SVG would be used inline for decoration, only, even though its use is ideal because it is so scalable.

I’ve had bizarre, even dangerous side effect with my inline SVG, such as the Chrome CPU spike with resizable SVG inline in a web page, sized to fit around the entire contents of the page. Seriously, if the pattern is strongly diagonal, Chrome had a hissy. This wasn’t a Webkit issue, either, but a graphics rendering engine problem.

Enough rambling. The point is, no browser implements SVG perfectly, but they’re improving. What’s holding us up is not enough interest because a major browser is a no show. It’s catch 22 — Microsoft won’t implement SVG because they imply its use isn’t widespread, but it isn’t in widespread use, because MS won’t commit to implementing in SVG, and around we go.

Have you ever though about using an existing CMS, like Drupal?

Posted by Shelley at

Out of interest, is it the SVG that makes the scrolling on these pages painfully slow in Firefox, or the combination of SVG and fixed position elements, or what?

Posted by andy at

would make a good test case, eh?

Anybody have any advice on how to most effectively create a bug report on fixed svg images with an opacity being clipped on webkit?

Have you ever though about using an existing CMS, like Drupal?

For the moment, for me, Rails won.

scrolling on these pages painfully slow in Firefox

I’m not seeing that.

Posted by Sam Ruby at

Sam, check out this bug report:

https://bugs.webkit.org/show_bug.cgi?id=14240

Doesn’t it sound similar to your problem? Anyway, this is a good demonstration of how to report this type of bug to WebKit.

As for jerky movement with Firefox — fixed images can inhibit smooth scrolling

Posted by Shelley at

Shelley: Thanks!  I added a comment to that bug report.

Do you see jerky movement scrolling with Firefox on this page?  I’m using Firefox 3.0.7.

Posted by Sam Ruby at

scrolling on these pages painfully slow in Firefox

I’m not seeing that.

Latest Firefox 3 release on XP, and scrolling is fairly slow for me, too.

Posted by Scott Johnson at

Do you see jerky movement scrolling with Firefox on this page?  I’m using Firefox 3.0.7.

I neglected to refresh before posting my last comment.  Afterwards, I thought I should add this:  I don’t see jerky scrolling in Firefox.  It’s just slower than usual.  FF3.0.7 on XP.

Posted by Scott Johnson at

No, I’m not seeing it with Firefox 3.1 on the Mac. But people have had scrolling problems in the past when I’ve used fixed images, which is why I stopped using them. I doubt it’s the SVG, as the only time I’ve had problems with SVG is if I resize the SVG background image to stretch to fit the entire page’s contents. Then, depending upon pattern, you can see a host of redraw issues with all browsers, not just Firefox.

Actually, Firefox is the best when it comes to redrawing content stretched SVG images with preserveAspectRatio set to “none”.

Posted by Shelley at

I’m using Firefox 3.0.7 with Xubuntu Intrepid 64 bit, which I know full well I should have stated in my first post, but didn’t for some unfathomable reason. I’d be inclined to suspect the fixed position stuff, which generally seems to cause problems, though some SVGs also cause slowdowns.

Posted by andy at

But people have had scrolling problems in the past when I’ve used fixed images, which is why I stopped using them. I doubt it’s the SVG, [...]

I’ve had similar problems with fixed images as well, so I’m inclined to also think it’s not exactly related to SVG.

Posted by Scott Johnson at

Two things that would help me hugely:

1) Lots and lots of unit tests have SVG being directly embedded into HTML (more text/html in my case, but XHTML is ok). Like Shelley mentioned (and you’ve found), this is underspecified. I’ve had to reverse engineer what Firefox and Safari does.

2) Lots and lots of unit tests of dynamically manipulating SVG using the DOM using JavaScript, including changing the CSS dynamically. Again I’ve been building up my own unit tests, using Firefox and Safari as a guide.

Both Firefox and Safari have alot of holes around these, so I don’t like having to depend on them to know the correct behavior. I probably should be depending more on Opera as a guide, since their SVG implementation is the best so far.

Best,
  Brad Neuberg
  [link]

Posted by Brad Neuberg at

@Alkarex:

“The size of the SVG viewport (i.e., its width and height) is determined by a negotiation process (see Establishing the size of the initial viewport) between the SVG document fragment and its parent (real or implicit).”

That paragraph of the SVG 1.1 spec was a pain in the butt. All it does is mention that a negotiation process occurs; it would have been nice to provide a sample, non-normative algorithm for doing so in an HTML container context. I had to reverse engineer this by seeing what other browsers do, and there are ways I still don’t have it right.

These are the kinds of things that are nice about the HTML 5 spec — it generally provides you an algorithm based on either reverse engineering existing work or a reasonable algorithm to actually implement things like this to prevent different implementations from having different behaviors.

Also, a question for Sam — I showed you a few days ago how I embed SVG into HTML using the SCRIPT element. You mentioned that no AT readers see the SVG TITLE or DESC elements currently; they definently won’t see it in my screen tag. Do you think there is some way I can use ARIA to dynamically notify any AT technology that is attached about the SVG title and desc elements?

BTW, it’s official — the rate limiter on here is really annoying. :) It’s like DRM — it hurts those who want to actually post good content on here and respond to several other posters over time. You should take a cue from what Ajaxian does and prompt readers with some custom questions that are technically oriented that your audience would know, such as “What does SVG stand for?”. Ajaxian says “What is the X in AJAX” for example. Drop the rate limiting :)

Best,
  Brad Neuberg
  [link]

Posted by Brad Neuberg at

Brad, how SVG is sized in a CSS context is defined by the CSS specification (an SVG fragment counts as a replaced element).

(Sam, your comment system thinks I’m new here.)

Posted by Anne van Kesteren at

If you embed SVG via the script element, you won’t have the problem of back-level user agents rendering the text inside elements they don’t understand (a problem for desc, but not for title), but you will have the problem that such scripts can’t embed scripts.

Posted by Sam Ruby at

Hi Sam; you can embed SCRIPTs inside nested SVG if you namespace all your SVG with a prefix, such as svg:script.

Posted by Brad Neuberg at

Hi Anne, I appreciate that. Would I find that in the CSS 2.1 spec? Do you know the relevant section by any chance?

Posted by Brad Neuberg at

I do. CSS 2.1, section 10.3.2 and section 10.6.2 have most of the details. (Language is not easy to follow, of course.) Sorry for not pointing this out directly. I sometimes assume everyone reads the same stuff I do :-)

Posted by Anne van Kesteren at

Mencoba Inline SVG di peramban Opera

Animasi dengan inline SVG (Scalable Vector Graphics) ini hanya sempat saya coba di peramban Opera 10.00 Linux. Mungkin juga dapat tampil normal di beberapa peramban modern Anda (Opera 9.x+, Firefox 3.x+, Safari 3.x+). Maaf untuk pengguna Internet...

Excerpt from Dani Iswara .Net at

pls disregard previous comment, worked out my svg didn’t have a viewbox set. sorry

Posted by David Semeria at

Add your comment