I have a mobile application that involves moving of text in a marquee way. I used css3 animation and it looks laggy on the mobile. I choose to use svg as an animation. How can I implement a marquee animation in a svg. I am new in this.
Here is a simple animation with scrolling text. Hopefully this will get you started.
There are numerous tutorials on the web on how to do SVG animation. You could also read the SVG specification if you want more information.
Note that SMIL animation like this (SMIL is animation that uses the <animate> tag) does not work in IE. But you could use a library like FakeSmile if you need to support IE.
<svg width="500" height="100">
<text x="0" y="80" font-size="80">Here is some scrolling text
<animate attributeType="XML" attributeName="x"
values="520;-880;520" dur="15s" repeatCount="indefinite"/>
</text>
</svg>
Related
I am developing a web page trying to focus on accessibility, and created different graphics in SVG to go in it. After reading different sites online (1, 2, and 3), I included the <title> and <desc> tags, and added the attributes role and aria-labelledby to make the SVGs more accessible.
Some of those sources, seem to claim (directly or indirectly) that using SVG inline is better for accessibility; so I ran a few tests with NVDA to see the differences, but I fail to see any at first sight.
For example, using a simple SVG:
<svg width="100" height="100" viewBox="0 0 100 100" role="img" aria-labelledby="title desc">
<title id="title">Abstract Forms</title>
<desc id="desc">Red square containing a white circle containing a blue triangle pointing up.</desc>
<g stroke="none" stroke-width="0">
<rect x="0" y="0" width="100" height="100" fill="red" />
<circle cx="50" cy="50" r="40" fill="white" />
<path d="M 50,20 80,70 20,70 Z" fill="blue" />
</g>
</svg>
If I add it to the page like that, NVDA reads "Graphic. Abstract Forms. Red square containing a white circle containing a blue triangle pointing up."
And if I save it into a myImg.svg file, and add it to the page like this:
<img src="myImg.svg" alt="Red square containing a white circle containing a blue triangle pointing up" title="Abstract Forms" />
NVDA then reads "Graphic. Red square containing a white circle containing a blue triangle pointing up." (same thing as before, just not reading the title).
This may be an NVDA thing, and other screen readers may do it differently, but there doesn't seem to be any considerable difference between the two. At least not to claim that inlining the SVG is better for accessibility.
Then I thought it could be related to reading additional information; for example, if there was some text within the graphic. So I added a <text x="50" y="50" fill="black">Hello World</text> at the end of the SVG... but NVDA read the same thing as before; not even selecting the text it will read it (again I don't know if this is an NVDA thing and if other screen readers do it differently).
So my questions are: what are the differences between having SVG inline or as an image? And what are the benefits (for accessibility) of having the SVG inline?
You probably already self-answered your question.
Inline-svg is interpreted as part of the html webpage. So your svg title and description are interpreted as well and read by the screen reader.
When using an ‘img‘ tag to include the svg, the file is handled like an external file (like a jpg) and so only the ‘alt‘ attribute of the img tag (= the image description) is interpreted/read by the screen reader.
I have currently no source and can't test it a the moment, but I think there are also differences for links within the svg code: Links within inline svg are read by the screenreader, links within external svg files not.
I'm trying to position SVG text so that it site entirely above the y-location at which it is located. A dominant baseline of text-after-edge appears to be the appropriate setting for this.
This works just fine in Chrome, but with Safari text-after-edge renders with the text centred around the y-location.
I explored further, as seen in this codepen:
https://codepen.io/anon/pen/obrreb?editors=1010
Here is the output in Chrome:
And in Safari:
As you can see a number of the dominant baseline renderings differ.
Jakob's suggestion to use dy is the simplest and most reliable solution. I would also suggest you use values defined in em units.
1em is the height of the font glyph from the bottom of the lowest descender to the top of the highest ascender or accent.
Descenders are typically around a quarter of an em. So to raise the text above the line use dy="-0.25em". Correspondingly, to hang below the line, use dy="0.75". See the example below.
<svg width="100%" height="200">
<line y1="100" x2="100%" y2="100" stroke="grey"/>
<text x="20" y="100" font="Arial, sans-serif" font-size="40">
<tspan>Hanging</tspan>
<tspan y="100" dy="-0.25em">Hanging</tspan>
<tspan y="100" dy="0.75em">Hanging</tspan>
</text>
</svg>
The main advantage to using em units is that they are independent of the font size. So you can tweak the value to suit your font exactly, and those em values will automatically work for any font size you specify.
I ran into the same problem recently, and found a solution that worked in my case:
After trying the dominant-baseline and baseline-shift properties only to find out that both of them don't work in all browsers I'm aiming to support, a college pointed out to me that you can use the dy attribute on a <text> element to shift it after the glyphs have been positioned along a <textPath>.
Here is some pseudocode/jsx to illustrate my solution:
<g {...}>
<path
id={textPathId}
fill="none"
transform={…}
d={…}
/>
<text
textAnchor="middle"
fill={textFill}
dy={shiftText}
>
<textPath
xmlnsXlink="http://www.w3.org/1999/xlink"
xlinkHref={`#${textPathId}`}
startOffset="50%"
>
{text}
</textPath>
</text>
</g>
Notice that this depends on the knowledge of a shiftText value that has to be known or calculated independently. If this isn't given I think the only road forward is to use a combination of dominant-baseline and baseline-shift while distinguishing the browsers used.
TL;DR: I need to mask out a portion of one rectangle in SVG, based on the size and position of another existing rectangle, which will be changing dynamically. A Chrome bug is blocking the mask + use approach I tried. How can I do a mask or inverted clip path based on an existing shape?
Full Overview:
I'm using D3.js, and I am using the brush control to add a brush to a rectangle in an embedded SVG. By default, this adds some extra elements to the SVG, including a rect with class extent that shows the size of the brushed area.
Rather than have the brush extent be rendered as a semi-transparent overlay on top of the rectangle, as in most D3 examples, I am trying to "cut out" the extent from a semi-transparent overlay, so that the brush area shows the true color below. Per this question, I am trying to do this with a mask element, with a child use element referencing the extent. With some D3 magic, I now have a structure like this:
<svg width="100" height="100">
<g class="brush-layer inverted">
<defs>
<mask id="mask835">
<rect fill="#fff" width="100%" height="100%"></rect>
<use fill="#000" xlink:href="#extent848"></use>
</mask>
</defs>
<g class="brush" style="pointer-events: none;">
<rect class="overlay" mask="url(#mask835)" width="100%" height="17"></rect>
<rect class="extent" x="30" width="52" height="17" id="extent848"></rect>
</g>
</g>
</svg>
This works great... sort of. It turns out that there appears to be a tricky Chrome bug, which I've filed here, which prevents the mask from being applied if there's a #media query in the CSS. You can see the working version here and the failing version here (fails in Chrome, works in FF).
I need this to work in Chrome, and can't drop the #media query. I also need to make the use element work, because D3 will automatically resize the extent rectangle, and that's the shape I need to mask out.
So, how can I mask out a portion of one rect, based on another rect, without using the mask + use strategy above?
One possible workaround might be to use a custom clip-path, but it's probably not going to be as elegant. Some examples of how to do do this with clip-path can be found in this question.
I have a simple cut-out rectangle with text in the middle.
<svg>
<defs>
<mask id="mytext">
<rect width='100%' height='100%' fill='white'/>
<text>Welcome</text>
</mask>
</defs>
<rect width='100%' height='100%' fill='blue' mask="url(#mytext)"/>
</svg>
However when viewing from a retina display the text edges become pixelated.
It does't happen if I only use text without masking it, but as soon the mask is used it breaks everything out.
EDIT: By Retina Display I mean, iOS and OSX both latest versions. All Browsers. I believe it might be a pixel density issue.
The interesting is while having
<text fill='url(#mypattern)'>Welcome</text>
The text is rendered sharply perfect. The problem lies only with masks being applied.
Here it is a jsfiddle sample (please make sure to test on your retina display enabled device).
And here is a screenshot displaying the difference on iPhone (note that the edges of the text below and how pixelated it looks).
I am supporting some old SVG graphics that we have in our application. I am having some issues with animating the fill color of a rectangle, and I am wondering if anyone else has seen the same issue.
We setup an animate element on the rec which ends up looking like this:
<svg id="svgEle" xmlns="http://www.w3.org/2000/svg" version="1.1">
<rect id="rect"
width="100" height="100"
style="fill:#008000; stroke:#000000;">
<animate id="animate" fill="freeze"
attributeName="fill" attributeType="CSS"
begin="indefinite" dur="1s"></animate>
</rect>
</svg>
And then, depending on values from a webservice result, we change the color of the rect and attempt to animate the color change. Currently it seems as if Chrome is the only native SVG render that supports the beginElement function. The animation works perfect on the first run, but all subsequent attempts to update the animation do not behave as expected. They always seem to revert to the first animation's fill color.
I have created the following example to show what I mean: http://jsfiddle.net/ssawchenko/ARXbs/
In Chrome the rectangle SHOULD cycle through all 4 colors via an animation when you click on the button, but it does not. In IE9 animation is not supported, so the fill color is just changed directly.
I am ok with IE9 simply setting the fill, however, in Chrome the colors are completely busted. Does anyone know if this is a bug, or if there is a work around?
Thanks!
This bug also exhibits in SVG Edit.
<animate attributeName="opacity" begin="indefinite" dur="1" fill="freeze">
</animate>
If you draw rectangles on top of each other you will see they seem semitransparent when they should be fully opaque. I've seen that Chrome Canary doesn't exhibit this behaviour, so it might be fixed in the next release.
I think this filed bug is related.