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
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.
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.
And if you put your SVG block in a div, it works too...
footer #svg { ... }
<div id="svg"> <svg ... /> </div>
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.
On this page, the dimensions of the SVG are set in CSS with a “em” unit.
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.
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.
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.
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?
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.
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
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.
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?
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.
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
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.
I’m not seeing that.scrolling on these pages painfully slow in Firefox
Latest Firefox 3 release on XP, and scrolling is fairly slow for me, too.
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.
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”.
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.
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]
@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]
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.)
desc
, but not for title
), but you will have the problem that such scripts can’t embed scripts.