22 Matching Annotations
  1. Jun 2022
  2. Apr 2022
    1. Setting "img max-width:100%" is a technique employed in responsive/fluid web site design so that images re-size proportionally when the browser is re-sized. Apparently some css grid systems have started setting this style by default. More info about fluid images here: http://www.alistapart.com/articles/fluid-images/
    1. Now, our img element will render at whatever size it wants, as long as it’s narrower than its containing element. But if it happens to be wider than its container, then the max-width: 100% directive forces the image’s width to match the width of its container.
  3. Jan 2022
    1. When you give an element a width of 100% in CSS, you’re basically saying “Make this element’s content area exactly equal to the explicit width of its parent — but only if its parent has an explicit width.” So, if you have a parent container that’s 400px wide, a child element given a width of 100% will also be 400px wide, and will still be subject to margins, paddings, and borders — on top of the 100% width setting.
  4. Aug 2021
    1. The most likely cause of this problem is having set the height of an element to be 100% of the page somewhere in your CSS. This is normally on the html or body elements, but it could be on any element in the page. This can sometimes be got around by using the taggedElement height calculation method and added a data-iframe-height attribute to the element that you want to define the bottom position of the page. You may find it useful to use position: relative on this element to define a bottom margin or allow space for a floating footer.
  5. Jan 2021
    1. Situation: you have a single line of text in a flex child element. You don’t want that text to wrap, you want it truncated with ellipsis (or fall back to just hiding the overflow). But the worst happens. The unthinkable! The layout breaks and forces the entire flex parent element too wide. Flexbox is supposed to be helping make layout easier!
    1. Great, I can use vw to scale text so it doesn't look puny on a desktop! Perfect... Oh. Huh, now the text is too small to read when viewed on a phone. Okay, well I can just use "max(x,y)" to make sure it doesn't get shrunk beyond a minimum size. Perfect... Oh. Hmm. Looks like "max" isn't supported properly by Chrome. Okay, well guess I'll just use "px" again.
    1. auto As a maximum, identical to max-content. As a minimum it represents the largest minimum size (as specified by min-width/min-height) of the grid items occupying the grid track.

      And I'm guessing that when you use auto as a value (not inside of a minmax), that it is equivalent to minmax(min-content, max-content)? Wish I could see that confirmed somewhere...

    1. fixed: With this value, the table’s layout ignores the content and instead uses the table’s width, any specified width of columns, and border and cell spacing values. The column values used are based on widths defined on columns or cells for the first row of the table
    1. It is also very likely that the contents of the table might change the structure or dimensions of the table. For example, long words residing in the table cells can cause the cell width to increases. If you fix that problem, it might happen that the long words cross the cell boundaries.
    1. The only difference is that in this case “auto” will not work, but instead “height: 100%” is required.
    2. Blocks Don’t Need 100% Width When we understand the difference between block-level elements and inline elements, we’ll know that a block element (such as a <div>, <p>, or <ul>, to name a few) will, by default expand to fit the width of its containing, or parent, element (minus any margins it has or padding its parent has).
    3. It seems like this should be one of the easiest things to understand in CSS. If you want a block-level element to fill any remaining space inside of its parent, then it’s simple — just add width: 100% in your CSS declaration for that element, and your problem is solved. Not so fast. It’s not quite that easy. I’m sure CSS developers of all skill levels have attempted something similar to what I’ve just described, with bizarre results ultimately leading to head scratching and shruggingly resorting to experimenting with absolute widths until we find just the right fit. This is just one of those things in CSS that seems easy to understand (and really, it should be), but it’s sometimes not — because of the way that percentages work in CSS.
    1. min-width: 0;

      Wouldn't expect the solution to "width grows too wide" to be to assign a (seemingly meaningless, since how could it be less than 0) a minimum width of 0.

      I would have expected to solve this by applying a max-width to the problem element or one of its ancestors.

    2. The explanation here is that the minimum size of an fr unit is auto. Grid then looks at the min-content size of the item. If the item has a size (you’ve given it a width) or has something in it with a size such as an image, the min-content size might be much bigger than the share of available space you think 1fr will give you. It’s easy to think of 1fr as being “one part of the space in the grid container” when it is really one part of the space left over. If there is space to grow then the tracks grow from that min-content size assigning space. Using minmax, as you have pointed out, is the best thing to do if you want to forcibly have equal width tracks, as that says “I want this track to have a min-content size of 0”, you could potentially in that situation end up with overflows as you lose the squishiness.
    3. And since auto is entirely based on content, we can say it is “indefinitely” sized, its dimensions flex. If we were to put an explicit width on the column, like 50% or 400px, then we would say it is “definitely” sized.