I'm trying to use Susy but I can not create a desirable grid. I want a fixed gutter grid with the gutters coming after the element, not before. I couldn't get that to work. It seems that no matter what I do the elements are too large and the last column falls to the next line.
See this gist:
http://sassmeister.com/gist/6ebf5ec14f697f8d137c
In this basic three column layout each 1/3 width column is over 35% wide. What am I missing?
I only see width: 28.57143%; in your sassmeister output. The problem is actually caused by your border on all the elements. That adds several extra pixels to the layout, forcing it to break. You can either remove the borders, or add box-sizing: border-box so that borders no longer add to the element width. Susy has a border-box-sizing mixin that will apply that globally, if you want.
Related
I am using elements of width 1.5 to connect elements. This all looks fine but if the image is dynamically scaled down to show more of the diagram then some of the lines eventually disappear in Firefox but not in Chrome. Is this a problem in the Firefox SVG support, or some difference in default settings that I can change?
Rather than present any code, I can point to an example in a blog-post at: https://parallax-viewpoint.blogspot.com/2018/12/further-travels-of-walking-boots.html. Scroll to the bottom of the post and there's an embedded SVG "family tree" image that uses the JavaScript pan-zoom library to dynamically scale the diagram.
On the default setting, in Firefox, not all lines will show -- probably dependent upon whether they fall on a pixel boundary or not. As the image is gradually scaled up, you will notice that the lines will eventually all show. Contrast this with Chrome where the lines always appear to show.
New information from Firefox support: there is a pronounced "redraw" fluctuation for all transformations (+ or -) from the initial position. The lines are markedly thinner after the redraw, and this suggests some sort of rounding error is occurring.
The suggestion of using double lines (one with non-scaling-stroke and one without) runs into a few issues. If the line elements have stroke-opacity less then 1 then the superposition shows through. Also, with SVG 1.1, it does not appear to be possible to encapsulate the drawing of two lines in a single group/symbol if the line lengths are related but not equal. Unequal lengths are necessary to prevent corner gaps where orthogonal lines don't reach fully into the corners. Using calc() to adjust one length relative to a 100% length doesn't work with line elements because they use pairs of coordinates rather than lengths. I tried using a rect in place of a line but Firefox did not support CSS control over its width/height in order to use calc().
The solution was simply to use opaque lines (stroke-opacity=1.0), suggesting that the disappearance of the lines was due to Firefox's handling of stroke-opacity < 1.0. It may be the case that lines will eventually disappear at minute scales, but the reported problem was specifically that Firefox lost them much earlier than it should, and compared the situation with Chrome (which worked OK).
I want to have 6 objects (buttons) laid out inside one view. They should, however, follow some constraints:
Two top buttons should have the same vertical distance from superview (A)
Two bottom - the same (C)
Two in the middle should have their centers at the superview's center line
The vertical distances between all buttons (E) should be the same
and last but not least - the buttons should be square (so the width and height should be the same)
A = C
B = D
Is it possible to have this effect just in the IB, or should I use some additional code for the constraints?
This is a logical request, but constraints are defined using the attributes of views, but cannot not be defined in relation to other constraints. That having been said, there are a number of approaches:
Layout guides: An approach which doesn't require predetermining the any spacing is to have UILayoutGuide objects or, if using iOS versions before 9, just use hidden views, i.e. views with clear background or alpha of zero, in between the buttons.
The idea is to add these layout guides with addLayoutGuide (or add invisible views with addSubview if supporting iOS versions predating iOS 9) in between your six buttons as "spacers", and define the spacers to be the same size as each other, and with constraints between the spacers, the superview, and the buttons that will go in between the spacer. Once you lay that out (showing the horizontal spacer views in blue, vertical ones in red, just so you can see them):
The equivalent VFL for the constraints for those red UIView objects, called vspacerX, would be:
H:|[vspacer1][button1(100)][vspacer2(==vspacer1)][button2(==button1)][vspacer3(==vspacer1)]|
H:|[vspacer1][button3(==button1)][vspacer2][button4(==button1)][vspacer3]|
H:|[vspacer1][button5(==button1)][vspacer2][button6(==button1)][vspacer3]|
And constraints on the blue UIView objects, called hspacerX, like:
V:|[hspacer1][button1(100)][hspacer2(==hspacer1)][button3(==button1)][hspacer3(==hspacer1)][button5(==button1)][hspacer4(==hspacer1)]|
V:|[hspacer1][button2(==button1)][hspacer2][button4(==button1)][hspacer3][button6(==button1)][hspacer4]|
You don't have to use VFL to define these constraints, as any way you define these constraints will work, but it's just a concise format for describing the collection of constraints that I employed.
Anyway, when the view is rendered with those layout guides (or invisible views), it yields evenly spaced buttons like so:
Another approach is to have six "container" views, that would look like:
The equivalent VFL for these six container UIView objects might look like:
H:|[container1][container2(==container1)]|
H:|[container3(==container1)][container4(==container1)]|
H:|[container5(==container1)][container6(==container1)]|
V:|[container1][container3(==container1)][container5(==container1)]|
V:|[container2(==container1)][container4(==container1)][container6(==container1)]|
You can then add your buttons to that, centering one on each of the six little containers and then make your containers clear:
This works, too, but just a slightly different spacing (where the margins are half of the spacing between the views, whereas the other approach keeps the margins the same as the spacing between them.
Stack view: In a permutation of the prior point, in iOS 9, you can also use UIStackView, designed precisely for evenly spacing views. In this case, put two buttons each in three horizontal stack views, and then place those stack views within a vertical stack view. This achieves six evenly sized container views.
See WWDC 2015 video What's New in Cocoa Touch.
The problem with stack views is that they can be used to ensure even spacing between the arranged subviews, they don't ensure spacing before the first arranged view nor after the last arranged view. So, the kludge to get around that is to, for horizontal stack view, include two more zero width views (or zero height for vertical stack views). Then when you use even spacing on the stack view, it also give you what will appear to be spacing before and after all of the arranged subviews.
NSLayoutAttributeCenterX with multiple: Another technique involves defining the attribute:NSLayoutAttributeCenterX and attribute:NSLayoutAttributeCenterY attributes for your six buttons, but rather than using the constant values, use the multiplier field. This technique enjoys a little simplicity, but doesn't always render the desired effect, so I won't describe it unless it's something you definitely want to pursue. I've already entered tl:dr territory here.
Collection view: Another approach is to use a UICollectionView, which handles this scenario gracefully. It's well designed to let you layout cells in a grid.
Hardcoding values: For the sake of completeness, I'll note that you could simply specify specific values for A, B, C, and D (as well as the width and height constraints). You don't even have to worry about setting the E constraints, but rather just set the vertical center constraint of the middle two to their superview, and you're effectively done (because the spacing represented by E should be a natural result of the previous steps, assuming A=C and B=D). If you want to adjust these values on the basis of device size and/or orientation, you can then implement a viewWillLayoutSubviews to adjust the constants for these constraints according to the size of the view.
Update: I have a better solution that does not use spacers. Check it out here.
Ok, this can be achieved very quickly in IB. It's so so simple. Here's a diagram that will help illustrate.
Assume v1-6 are your buttons, and s1-5 are your spacers.
1) in IB control drag out all of the connections shown by the red lines.
2) shift click v1-6 and pin icon (looks like |-I-| ) set the width and height to a definite value. also, set the height and width to be equal.
3) shift select s1-4 (not 5) and set the height to equal. do not give it a definite height, since this should be calculated by the system. you might also need to set the widths of s1-4 to be equal, but don't give them a definite width.
4) control drag from the centre views to the leading and trailing edge and set the centre constraint.
So, you might think, ok, this should work now. It doesn't. Here's my app running in portrait with slightly different colors. Looks good. (Notice, you would make the spacers invisible once you get it setup).
But when I rotate, oops!
What's happening here? The problem is incredibly easy to solve once we understand what's gone wrong. What we want is for IB to not shrink our views. We want IB to make the spacers and the spaces to shrink and grow as necessary, but to leave our views alone. Basically, IB has shrunk the spacers down as far as it can in portrait and to attempt to make everything fit IB has shrunk our views. But we wanted IB to shrink the vertical spaces between views and spacers, not our views. The solution is so easy. All we have to do is adjust the priority of the vertical spaces and all is well. So, select the vertical spaces in IB and adjust the priority to 750. The vertical spacing lines will show as dashed. Done.
Ok, so here's everything as we expect it.
And with the spacers made clear:
So I've got some native elements (divs) with various effects applied to them (border-radius, box-shadow and transform: scale()). When I animate them, two weird things happen:
Even though I'm not trying to animate the scale, if I don't put the scale in the animation, it is ignored.
When I put the scale in the animation, Webkit blurs the elements
See the example here: http://jsfiddle.net/trolleymusic/RHeCL/ - the buttons at the bottom will trigger the issues.
The first issue happens in Firefox too, so I'm guessing that it's because that's how the animation spec is supposed to work. Not what I wanted, but ok, I'll live with it.
The second issue is just weird. I know it's to do with 3d transform because if I (just for testing purposes) declare -webkit-perspective or -webkit-transform-style: preserve-3d; on the circle elements, it causes the blur issue as well. My confusion is that I'm not trying to transform the z index as all, and I have also tried the animations using purely translateY instead of translate.
It happens in Chrome (18), Chrome Canary (20) and Safari (5.1.2 & 5.1.4).
So, am I right in what I think is happening? And how can I avoid the blurriness?
Worst-case scenario: I can just use different sizes for the elements instead of scaling them, that's not really a problem - but I thought this would be a more elegant solution and now this issue has cropped up.
Refer to this answer as to why it's blurring the element: https://stackoverflow.com/a/4847445/814647
Summary of the above: WebKit is taking the original size/CSS before animating, and treating it as an image, THEN scales it up, producing the blurriness.
Solution: Make initial size the largest scale you're going to, and start it initially with a lower scale (so in your case you'd want to up the size by 5, and set the initial scale to 0.2)
UPDATE
The reason it ignores the current scale from what I understand is because you're not specifically setting JUST the translate (I'm looking up the CSS for it now). When you run -webkit-animation, it's resetting all your current transforms (scale), so you need to make sure that you have your scales in there. I'm looking up the css to change so it only changes just the position:
The best way I found is to wait the animation is complete, then apply the transforms directly to the element and remove the animation class. Something like this works for me, producing no glitches:
$m.bindOnce($m('win-text'), 'webkitAnimationEnd', function(){ //avoid blurred problem with animating scale property in webkit
$m('win-text').style.webkitTransform = 'scale(1.5) translateY(-60px)';
$m.removeClass($m('win-text'), 'final');
});
I'm using a different library than jQuery, but you get the idea.
I'm trying to create a matrix plot with mathematica. Using ArrayPlot[] I get a very nice figure, apart from the fact that it's surrounded by a white margin. I've got to the root of the problem, in the sense of the following example.
http://img689.imageshack.us/img689/8427/badmargin.png
If I try to export the resulting graphic, it exports the margin also. I want my array content to fill a rectangle of a certain size so that it can be superimposed on another image, but the ArrayPlot function produces margins that interfere.
What do?
QuickEdit: ImageCrop will not work in my case, because a) I want my resulting image to be of a certain size, and b) without specifying how wide margins I want to remove the automatic version may mess with my graph (first row may well be white, for example).
Try PlotRangePadding->0
Apparently my reply was too short, so I'm typing more.
If you set the option Background->None the edges should be transparent. This would work if you were embedding it in another graphic.
With jqGrid if width of columns are not specified, they share the width of the grid equally. (ie. if the width of grid is 400px and there are 4 columns, they all occupy 100px width). Is there an option to handle this in a smart way so width of the columns can be upon their content?
For example let's say there are two columns: name and info. Assuming average length of names is 60 chars, whereas average length of info is 400 chars. If the grid has a width of 460px, name column should has a width of 60px and info column should has a width of 400px.
Some kind of autowidth-to-content functionality is needed. I think there is a little possibility about that because if I dynamically resize the grid, then the width columns somehow changes and fits according to their contents.
Thanks in advance.
You could dynamically resize the grid in the `loadComplete', to make column width better fit the content. Normally I will just choose column widths that are satisfactory for each row and that tends to be good enough. There is also a method for showing an ellipsis for content that is too wide to fit within a column, although unfortunately the technique is error-prone in firefox.