Properly sizing and aligning the flex item(s) on the last row - html

Let's say I have a list of users, and each user has some number attached to it. Each user is listed like so:
<span>Niet ⇒ 2</span>
They are all styled with:
.userlist>span {
display: inline-block;
padding: 2px 6px;
border: 1px solid currentColor;
}
Here's an example of it in action:
Okay, this looks all right, the list of users can get quite long so compact-ness is important here. My issue is that that right edge is horribly inconsistent, so I'm wondering if there's any way to improve that.
My first thought was, of course, just setting a fixed width on the spans. However username widths aren't exactly predictable. You can have someone called iiiii and someone called WWWWW but since this isn't a monospace font you get "iiiii" and "WWWWW", very clearly different widths there. So the "max width" would basically be the widest allowed character, which is W, multiplied by the max username length. Let's try that...
Ew. I might as well use a <ul> if that's the result I'm going to get. The next thought was maybe something involving display:table to have the widths be consistent across columns, while still remaining dynamic and - assuming most people have sensible usernames (*cough*... oh hey, so that's how you escape Markdown... huh...) - but it does tend to end up with a lot empty space still.
So my current idea is some kind of justify-alignment. That works quite well for text, right? But alas, text-align: justify does precisely bugger all in this case, possibly because there are no spaces between the elements to be justified.
My final attempt was using flexbox, something I'm already using to good effect in the site's new design. Let's see how it looks with display: flex; flex-wrap: wrap; on the container, and flex: 1 0 auto; on the elements...
Huh, that doesn't look too bad. Not too bad at al-
... Hm. So close. What I'd really like is for the last line of elements to not get flex stretched all the way across. It's okay when there's three or four on the last line, but two looks a bit silly and just one fills the whole width and looks ridiculous.
So I guess this whole little adventure boils down to one simple question:
How can I achieve justify-align-like behaviour, in which elements are spaced to use the full width of the container, except on the last line where they should use their natural width?
To complete this little story, thanks to #Michael_B's answer, here's how I've implemented the solution:
.userlist:after {
content: '';
flex: 10 0 auto;
}
And the result:
Beautiful.

Using flexbox, create 3 or 4 "phantom" items that always occupy the last slots.
So, for instance, user #82 is currently your last entry.
Make fake users 83, 84, 85 with visibility: hidden.
Alternatively, try just one phantom item at the end with visibility: hidden and flex-grow: 10. Target it with :last-child or :last-of-type pseudo-class.

Related

Html table gets distorted only on one page

I have a website with a table and for some reason that I cannot find for the love of god, the last item of the table row is wider than previous items. Here is a link to see what I mean. However, it only does that on some pages. Most pages are completely fine. Here is an example of what its supposed to look like this.
The code is the same on every page and I do not quite understand why it does that because the 'inspect element' gives me that the width of the table element is the same. However, it clearly is not. Please check it out and let me know where to start looking.
The below content in one of the bottom rows is causing the issue -
СК-201(М),231(М),251(М),351(М),501(М)
Its in the 5th row from bottom.
Add space after comma to solve the issue.
some time data come from data store and you cant hanld this with adding space in the table when long words comes in then td width should extend its simple to solve this issue in css add this line for you td css
word-break: break-all;
your css will be look like
.catalog_items_blocks td {
padding: 10px 0 38px 41px;
width: 179px;
word-break: break-all;
}
now words breaks when cross the td width
thanks

What is the best way to "wrap text" on a web page

I have a HTML page where I am listing pictures of people and their names. If there name is longer than 20 characters I want it to show up on 2 lines instead of one to avoid a lot of empty horizontal space for the people below them
What is the simplest way to make sure to do this. To be clear, I don't want to break up words in name but rather just break up the words on two lines.
You can try setting the width of the container that holds the name to be smaller or alternatively add some padding. For example:
HTML
<div class="name">This is my name</div>
CSS
.name { width: 50px; /* or whatever value works for you */ }
You would rather need to decide what is the maximum width that the name can take. Then,
.boxed-name { width: ?? px;text-align: ??; }
The main issue with a character counting solution is that it doesn't consider the font family neither the font size. This can lead to serious differences. Also, mmmmmmmmmmmmmmmmmmmm can be longer than iiiiiiiiiiiiiiiiiiii if the current font is not fixed.

Fixing html and css

First.. How do i fix this:
http://jsfiddle.net/kLjcq/
I am seeing this properly formatted on my browser..!
http://picpaste.com/pics/Screenshot_from_2013-02-07_13_31_20-ViIvXLQf.1360273538.png
http://picpaste.com/pics/Screenshot_from_2013-02-07_13_37_15-GBjeEsL8.1360273595.png
But on the fiddel it messes things up.. :( What happened? HOw do i fix this?
Second is.. if i have long string... it shoots over that light gray border of the heading
"Reading from xml..." thingy
What I am looking for is that the maxiumum spread of this text goes upto that border.. and after that.. it breaks to a next line.. so that text is enclosed properly..
In div.content
div.content {
background-color: #add8e6;
display:inline-block;
margin-top: 20px;
border-radius: 10px;
position: relative;
top:-5px;
}
I tried to add limit and stuff.. but it limits the blue box to a pixel value
but instead i want text (and blue box) to limit upto certain limit after which it
breaks to a new line...
any clues.
Thanks
You're absolutely positioning the .checksheet class. This removes it from the document flow. Other elements like your .content-class don't care for it.
I don't know why you use position: absolute; in this context, but it's producing your mistake.
Your fiddle is breaking because you're using absolute positioning. When the screen is narrow, your elements in the checklist are wrapping around, but the elements that follow are positioned in a way that assumes the preceding element is only 1 line instead of 2.
Without the actual markup relating to your second question, we can only guess at what the actual problem is. However, since you're using pre in the sample provided, the culprit is most likely there. What you need is to add a property like this:
white-space: pre-wrap
Without this property, the pre tag generally does not allow elements to word-wrap, which will cause it to take up as much horizontal space as possible to display all of the text.

Centering a div popup in the center of screen

I have searched a lot for centering a div, both horizontally and vertically, this is the method given everywhere:
div {
position:fixed;
top:50%;
left:50%;
margin-left:(div width/2)
margin-top: (div height/2)
}
I just found a new solution to centering a div, both horizontally and vertically, by wrapping it inside a table. I've tested it in ie7 and above, plus other browsers.
Here is an example : http://jsbin.com/ocenok/2/
I was wondering that the first method is found everywhere on the internet, SO, etc. and requires beforehand knowledge of width and height, or is usually calculated via Javascript.
The table approach seems flawless, and requires neither javascript, nor fixed height/width.
Are there any drawbacks to the table approach ?
(I do not know the height/width of the div that I want to center.)
Update (To make my question clearer) :
I myself hate using tables for non-tabular/layout data.
I know that what I want can easily be achieved using Javascript.
I figured I can achieve this using display:table, killing IE7 support.
But what I'm trying to understand is, that when I can achieve this using a single <table> element, what are the drawbacks, if any.
Checking Answers here and on similar questions, no one has recommended this method, even though it uses all valid HTML elements and syntax and rules.
If everyone is recommending to use javascript to handle presentation, even though it is easily possible using CSS, it must have some drawbacks.
Code :
<table>
<tr>
<td>
<div>This is div that needs to be centered.</div>
</td>
</tr>
</table>
and then apply the following CSS
table {
width:100%;
height:100%;
position:fixed;
top:0;
left:0;
}
table td {
width : 100%;
text-align: center;
}
div {
width:100px;
height:100px;
background:pink;
margin: 0 auto;
}
see the below function and change as per your needs
function positionLightboxImage() {
var top = ($(window).height() - $('#lightbox').height()) / 2;
var left = ($(window).width() - $('#lightbox').width()) / 2;
console.log("The calculated position is:");
console.log(top,left);
$('#lightbox')
.css({
'top': top + $(document).scrollTop(),
'left': left
})
.fadeIn();
console.log('A jQuery selection:');
console.log($('#lightbox'));
}
Updated answer HTML and CSS:
HTML:
<div id="outer"><div id="inner"></div></div>
CSS:
#outer {
position: absolute;
top: 50%;
left: 0px;
width: 100%;
height: 1px;
overflow: visible;
background:red;
}
#inner {
width: 300px;
height: 200px;
margin-left: -150px; /*** width / 2 ***/
position: absolute;
top: -100px; /*** height / 2 ***/
left: 50%;
background:#ccc;
}
Even more updated using jquery and always remain center when you resize the window too : http://jsfiddle.net/3aZZW/3/
Demo: http://jsfiddle.net/3aZZW/3/embedded/result/
There are different reasons why you should not use tables. Some which have already been discussed here. I understand that you are only using one row and you will hopefully try to keep your promise to not add any rows but if you come to break that promise, some of the reasons below will show a lot more significance, like the rendering speed and the screen reader issue. That's exactly why they call somethings standard and some not. Standards take everything and every situation into account.
Rendering speed issue:
One of the biggest drawbacks of tables is the way they are rendered by browsers. The inside of the table must be loaded before the position and size of the table can be exactly determined. This may cause problems if you are going to have a lot of information in the table.
Validness and standards:
Using tables for non-tabular data means you are writing invalid X/HTML. Which may be fine for some. But I don't recommend. See here
SEO:
I didn't know this before I did a search on some other less heard issues with using tables.
Search engines love valid code, so by not using tables it helps with
Search Engine Optimization (SEO).
See here for more info on this
Problems for screen readers and Braille displays:
Tables can't be used easily in screen readers. Check this article.
If you must use a table for layout, remember that screen readers and
Braille displays read tables row-by-row across the columns. The TAB
order also goes through the table in this way. So make sure that your
table structure makes sense when reading from left to right,
row-by-row.
On the + side:
I hate to admit that if you honestly use just that one table with one row and one column and with a very small amount of data inside (which I would call a limitation) then the page would probably render faster than the time you use Javascript but the other issues remain.
Tables are only meant to be used for tabular data - not for layout purposes.
Using tables for your problem provides a quick and easy solution for you but it doesn't mean it's the best, or correct method.
Just because something takes a little bit more thought and effort doesn't mean it should be avoided.
Use tables for this at your peril - your immortal soul may pay a heavy psychic toll at some future date for your actions today :p
According to StatCounter, as of November 2012, IE7 accounts for only 0.87% of the usage share of desktop browsers. It's not clear how accurate that measure is; some countries are probably disproportionately weighted and the sample-set almost certainly doesn't exactly match your user demographics, whatever they are. But, how much would you really lose by leaving IE7 behind? Might as well go with display: table;
On the other hand, it drives me nuts that display: table; is necessary. This is the closest I can get to a workable alternative:
HTML
<div id="pg-centerer">
<div id="shifter">
<div id="item">content</div>
</div>
</div>
CSS
#pg-centerer {
position: absolute;
left: 50%;
top: 50%;
}
#shifter {
position: relative;
height: 40px; /** Must set the height here. **/
left: -50%;
}
#item {
position: relative;
top: -50%;
}
So far, I haven't figured out how to avoid setting the height of the div#shifter element. Here's a working demo. I've tested this on Mac 10.8.1 FF 18, Safari 6.0, Chrome 25.0.1362.0 canary, and iOS Safari 6.0.1.
There is not much of a problem till you have small data inside table. Tables are somewhat heavy for browsers and with more data coming in, they make your web page response slower in comparison.
The example you have shown is only for an example but in real world you will have data inside it. If its going to be large try choosing a different method. may be the flexbox model or box model that is going to be supported in all modern browsers very soon. See an example here. http://www.kirupa.com/html5/centering_vertically_horizontally.htm
If the data inside is going to be small, feel free to user your method.
Directing my words to the geek inside who care not about standards, or multi-channeling content served... there is really just one technical problem with tables that I can think of, if you have large content inside that cell, the browser will wait for all content to load to be able to calculate the width and height of the cell before rendering... so if that content is really large and has large images, it will not render gradually... and making it a fixed table, well, the trick above won't work.
I depends on what you're trying to achieve. If it's just one page with one thing centered, then its great.
But I see you have set the table position: fixed. Which means it will scroll with you and go on top of content below. The other thing is that, if that table really fills up, you wont be able to see whats at the bottom of that table, since the position is set to fixed.
It's a great solution to center a small piece of text, image or information.
But its a bad thing to use within a page with a lot of other content or a lot of content within the table.
Side note: Using javascript to achieve something simple like that, is stupid. It can be done without javascript using CSS only. What if you use javascript to center something, and a client without javascript visits? Lets not destroy the web by using javascript/jquery for all the simple things ;)
http://phrogz.net/css/WhyTablesAreBadForLayout.html
Basically, it's slightly longer load times (JavaScript is slower), bad for screen readers (test it with one like JAWS), and hard to redesign (really only hard if you happen to forget why the heck you put a table there, so make sure to leave yourself a comment :). What would be really nice (I'm talking to you, W3C!) is something like box-align: x y;. Then you could also do things like align: center center or align: center bottom;.

