Can you change Zurb Foundation's first breakpoint from 640px to 768px? (are there side effects of doing so, and is it a common and generally accepted practice?).
I think Bootstrap's first breakpoint is 768px and it does allow for more room for a "desktop" browser or tablet. 640px actually might be too cramped to fit in all things, and it goes all the way to 1024px, so it is difficult to design for anything in between.
At 640px, we get header elements pushed down the row, so items need to be styled with cramped margin space, and at 900px or so, the margin space are % values, so they get expanded but remain somewhat cramped.
If you are using the SASS version of foundation, it's easy to change the breakpoints. Take a look at the _settings.scss file, here are the few relevant lines:
$breakpoints: (
small: 0,
medium: 640px,
large: 1024px,
xlarge: 1200px,
xxlarge: 1440px,
);
$breakpoint-classes: (small medium large);
So for what you are trying to achieve, you could simply change the value of medium to 768, and if you want, also increase large. Note that the array of breakpoint classes doesn't contain xlarge and xxlarge by default - if you want these additional classes just add them into the array. You can also define your own if you need to.
Related
When I try to show the bar value in the bar chart of apache superset, y axis bar values overlap with each other.
To fix this issue, I want to rotate the y-axis values with 45 degree so that those values will look vertically and won't overlap with each other, just like it is there in x-axis values.
Do you prefer grouped or stacked bars. Using stacked bars would be a shortcut to solving this.
I don't have an easy but bad answer for you, and a more difficult but rational answer.
The bad/easy answer: You might be able to do this with CSS, at least in any given dashboard. For that, you'd want to take your Dashboard into Edit mode, and pick "Edit CSS" from the "..." menu in the top right. There, you should have access to write some clever CSS selectors (let me know if you need help) and tweak CSS properties of the SVG text element (i.e. text-anchor, transform). That said I think you're going to have a bad time with this approach, since you don't have access in CSS to the values you might need for `translate(x, y). So, that brings us to...
The better/harder answer: You could edit the plugin! One caveat is that we'll be replacing some visualizations in the near future (including the Bar Chart) with ones based on Apache ECharts. Meanwhile, you could open up a PR on the Superset-ui repo at https://github.com/apache-superset/superset-ui. The NVD3-based plugin lies in there, as do the controls, where you might be able to add additional controls for rotation.
Door #3, of course, would be to write your own visualization plugin (or help us with the ECharts refactor!) but that's another conversation entirely.
Sorry this isn't more directly helpful, but I hope it gives you more avenues to explore.
I have a header, a body, and a footer set up for an Xsl Fo page sequence. There are certain items displayed on this page in blocks with a keep-together.within-page value of 1. This works really well for the most part, but I've noticed that when stuff that will span an entire page or more absolutely has to break it will end up on a new page and then get cut (which is fine) but then the header gets drawn in the middle of this making everything look a little gross/confusing (not fine) as whatever remains is drawn onto the next page.
So I'm wondering, is there some way to suppress the header on content overflow into the next page?
Or is there some way with alternative page sequences or something to achieve what I want?
Sorry for the vagueness here, and a lack of a current working representation of what's going on. I am very new to Xsl Fo, and most of our working code is under an abstracted framework, but if I knew of the correct directives or if this was possible I'm sure I could implement them into the framework and get things working.
Edit: I have attached a picture to hopefully clarify what is going on
You could put the content that you want to hide in an fo:marker and use fo:retrieve-marker in the fo:static-content that flows into the 'region-before' region.
The trick is to put a copy of the 'real' fo:marker before each of the blocks with the keep-together and also put an empty fo:marker with the same marker-class-name as the first thing inside the block. (I don't know what your XSL-FO markup is like, but you may need to put an fo:wrapper around each block as a place to put the 'real' marker.)
If retrieve-position is first-including-carryover (see https://www.w3.org/TR/xsl11/#retrieve-position), then you should get an empty fo:marker for blocks that broke across the page boundary and get the 'real' fo:marker on other pages.
I am using a UICollectionVewCell with custom layout in which height of the different cell varies from cell to cell. I have used approach described here
https://www.raywenderlich.com/107439/uicollectionview-custom-layout-tutorial-pinterest
I have setup the cell in the storyboard and all the constraints seem to be happy with each other. When I run the code, I get cell layout exactly what I want. No problem there.
Problem is that in the log I see a NSAutoresizingMaskLayoutConstraint that seems to be in conflict with the constraints that I have put myself. The NSAutoresizingMaskLayoutConstraint is something the xcode is adding itself. This constraint is being automatically put by xcode on the CollectionViewCell's own content view (this content view is visible only in the view hierarchy and not in the document outline).
2017-02-19 21:54:28.999546 TestProject[6612:395125] [LayoutConstraints] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"",
"",
"",
"",
"",
"",
""
)
Will attempt to recover by breaking constraint
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
I see quite a few other people have similar issues but following those posts and trying all the solutions listed there has not helped me in getting rid of this error/conflict in constraints. Some of the posts that I had tried following are
Unable to simultaneously satisfy constraints, will attempt to recover by breaking constraint
How to trap on UIViewAlertForUnsatisfiableConstraints?
One of the solutions that come almost close to fixing it but not completely is to change the priority of the constraint that to 999. But this adds small empty that doesn't look good.
Any suggestions of how I can remove this NSAutoresizingMaskLayoutConstraint warning without having to change the constraints that I have manually put?
Thanks.
I realize this was a while ago, but I'm mainly posting this comment for future people seeking help.
I was having some issues recently with a UICollectionViewCell subclass with dynamic height and NSAutoresizingMaskLayoutConstraint as well, and also perused the other links you mentioned without success.
In my case I had two subviews: subview A pinned to superview.top/left/right, and then pinned bottom to subview B, which was pinned superview.left/right/bottom. I had given explicit height values to A and B (height = 50 and height = 300, that sort of thing), and in that scenario I was having the same thing as you - an auto layout error about constraints that can't simultaneously be satisfied, but the layout itself ended up fine.
In the end, I removed the height constraint of subview A and instead laid it out differently that still let it be the proper height (I had a label within it, so I pinned the label's top/bottom spacing, rather than pinning the height of A explicitly). And the console error went away while I was still able to maintain the layout I needed. So I don't know why, but it seems like for me the error occurs when there are explicit heights all the way from top to bottom of the cell. Changing it up so that one or more of the views are pinned via spacing constraints rather than height constraints seems to play more nicely.
(Bonus follow-up for anyone else desperately searching in the future: I later tried to resize subview B by changing its height constraint constant, and that again led to the console error but a proper layout. In this case, then, changing the priority of subview B's height constraint to 999 allowed the error to go away.)
I just upgraded from version 4.1 from a month or so back and suddenly my section (horozintal-nav) is being hidden on screen sizes above 768px. Prior to the upgrade it would display as a horizontal nav above 768px and as an accordion on smaller screens.
I am using compass and sass.
I have also tried cutting and pasting their example code from their documentation into the top of my page and I get the same behaviour with that as well.
The CSS that hides the control...
/* line 49, ../../../../../lib/gems/1.9.1/gems/zurb-foundation-4.3.1/scss/foundation/components/_section.scss */
[data-section='horizontal-nav']:not([data-section-resized]):not([data-section-small-style]), .section-container.horizontal-nav:not([data-section-resized]):not([data-section-small-style]) {
visibility: hidden;
}
Is anyone else having this problem?
Seems I just needed to add data-section-resized attribute to my container.
<div data-section="horizontal-nav" data-section-resized>...</div>
So simple fix, but that isn't in the zurb documentation - does anyone one know what that attribute is for?
I ran into this problem as well. The above answer didn't quite work for me because all my tabs were squashed to the top right, overlapping each other.
This thread helped me sort it out:
https://github.com/zurb/foundation/issues/3555
This isn't broken. Sizing can't be calculated correctly when elements aren't visible. If you're going to hide them and then show, you'll need to call reflow or fire the resize event to get things to calculate the correct sizes.
At least for my case, my items were being loaded AFTER Foundation was able to calculate the widths, so it always went to 0.
Hope this helps!
I am trying to create a single round (bottom right) corner on my navigation menu.
I have a ul id labeled "main-nav" and I created a li class labeled "round".
I added this li class to the Music link to get the round corners, but nothing happened.
Here is a fiddle//
http://jsfiddle.net/2qRLU/3/
You wrote .round li This will try to target list items nested inside elements with the "round" class.
You need to write li.round This targets list items that have the class "round" on them.
Note that spaces are important, it would be wrong to write li .round as this would target children of list items that have the "round" class.
http://jsfiddle.net/2qRLU/4/
If you wanted to style corners individually you can use the more specific versions:
border-top-left-radius:5px;
border-top-right-radius:10px;
border-bottom-left-radius:15px;
border-bottom-right-radius:20px;
I've styled them all here to show the different types, but in practice you probably just want to style one corner, so here's a version of your fiddle with only the bottom-right corner curved: http://jsfiddle.net/2qRLU/6/
Also, as a side note, unless you need to support older versions of the browsers, it is safe enough to just write border-radius without all the vendor prefixes. Browsers haven't needed vendor prefixes for border-radius for a while now.
You can test it without prefixes on your browsers here: http://jsfiddle.net/2qRLU/5/