I am using v-selects inside a flexbox, and I would like the v-selects's size to depend on the flexbox settings instead of changing depending on whether a long or short item is selected.
Is there a way to make the width independent of the selected item?
Yesterday I remembered that it didn't happen when I used a v-container, so I mimicked the css of a v-container but with a few changes to apply a different style.
Essentially, if the v-select has rather low width, you can't get around setting the width of the v-select manually if you want it to stay a certain size, which in the end is what v-col is effectively doing.
I wanted it to change depending on the parent's width so I used a percentage and subtracted the total flexbox gap (20px) divided by the number of items (2) in the parent, like this:
.v-select-class {
width: calc(50% - 10px);
}
Hope this helps someone in the future.
Related
I am trying to build a scene in my 2D game which has a panel whose elements are arranged as in this image:
The ScrollRect should dynamically add rows after users provide values to the InputField, select an option from the Dropdown, and then click the Button. This all works fine, except that the viewable area of for the ScrollRect has the same vertical size as its siblings within the parent panel.
This happens because the GridLayoutGroup of the parent panel requires the child cell sizes to be specified, and if I specify a value which makes sense for the top two panels it is too short for the ScrollRect. Putting a ContentSizeFitter on the parent panel does not help (also, despite Unity warning against it, there is a ContentSizeFitter on the content of the ScrollRect since without one the newly added rows will not appear when scrolling).
So my question is:
what do I need to do to allow the vertical sizing of the children of the top level panel to be based on their sizes, when one child's vertical size will change dynamically?
Thanks!
For grid layout you cannot control the cell sizes dynamically . Instead you can use horizantal / vertical layout groups where you can find an option control child size . And as mentioned in above ans add Layout element to child component and adjust the sizes
Both #Programmer and #Salma572 answers are true. If you want that size to be a fixed number or pixels, use a LayoutElement. However, It doesn't seem you can use a scale (in percent) or anything else dynamic.
It's a shame but you'll probably need to write a script.
It is possible. Attach Layout Element component to each child GameObject. You can then dynamically change the size of each child GameObject by modifying the Layout Element's Preferred Width and Height variable.
i have a function where i manually set the width of a jqgrid column. If I after this want to use the resize handle, it adds or substracts relative from the original width size. So it doesn't see my new width to take as a base. I have tried putting the width and withOrg in the colModel without success.
I have a click handler inwhich i resize a column to a certain width on click. i set the width of the th trought JS. After this i would like to be able to use the .ui-jqgrid-resize element for resizing the column.
a short version of my code, say the th is 200px wide:
$('th').dblclick(function(){
$(this).width('100px');
});
after the user doubleclicked, and the th went smaller in size to 100px, the user uses the resize handle to widen the th 10px. The expected result is a th of 110px wide, but the thjumps to 210px wide. It adds the 10px the user wanted to add to the original state, not the state i have set with the doubleclick.
I would recommend you to use setColWidth method, from the plugin which I wrote before (see the answer), to change the width of the grid column. You can download the current version of the plugin from github.
If you trying to set the width of columns based on the width of the content of the column then I would recommend you to take a look at the demo created for the answer and read the answer too. I don't see the suggested code as final solution, but the demos shows my view on the problem and the ways to implement "autowidth" functionality.
The CSS2.1 spec mandates that overflow other than visible establish a new "block formatting context". This strikes me as odd, that a property whose obvious purpose is to hide overflow without affecting layout, actually does affect layout in a major way.
It seems like overflow values other than visible combine two completely unrelated features: whether a BFC is created and whether the overflow is hidden. It’s not like "overflow:hidden" is completely meaningless without a BFC, because floats historically can overflow their parent element, hiding the overflow without changing the layout seems sensible.
What are the reasons behind this decision, assuming they are known? Have the people who worked on the spec described why this was decided to be the case?
I asked about this on the mailing list on your behalf; the thread can be found here. In summary, this has to do with scrolling content for the most part:
Fundamentally, because if the spec didn't say this, then having floats intersect with something that's scrollable would require the browser to rewrap (around intruding floats) the contents of the scrollable element every time it scrolls. This is technically what
CSS 2.0 required, but it was never implemented, and it would have been a huge problem for speed of scrolling.
-David
Most likely, it refers to scrollable content in a box that may occur outside of the float's parent but would intersect with the float. I don't think this is related to rewrapping content around a float within a scrollable container, as that already happens naturally, plus the float would clip into the container and scroll along with the rest of its content anyway.
Finally this makes sense to me. In fact, I'm going to provide an example here so hopefully it makes sense to you and anyone else who may be wondering. Consider a scenario involving two boxes with the same fixed height and overflow: visible (the default), of which the first contains a float that stretches beyond its parent's height:
<div>
<p>...</p>
</div>
<div>
<p>...</p>
<p>...</p>
</div>
/* Presentational properties omitted */
div {
height: 80px;
}
div:first-child:before {
float: left;
height: 100px;
margin: 10px;
content: 'Float';
}
Notice the similarity to one of the examples given in section 9.5. The second box here is simply shown to have overflowing content for the purposes of this answer.
This is fine since the content will never be scrolled, but when overflow is set to something other than visible, that causes the content to not only be clipped by the bounds of the box, but also to become scrollable. If the second box has overflow: auto, this is what it would look like had a browser implemented the original CSS2 spec:
Because of the float, attempting to scroll the content would cause the browser to have to rewrap it so it doesn't become obscured by the float (and what should happen to the part that scrolls out of the top edge?). It would probably look something like this when scrolled to the bottom:
The catch here is that the browser has to rewrap the content every time it repaints it during scrolling. For browsers that are capable of pixel-based smooth scrolling — which is to say, all of them — I can see why it would be a performance disaster! (And a user experience one, too.)
But that's for when the user can scroll the content, right? This would make sense for overflow: auto and overflow: scroll, but what about overflow: hidden?
Well, a common misconception is that a container with overflow: hidden simply hides content by clipping and cannot be scrolled. This is not completely true:
While scrolling UI is not provided, the content is still scrollable programmatically, and a number of pages perform just such scrolling (e.g. by setting scrollTop on the relevant element).
-Boris
Indeed, this is what it'd look like if the second box was set to overflow: hidden and then scrolled to the bottom with the following JavaScript:
var div = document.getElementsByTagName('div')[1];
div.scrollTop = div.scrollHeight;
Again, notice that the content would have to be rewrapped to avoid being obscured by the float.
Even though this wouldn't be as painful for performance as had scrolling UI been available, my best guess is that they made boxes with any overflow value other than visible generate a new BFC mainly for the sake of consistency.
And so, this change was brought about in CSS2.1, documented here. Now if you apply an overflow value other than visible only to the second box, what a browser does is push the entire box aside to make way for the float, because the box now creates a new block formatting context that encloses its contents, instead of flowing around the float. This particular behavior is specified in the following paragraph:
The border box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap the margin box of any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. They may even make the border box of said element narrower than defined by section 10.3.3. CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower.
Here's what it looks like with overflow: auto for example:
Note that there is no clearance; if the second box had clear: left or clear: both it would be pushed down, not to the side, regardless of whether it established its own BFC.
If you apply overflow: auto to the first box instead, the float is clipped into its containing box with the rest of the content due to its fixed height, which is set to 80px in the example code given above:
If you revert the first box to height: auto (the default value), either by overriding or removing the height: 80px declaration from above, it then stretches to the height of the float:
This happens to be new in CSS2.1 as well, in that an element with height: auto that generates a new block formatting context (i.e. a block formatting context root) will stretch vertically to the height of its floats, and not just enough to contain its in-flow content unlike a regular box. The changes are documented here and here. The change leading to the side-effect of shrinking the box so that it does not intersect the float is documented here.
In both of these cases, no matter what you do to the second box, it will never be affected by the float because it has been restricted by the bounds of its container.
I know this will be a speculative answer, however after reading the specifications a few times here is my view on this:
What section 9.4.1 is talking about is any block element that does not fully contain or does not fill the containment space. For example when you float an element it is no longer filling 100% of the parent, like in-flow elements do. Inline blocks, table cells, and table captions are also elements that you can affect height and width but that are not intrinsically 100% of the parent (yes table>tr>td is one that would fill 100% of it's parent but it is designed to allow for multiple td's so the td doesn't count as it will automatically shrink to accommodate additional td's) this also applies to any overflow other than visible because it breaks the containment of the block element.
So if I am reading this correctly the way it works is the 9.4.1 section is referring to block elements that break the default containment rules of the block elements as specified by section 9.2.1
I want slickgrid to autosize the columns based on the widest content or header text - whichever is wider. In simpler terms, I want it to simulate the default behavior of regular HTML tables when it comes to column sizing. How can I do it in slickgrid?
When constructing your options, you can use forceFitColumns: true
var options = {
enableCellNavigation: true,
forceFitColumns: true
};
This will make the columns fill the entire width of your grid div.
The OP is looking for columns to grow to match their content. grid.autosizeColumns() grows the cells to fit the parent container, which is not the same thing.
I have added this feature, and it is about as manual as you might imagine. You loop through the displayed cells and measure each one, saving the widest cell and using that width to set the width of your column. SlickGrid gives you good access to the cells in the viewport, so that works nicely.
The measurement algorithm is your big decision. You may put the content off screen and measure it, as #jay suggests. This works, but it is the slowest method, as it requires a repaint to insert, and a repaint when you remove. There may be ways to optimize. The solution I went with is to measure the width of every letter in the alphabet, as well as other typographic characters we come across, and sum them to generate a width. Yes, this sounds absurd. It has many constraints: The font size must be the same, it doesn't support images, there can't be any line returns, and more. If you can live with the constraints though, you can calculate sizes for a huge grid viewport in <5ms, because the character widths are only measured once.
After you get the sizes of the columns, you assign them to your columns using grid.setColumns().
Slickgrid will not support column auto size based on data.You need to write a plugin or fork the slickgrid core to modify.
Here is the link I have created a plugin to handle slickgrid auto size
https://github.com/naresh-n/slickgrid-column-data-autosize
I added this after the grid is drawn and it works fine.
$(window).resize(function() {
var cols = grid.getColumns();
grid.setColumns(cols);
})
You should be able to call the autosizeColumns() method of the grid object.
grid.autosizeColumns();
Make this simple adjustment to Naresh's https://github.com/naresh-n/slickgrid-column-data-autosize, on the init function:
Add $container.ready(resizeAllColumns); to the init function.
This ensures the columns autoresize on initial load
Insert the text into an off-screen element and retrieve the width of the element. This is what excanvas does to measure text. Use this to set the width of the column since it's expecting a pixel value.
I'm having hard time with tables and column widths.
Update: I'm using XHTML Strict 1.0.
The page is: http://www.pro-turk.net/try
The first problem I have is, I have a column with a fixed width of 100px and 4px padding, but it disobeys my padding depending on the value. The column width (as the distance between two borders according to W3C Box Model) is 156 px even if padding is 0 or 4. Only the position of the text changes.
According to W3C Box Model ( available at www.pro-turk.net/box_model.png ), borders and paddings aren't included in WIDTH attribute, so why does it render wrongly ?
The second problem is, when you look the page I gave with IE8, the first cell in the second row has 150px fixed width, but ie shows it about 50% of the total table width regardless of what i say.
You're using the default auto table-layout mode. That lets the browser decide fairly arbitrarily how much space to assign to each column, usually depending on the amount of actual content in the cells. In this mode, width is little more than advisory.
If you want the browser to take your column widths seriously you should set table-layout: fixed on the <table> element, and either include <col/> elements with explicit widths, or set widths on the cells in the first row, for the columns you want to be fixed-width. (The other columns will share the remain width equally.) fixed table layout also allows the browser to render faster.
For your page you might be better off with CSS positioning. Certainly for the internal table that seems to exist only to float-left the image. Nested tables are to be avoided.