Why doesn't IE display this requested background image?

Here's an odd rendering difference between IE and other browsers.
Internet Explorer 8
Firefox 3.5
Chrome 5
See the difference? That vertical line suddenly stops in IE8. That's because IE8 refuses to display a certain background image. Here's a relevant snippet of CSS code:
td#leftbar {
background: url(img/leftbar.gif) repeat-y right top;
width: 100px;
}
You can get additional information by viewing the website on your own computer here: http://labs.pieterdedecker.be/vspwpg/
The problem is not leftbar: It is the leftbartop table cell stretching all the way down to the bottom. That is because leftbartop is in the same table row as the content.
In fact, I think IE is the only browser doing this correctly: All elements in the tr get forced to the same height. IE is ignoring the columns' rowspan properties for some reason. Why, I do not know.
The first thing that comes to mind in terms of a solution - unless somebody comes up with an explanation for this behviour - is having a separate table on the left-hand side with the first (leftbartop) and third rows (leftbarbottom) having a fixed height.
Oh, and using tables for layout is no longer socially acceptable. Just as a side note :)
I'll second Pekka's comment about avoiding tables for layouts, but since proposing serious structural changes would be a bit extreme, the following CSS seem to work well enough to fix the problem:
TABLE#body {
background:url(img/leftbar.gif) repeat-y 94px top;
border-collapse:collapse;
width:100%;
}
TD#leftbar {
width:100px;
}
TD#leftbarbottom {
background:#FFFFFF url(img/leftbarbottom.gif) no-repeat right top;
height:100px;
}
As far as why there is a difference between IE and Firefox/Chrome, the only potentially relevant piece of information that I could find right now was the CSS 2.1 section on table height, which states:
CSS 2.1 does not specify how cells
that span more than one row affect row
height calculations except that the
sum of the row heights involved must
be great enough to encompass the cell
spanning the rows.
So, not only is IE's behaviour bizarre, there's doesn't seem to be a clear cut explanation of what should happen. In IE's case, space required by the multi-row cells appears to be divided up using some sort of relative percentages related to the minimum height of each included row.
To illustrate this, you can cause #leftbar to take up all the space it's leaving empty now by using the following rules:
TD#leftbartop {
height:1px;
}
TD#leftbar {
height:150px;
}
Another interesting example is a 1/3, 2/3 split:
TD#leftbartop {
height:33px;
}
TD#leftbar {
height:66px;
}
Note that if you set the height to something unreasonably small (like 1px in the earlier example), it calculates a height for that cell that is not based on the relative percentage, but something else. I'm not sure where that comes from right now, but I'll play around with the numbers and see if I can take a guess at it later on.