I'm new to Semantic UI and don't see this in documentation or searching.
Due to publishing constraints I need to have a container inside a container. That parent container is responsive and perfect in terms of gutter/margins.
However I would like a child container that pushes reliably outside the parent left and right so it hits the walls in any viewport. Is this possible? There is probably an approach I'm not seeing here.
Related
How can I setup a container so when the window size is too small shows a scroll in order to see all the elements that doesn't fit in one go, but at the same time, if a child shows a floating elements it is allowed to exit the bounds of the container.
I am currently using a Material UI Card, which has some elements:
As you can see in the image, it works while using overflow: auto for the CardContent.
Unfortunately, the floating element for the Combo1 component is not allowed to be shown outside:
And if I remove the overflow and/or set it to overflow: visible, the floating element shows fine but the contents doesn't scroll anymore:
Is there any way to allow only the floating elements to be shown outside a parent with hidden overflow?
Your core issue is that A) if you have content inside an element, B) that content exceeds the element's width, and C) that element has an overflow style that hides content that content will be hidden. This is just how CSS works.
Similarly, if you don't hide your overflow, there's no way to have the browser add scroll bars to that content. So if you want scrolled content you have to have an appropriate overflow style (auto scroll-y, scroll) to get the scrolling you want.
The solution, which will feel unnatural in a React app (where you're used to keeping all your UI within your component's HTML element) is to keep any UI bits that need to be shown outside the overflow, outside of the element with the overflow style.
They can still be in the same component, they just have to be outside the main element. Then, you can use some onComponentDidMount (useEffect) code to position that UI to appear next to the scrolling UI. In other words, you can't change overflow or your DOM structure, but you can use CSS to make your UI look the way you desire with a different structure.
Something like:
const YourComponent => {
useEffect(positionUiBitsNextToMainUIUsingRefsOrSomething);
return <>
<UIBits/>
<div style={{overflow: 'auto'}}>
<MainUI/>
</div>
</>;
}
As for doing the positioning part, you'll need to use refs (useRef) to access the DOM elements of your UI, so that you can position them. Prior to React I would use jQuery UI's position function to do this sort of thing, but haven't needed to do this in React (or anywhere else) in a long time, so I don't have a better recommendation.
Whether you use a library or not though, essentially you'll want to use position: absolute styling (and some calculations on your main UI's position) to move the UI bits to where you want them.
What is the best way to achieve this effect? Scroll on any part of the document should scroll the inner container.
In this demo, all top-level components have position: fixed with hardcoded positions and widths. Seems rather inflexible.
We could have a regular (non-position: fixed) layout, listen to scroll events on the top-level container and trigger those on the inner container. That requires keeping the outer scrollbar in sync and seems error-prone.
What's the best way to think about this problem?
I think its best to stick scroll on inner container than the whole document, for example your page is long or very long it would conflict scrolling the inner container with the whole document, unless otherwise your page is fit to browser window -which doe's not need scrolling, then you can use inner scrolling.
I you are sticking for whole document scroll here is an example on jsfiddle http://jsfiddle.net/NGLN/qndjW/6/
I'm having some trouble with the current layout of my polymer site, specifically with regards to nested components and their associated scrollbars. I'll preface this by stating that by absolutely no means am I a CSS guru. I wish I was because I probably wouldn't be struggling with this as much as I am. Also feel free to jump straight to the jsbin URL as my issue may become apparent.
The situation:
I currently have a nested core-scaffold element, whose main content often requires vertical scrolling and thus it's vertical scrollbar becomes active as required. However, as it is nested, it's container(s) can also have scrollbars enabled. Ideally, I'd like a single scrollbar on the highest level element which can scroll the scaffold's content to it's full vertical extents, yet also cause the topbar to slide away as it does now when scrolling down. I've also noticed that the height of the scaffold's main content is determined by the first page that is loaded into it. Subsequent page loads with different heights does not cause the scrollbar height extents to change accordingly.
Please note that I've simply inserted an iframe loading external content into the scaffold's content section for the purpose of this jsbin demo. My actual site loads a bunch of data driven collapsible height containers within the content pages, wrapping horizontally as needed. Due to their collapsibility, their containing page therefore has a dynamic height. That height can vary from page to page as container heights within them vary.
Here is the jsbin. Whoever can remove me from this css hell will be considered my hero...
http://jsbin.com/muniqi/1/
In my initial jsbin sample code, you'll notice I have specified core-pages height as '100vh' the top level polymer element (i.e. my-app-element). The second level polymer element (i.e. my-scaffold-page-element), loads within the aforementioned core-pages. Therefore, the nested scaffold element's maximum height is 100vh. Further down the chain, when the scaffold-element's main content area's height flows past its host's height limitation, it caused a secondary 'inner' scrollbar to appear, which has a different vertical extent than the original outer scrollbar...so trying to use the outer scrollbar alone doesn't effectively scroll the inner content to its entire vertical extent, forcing you to use the inner scrollbar as well to get the job done. Ugly to say the least.
Now that I know that is the case, one way to reduce the likelihood of an inner scrollbar appearing for the nested scaffold element's main content area is to change it's parent element's core-pages height to something much greater than 100vh (400vh?). Doing so solves the problem in a roundabout way. The outer scrollbar can now be used to scroll the entire vertical extent of the nested scaffold's contents without an inner scrollbar occurring.
In the new jsbin example (below), you can witness the 'fix', which also happens to remove the reliance on core-scaffold, instead preferring to utilize its individual components in a more configurable fashion.
http://jsbin.com/muniqi/3/
Ok, so I've got an issue.
Working on a simple site, which has a regular background, and an opaque main container, that also includes nested elements inside of it. Because of the nature of the site, the main container must be able to grow vertically, should the content within the body become larger. Basically, the main container must dynamically grow to fit all the floated content within.
My problem is this.
I can do this one way, where I nest elements in a main container div, and then change the opacity of that main container div to match what I need. This is easy. the problem here is that the opacity of the other elements nested within is inherited from the parent main container. I can fix that, but I do not know if it would be semantically correct for the site, or if the workarounds for alpha filters will be the best workaround.
Another option I have is creating a background img that is set at 90% opacity, and then tiled vertically. The issue here is that I HAVE to specify a height, which does not allow the main container to stretch dynamically in a vertical direction. This takes care of the semantics problem, and the opacity problem, without too much cross browser manipulation, but I don t know how to make the main container div resize itself dynamically. I'm sure there is a solution to do this with javascript or some other programming language, but that's not really my forte.
So I guess what I really want to know is this, Should I go with the first option, and use the browser manipulation for opacity, or is there a better way to be able to dynamically resize the main container div so that the image is tiled to the specific height which the content takes up?
I'm having one of those pull-my-hair-out moments that has become an all consuming obsession at work and I can't figure it out for the life of me.
I'm working on a site where I have a repeating background image (gradient of blue) and I need to put another image on top of that which goes beneath my "container" div. The large image that I'm having to put the "container" on top of has designs that appear to pop out of the sides.
The trouble that I'm having is this: when the user shrinks the window size, my buttons (that are within the container div) get all jumbled up and go one on top of another when I do this in IE and Firefox. I would like it to stay in the same spot on top of the large image in its spot despite the size of the window.
I think it has to do with absolute position, something that I'm not too familiar with, but I'm wondering if this is possible. I have also never used tables and have just used div tags to create sites. Fairly new at this - just have been designing websites for about a year now.
Help!
I am answering this without seeing an example, so bear with me.
It sounds as though the container div does not have a width assigned to it.
Since the container div doesn't have a width, it is shrinking and expanding causing the buttons to jumble up. Also, make sure that your buttons and such are positioned absolutely inside of your container div. Your container div must have position:relative; set in its style in order to absolutely position items inside of it. However, it sounds as though you have your positioning already set accordingly, it is just worth re-mentioning.