I've tried to make some hexagon-based map in SVG. Unfortunately, there are white spaces between fields.
I've disabled fields' borders (stroke="none stroke-width="0"), rounded all floating points to integers and made sure that hexagons have common points (no space between them). It didn't help.
Two screenshots shows same SVG in different magnifications http://imgur.com/GLiJs,gi3pt
Source code is here: http://pastebin.com/hqwTKW4M (remember to change extension to svg, after download).
Setting shape-rendering property to 'crispEdges' for all hexagons (or group of them) solves this issue. E.g.
<polygon
points="0,90 45,12 135,12 180,90 135,168 45,168"
fill="green" stroke="none" stroke-width="0"
shape-rendering="crispEdges" />
http://www.w3.org/TR/SVG/painting.html#ShapeRenderingProperty
Related
I noticed the the root coordinates for a text element are not at the top left corner like a rect element:
Is there a way to set it such that when a text element is at (0,0), it fits inside the parent element?
If I understood you well, you can use this:
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/dominant-baseline
A) Chromium browsers
svg {
dominant-baseline: hanging;
}
https://jsfiddle.net/e7vc4bqj/
B) Chromium and Firefox
.text {
dominant-baseline: hanging;
}
https://jsfiddle.net/3zskd148/
SVG text coordinates are used to define its left bottom corner by default:
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/text-anchor
Hope this help :)
Why are the SVG Text elements too high?
The x and y coordinates of a <text> element specify the start of the baseline of the text. This makes complete sense. You wouldn't want it to be the top left of the first character - because it would then be a difficult job to get text of different sizes and styles to line up.
There is no global option in SVG that changes that behaviour. However see below for alternatives)
Is there a way to set it such that when a text element is at (0,0), it fits inside the parent element?
Normally you would just adjust the y coordinate based on the font size.
However there are a couple of alternatives you can use:
One is the xxx-baseline properties (as #gengns has pointed out), that can alter how the character glyphs are positioned relative to the baseline. Note however, that those attributes are not entirely reliable, due to mixed browser support. Plus they depend on the font containing the correct data tables. Not all fonts have those tables.
A better option IMO is to use the dy attribute. This adds a relative offset to the text position. Meaning the text is actually positioned at (x, y + dy). And it is supported by all browsers.
<svg width="200" height="150">
<rect x="0" y="0" width="200" height="150" fill="skyblue"/>
<text x="0" y="0"
font-size="25px" dy="1em">asd</text>
</svg>
Filling and stroking a circle with the same color and a stroke-width exceeding a certain size, produces a strange transparent region “between” the two paint regions. What is going on?
This is happening in both Chrome and Firefox, so it may be to spec, but I couldn’t find any language in the spec about this behavior.
Fiddle
<svg viewBox="0 0 300 300">
<circle cx="100" cy="100" r="8"
stroke="#000" stroke-width="40"
fill="#000"/>
</svg>
Produces this rendering:
As Robert Longson noted, the issue shows up when a stroke overlaps itself in such a way that it creates a donut-hole when you convert the stroke outline to a separate path (depending on the winding-order / fill-rule calculations).
The gap between the fill and stroke in your particular example is caused by the "inside" edge of the stroke extending across the entire fill region and out the other side.
It gets really weird when you have dashed strokes, as shown in the examples from Tavmjong Bah's discussion article.
This is, unfortunately, neither according to the SVG spec nor against the spec. Instead, the spec at this point of time has left the matter undefined.
SVG working group discussion is here.
At this point, WebKit, Blink, and Firefox on Mac/Android draw strokes with cut-outs, using the Skia graphics library or Apple's CoreGraphics.
IE/Edge and Firefox on Windows/Linux just draw the total stroke, without cut-outs, as do Inkscape and Illustrator and most PDF-rendering software (the PDF spec itself is non-committal).
Everyone I've discussed this with agrees that the cut-outs are a sub-optimal result. But with so many browsers using rendering engines that do it this way, the SVG working group wasn't willing to make the more-intuitive stroke behavior a strict requirement. So instead, the SVG 2 spec has a warning-to-authors with a sample figure:
At this point, the best prospect for making a change would be to file issues (or contribute code) on the Skia library. If it was changed, that puts pressure on Apple to update to match, and the SVG spec would be able to make it official.
I found that adding stroke-linecap="round" style="stroke-dasharray: 1000" fixes the issue by introducing virtual dashes
<svg viewBox="0 0 300 300">
<circle cx="100" cy="100" r="8"
stroke="#000" stroke-width="40"
fill="#0F0" stroke-linecap="round" style="stroke-dasharray: 1000" />
</svg>
It's an artifact because the stroke width is so big it crosses the centre of the circle. It shouldn't happen but it's easily avoided by increasing r and decreasing the stroke-width.
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 have a SVG path scale to fit the entire container element, without stretching or being trimmed. The SVG is the one below. As you can see, it's a simple border.
<svg preserveAspectRatio="none" viewBox="0 0 370 80" height="100%" width="100%">
<path vector-effect="non-scaling-stroke" d="M359,70C359,70,300,70,185,70C84,70,9,70,9,70C9,70,9,60,9,40C9,24,9,10,9,10C9,10,84,10,185,10C300,10,359,10,359,10C359,10,359,24,359,40C359,60,359,70,359,70C359,70,359,70,359,70"/>
</svg>
Then I have an element that could have different sizes, because it's responsive and because I use it in various cases where width or height can be different. I can't succeed in having the SVG that expands its path by always staying inside the viewport, but scaling without preserving aspect ratio. It doesn't seem a difficult logical thing to do, but I tried various options without success.
EDIT
I was able to scale this SVG, by setting whatever dimensions I wanted. Why does the first not work, but this works instead?
<svg preserveAspectRatio="none" viewBox="0 0 404 77" height="100%" width="100%">
<path vector-effect="non-scaling-stroke" d="m0,0l404,0l0,77l-404,0l0,-77z"/>
</svg>
The short answer is no. What you want to do (as I understand it) is not possible. In SVG you can scale to fit the container (using constant aspect ratio), or you can stretch (ignoring aspect ratio).
There is no way currently to keep some parts of the SVG static and stretch other parts. Unless, of course, you use Javascript to manipulate the contents of the SVG.
What you may want to do is consider using an SVG as the source image for a CSS border-image (see http://www.w3.org/TR/css3-background/#border-images). Perhaps that is the sort of thing you were after?
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.