How can you enforce the minimum width for a TD that can optionally contain an image? I ask this because I'm using a Javascript chess widget but when there are no pieces in any of the squares of a particular column, regardless of the width style of the td's being set to 36px, this column renders much narrower than those that have at least one row that contains the image of a chess piece.
Note that all the style is being set directly on each td cell. I read somewhere that a possible solution would be to instead create a div inside the td and set the width on that. Am hoping to avoid that as it might require significant modification to the underlying Javascript library. I've tried specifying !important along with the width but it had no effect.
Using firebug I can modify the width attribute but it seems the numbers are incorrect. For instance I can decrease the width all the way to 0 and it still appears the same. Or I can set the width to more than 36 and it appears to grow by width-36, but if for instance I set both the height and width of one of these narrow cells to the same number, lets say 60px, the height of what gets displayed is greater than the width and it appears as a rectangle not a square.
Furthermore not only can the td optionally contain an image, but each square specifies a background image too. So I am at a loss :( Thanks in advance
When I alter the CSS in your file using Firebug or the JS inspector in Chrome, setting the min-width property instead of the width property does the trick. Might want to try that? Not sure how IE will like that, though.
BTW: Why not use classes to do the CSS? It's kinda horrible to debug, this way.
By default tables will auto-size their columns.
If you set the table style to include:
table-layout: fixed;
then you'll have much better control of it via css and attributes.
You can use the td tags width attribute or you could use css and set the width.
Related
I'm trying to write a CSS class that allows me to sit form elements (mixed button and text inputs) in a line so that they abut. I'm using display:table on a parent, and wrapping each element in a container with display:table-cell, and it works fine except for one bug that I can't figure out a way around.
So for example, parent is control-group, the element wrappers are control-group-item, and the elements themselves are control-group-input.
.control-group
.control-group-item
.control-group-input{type: "text"}
.control-group-item
.control-group-input{type: "submit"}
CSS of this (I've normalized font size/line height/padding/browser weirdness and all form elements are inline-blocked etc.):
.control-group {
display: table;
.control-group-item {
display:table-cell;
}
gives this, which is OK:
However, I ideally need it to fill a grid column of undetermined size, rather than the browser deciding how big my elements should be. If apply width:100% on .control-group, this happens:
The orange is a background colour applied to the table cell control-group-item. The issue seems to be with the 'submit' input: the submit stays the size it should be but browsers universally add extra space next to it within the table cell. So if I apply width:100% to each .control-group-input, I get this:
Which is OK, but stretches the ‘submit’ button. I can live with that, but is there any way to get it like the second image (but without the random space) using my current approach, or should I sack that off & try something different?
Edit I do not know the sizes of the inputs in advance: I can't set a width on them, which effectively rules out most inline block/float methods. I ideally need IE 8/9 support, which is why display:table was tried.
Edit 2: here are versions on Codepen: http://codepen.io/DanielCouper/pen/knDmC
After rewriting the code there, I realise my question is: how is the width of the table cells being calculated? It's specifically the cell with the submit button that has the extra space. The extra space seems random.
Here's a working version in codepen: http://codepen.io/mkleene/pen/ldqDH
The summary is that you need to remove the width: 100% on the submit button and then give the second table cell element width: 100%. You also need to make the textbox take up its entire parent with a 100% width.
You also need to make sure that the table element is using an auto table layout.
nm, spoke too soon. Thought I had solved it, hadn't, was getting effects from some other CSS.
I am trying to create an input mechanism using the flex box model. I know it's not supported by all browsers, but that doesn't matter in this case. It really only needs to work on web-kit browsers.
I am trying to build a nice two column layout without needing to use specific widths. I have the flex property set to one on both the label and the input. However, as you can see, when the label element gets long, it messes up the width of the input that is next to it.
I want both label and input to be the same width down the column, but I want them to grow and shrink as the size of the window/device changes.
Is there a way to do this without having to set a width on either of the elements?
Update
I can set a max-width on the label elements to 5% and I basically get the desired effect. However, I'm still wondering if there is a way to do this without setting any width and using purely the flex box?
Here is a working jsFiddle.
The example you provided doesn't have columns at all, just the appearance that there are columns. Without actual columns you will have to set widths to make these 3 unreleated blocks look they are joined in some way.
You should be using the new CSS3 Flexible Box syntax, which is now 'flex' rather than 'box'. See the spec: http://www.w3.org/TR/css3-flexbox/ With this you can set the elements to have a <grow> <shrink> <default width> of 1 1 50%, so they will grow and shrink at the same rate and will each take up 50% of available width (you can adjust this or make it 60/40 or whatever).
Example JSFiddle: http://jsfiddle.net/XTa98/4/
Otherwise, if you want actual columns so that you don't have to set widths, you need to wrap all of the labels in their own "column" div and all of the inputs in their own "column" div.
JSFiddle: http://jsfiddle.net/XTa98/5/
This has actual columns and no widths set, but it does not degrade gracefully anymore since the elements are not in their own rows. To alleviate this you could always provide text-overflow: ellipses to truncate the text.
In any case, you have a trade-off. If you want the appearance of columns without actually using columns, you will need to set some type of width. Otherwise, you can use real columns but the elements are no longer joined as rows and you will need to account for the overflow when shrinking the browser width.
You don't have to wrap the elements in column divs to avoid setting widths. Just set each label and input to flex:1, and you'll get them dividing up the width equally. However, this is effectively just the same as setting each to be 50% wide, in this case, so I'm not sure what advantage it really has.
My question says it all. If we specify in css the width and height of textarea or text type form elements and don't use rows and cols property and size attribute respectively. Does it really matter? I would like to know are there any performance degradation's in the same on using on over the other.
width and height will override the values set for any sizing attributes, be it size or col and row (See: http://jsfiddle.net/Wexcode/Bmp65/). I would highly recommend setting the dimensions using width and height, since setting the size or col and row will lead to cross-browser inconsistencies.
The performance does not depend on the width and height properties itself, but on the way you specify your element in the stylesheet. For best results, reference the textbox by ID.
For instance
#thetextbox {width:10em; height:2em}
is faster than
form fieldset:nth-child(3) input[type="text"] {width:10em; height:2em}
setting height on input text is very dangerous!
on some systems the text may not be fully visible in the Y axis
safe solution is setting line-height instead of height
in textareas there is no problem (unless you want a textarea of one single row)
it is preferred to use cols rows and size attrbutes for backward compatibility, but if your audience are users with a modern browser css will be sufficient
HTH
edit:
<input type="text" style="font-size:20px;line-height:1;height:20px;"
value="ASDASDASD">
in firefox, "zoom text only" under View > Zoom
then zoom to 150%
this may happen on older firefox users, IE6 and probably 7 users (not sure)
where zoom applies only to text
in plus some systems have a native padding inside the textbox that you can't override,
a space used for focus rings/highlight outline, and it occupy some space that is included in the css "height"
if you remove height:20px; theres no problem at all I guess,
It is okay to use specify the width and height in css instead of using cols and rows. cols and rows really aren't good if you need the textarea to fit in a certain space, so using css is better.
if you use rows and col in your design , your page dose not displays good in different browser.using Css its better.
Use CSS!
The rows, cols, and size html attributes exist purely for style purposes.
In my opinion, you should leave the styling to CSS, so that you have separation of content and style.
It's the same reason we shouldn't be using the <font> tag, <blink> tag, style attribute, align attribute, etc.
I'm facing a rather difficult issue at the moment; really appreciate your help.
I have a table with 2 columns, td1 and td2, and containing texts and both of which have fixed widths.
td1.width = 10px and td2.width = 20px
the fixed width are set at runtime one by one from the left using JQuery (as this table is nested inside another table...)
The text width may be longer than these fixed widths in which scenarios the expected behaviour is that
the fixed width of the columns should stay the same 1) if there are extra texts, the text should wrap, it should not increase or decrease the td width 2) if there are empty spaces, the cell width should not be reduced when resizing other columns or page; it should stay intact.
I have set the td.whitespace property to pre-wrap and td.word-wrap: break-word but they haven't helped.
how would these be possible using css 2.0 (not 3.0)?
Thanks,
In this case, because the widths are so small, and the text doesn't typically have words that small, it has no way to wrap them, so it extends the width of the td even with a set width!
It decreases the width of the second td because the first is using an extra width.
Also, you could have a situation where the text is so wide (a long word for example) and in that case there is no way to wrap it. Unless using javascript, IMO it is the only way.
I recommend reading this answers: HTML TD wrap text
ok, I got it resolved. My table had thead and colgroups. Althought their display attribute was hidden, IE 9.0 ignores it whereas IE 6.0 takes them into account in calculating the width of columns!
I removed them using jquery and sorted out!
$('.myTable thead, .myTable colgroup').remove();
Is it good to add min-width, max-width, min-height, max-height always in any type of layout fixed or liquid?
No.
The concept of cascading style sheets is that there are rules that dictate other rules up and down the chain (hence the inclusion of "inherit" as a property).
For example, if you use a container div, and you specify an max and min, then you would need to recalculate every time you adjust a div underneath it, for example if you wanted the header to be wider.
Conversely, if you have a container div with a fixed size, instead of making the header the same width (if you are trying to fill it), you can just specify a percentage, instead of having to do the math for every div down the cascade.
This becomes even more important the more stylesheets you include, and the more complex your pages are.
If your layout is fixed (which means you have defined width/height) then the min- /max- rules will be ignored as the width/height have precedence over those..
Of'course you might want to use min-/max- rules for other elements inside of the fixed ones. (if there is reason)..
So, you should only use them if they are required by the layout logic..
I agree with #Cryophallion. It also depends if you are expecting controlled static data, or dynamic data. I.e. if you have a DIV that holds a dynamic object such as a image, you may want to limit the size it takes on the page. This is to control the size the image takes, because you may not know the size of the image before hand.