Not discussing the good and bad of tracking pixels here, I wonder whether it is ok to set width and height of a tracking pixel to 0 each?
All examples and usages I see use a value of 1 for these, so I wonder if there is any reason for it?
I just quickly tried it in Chrome and saw that indeed, an image with width and height set to 0 is requested by the browser, despite not being rendered.
Maybe there are browsers out there that would not send a request to 0-dimensioned images and this is the reason why all examples use 1 pixel?
Could anyone enlighten me here?
Ok, it obviously is ok to use a value of 0 für tracking pixel width and heihgt. There are examples out there that use these values.
Pro: You can skip CSS for hiding these pixels.
Related
Good morning!
I'm currently trying to create a view similar to this mockup.
I have put down 3 different screen sizes so you can see the issue.
I have a header background image (grey box) with an angled bottom. On the right I want to display an image, which obviously needs to be positioned.
Positioning it horizontally is no issue but how can I position the image vertically? I have it positioned fixed for one screen size but obviously need to make it flexible.
Any ideas? Help would be much appreciated!
David
You can definitely use measure as #rajesh pointed out, or you can use Dimensions. As far as getting the layout consistent across devices, using position absolute and measuring the device height should allow you to get consistency across these devices.
Check out this example I set up, it should be a good starting point at least.
https://rnplay.org/apps/pSzCKg
I find great support for very small edge width and node border width, very useful when we zoom in deeply:
cy.edges().style({"width": 0.01})
cy.nodes().style({“border-width”: 0.01})
but font-size is less malleable: any font-size less than 1 appears to be clamped to 1. Thus the last three of the following commands, executed from the javascript console, produce the same result:
cy.nodes().style({"font-size": 10}) // big font
cy.nodes().style({"font-size": 1}) // much smaller
cy.nodes().style({"font-size": 0.1}) // unchanged
cy.nodes().style({"font-size": 0.01}) // unchanged
In each case (using the last as an example) the font-size property seems to be properly assigned:
cy.nodes().style("font-size”) // “0.01px"
But the rendered node size remains at 1. Any ideas?
Thanks!
Paul
This has been answered on Github. This is an issue that some browsers have, and there's nothing that can be done in the library to change the browser's behaviour
--
Copied from Github : https://github.com/cytoscape/cytoscape.js/issues/1173
This is a limitation of how browsers implement font rendering in canvas. There's nothing we can do in this case on the library side.
The only suggestion I have is to scale up your styles. Multiply your sizes by a factor such that the font size is at least 1px. While font sizes can't scale, the zoom level can scale arbitrarily. Your zoom levels will be different, but zoom is just a relative measure anyway.
I'm working with documents, so maintaining the the original image dimensions and subsequent dpi is important.
The aspect ratio is always maintained so the automatic fill modes and alike don't seem to have any effect.
Say I have a 300 dpi document and the user want to clear an inch border around the image. So I need an inch cropped from the image but the result needs to be the original image dimensions (2550x3300).
I have been able to achieve this effect with...
...&crop=300,300,-300,-300&margin=300,300,300,300
This works, but seems more than a little clunky. I've tried a lot of other combinations but they all seem to enlarge or reduce the image size which is undesirable in my case.
So does someone know a simpler syntax to achieve the desired result, or do I need to re-size the image then calculate and fill with a margin as I'm doing now.
Thanks
It turns out that my example requests the image in it's full size which turns out to be a special case. When I introduce a width or height into the command line things don't work very well since crop size is in respect to the original image dimensions and margin size is in respect to the result image.
Thinking about it more I abandoned the crop approach. What I really needed was a way to introduce a clipping region into the result bitmap. So I built an extension to do just that. It works well as it doesn't interfere with any of Resizer's layout calculations and the size of the returned image is whatever the height or width were specified as. Which is just what I needed. The Faces plugin has an example of introducing a clipping region.
Karlton
Cropping and re-adding 300px on each edge is best accomplished exactly the way you're doing it:
&crop=300,300,-300,-300&margin=300
What kind of improved syntax would you expect? This isn't a common operation.
(this is for running reports outside of rally via the loginKey - currently using 1.26, although i have tried using up to 1.32 with no difference in results)
it seems that even though the iteration burndown chart accepts width and height parameters, they are not reliable in any sense, and often not honored at all. if i extract it down to the rendered iframe, i see the following link:
https://loginapirally1.rallydev.com/slm/analytics/reports/4/run?WIDTH=1024&HEIGHT=768&ITERATIONS=[MY_ITERATION]
but the chart is not near that size at all - often it seems to default to a very small size (540pt x 300pt) no matter what w/h is requested. in my implementation, i have the burndown chart in a div that is first adjusted to the size of the window and then those dimensions are passed to the cart object. at some sizes, it will come close to taking up the space, but at others it will revert back to the default size.
is this a known issue? am i missing anything obvious? thanks in advance for any thoughts anybody has!
For whatever reason, I have found that the largest I can get most all of the standard reports is Height = 599 and Width = 999. If I go with anything larger, I end up getting back a size much smaller than 599x999. One exception is the Velocity Chart, in which if you have Height of 599 it is large but has a vertical scroll bar, but if you make the height 600 it is smaller and does not have a scroll bar.
i have received confirmation from rally support that indeed this is the max supported resolution when using loginkey:
"Just wanted to let you know that I have received confirmation from our engineering team that the maximum resolution through LoginKey is indeed 600x1000, so the 599x999 would indeed be correct."
How does Safari determine what size to output an svg in the following scenario;
SVG code
viewBox 0 0 800 800
height 100%
width 100%
css
svg width 100%
containing div width 60%
Safari outputs a much smaller svg than the 60% of screen, ok this is a bug. But what determines the size of this smaller svg, it has no connection to anything I can think of.
Just to give some background info. Safari needs both width and height in px for it to do what you want. % don-t work. But it does output the svg, and so it must make a decision somewhere about its size.
It's not a bug you're seeing. That's the correct behavior. The browser by default scales the SVG viewbox (careful with the terminology now, we're not talking about the browser viewport) to fill the CSS-determined dimensions of the SVG element. The fill behavior is determined by the SVG preserveAspectRatio attribute. By default it's set to meet, which keeps the whole SVG viewable, and the aspect ratio preserved. The alternative is slice which scales the viewbox up to cover the element, even when that means cropping. (slice behaves similarly to background-size:cover in CSS3.)
What you need to do is:
a) Don't declare explicit height or width in the SVG file. If your graphics editor is generating them, just go in by hand and delete them. According to the spec, if no width and height are specified, a value of 100% is assumed, so your pseudocode is redundant at best.
b) Make sure you're setting an explicit height for the svg element in CSS. I recommend developer or Canary builds of Chrome for troubleshooting responsive svg sizing, as there is a bug in Chrome 18 Dev Tools that has since been fixed. Once you've got it working in Chrome, it will almost certainly also work in Safari.
c) Figure out how you want to set preserveAspectRatio and manually edit the svg to put in the declaration.
If you're still having trouble, please post a jsfiddle. It's much easier for other people to comment on.