Forum Moderators: not2easy
having problems with IE not working like everything else as usual
i have a form with some checks - with labels.
now as usual it looks fine in FF/Opera/Safari, but in IE the fact that the p is set to no wrap seems to make the label in IE shift down below its checkbox - i played a bit with the overflow, which got it lined up but, certainly dont want a scrollbar, and hidden crops so much its a no no. if anyone can explain a way to avoid this that would be incredibly helpful
many thanks
markup and css below
<table>
<tr>
<th colspan="3"><p class="q">Here is the question text Here is the question text Here is the question text Here is the question text Here is the question text </p></th>
</tr>
<tr>
<td class="l"> </td>
<td class="c">
<p class="option">
<input type="radio" name="radio1" id = "radio_1" value="1" />
<label for="radio_1">option 5555555 5555555 5555555 555555 555555</label>
</p>
<p class="option">
<input type="radio" name="radio1" id = "radio_2" value="2" />
<label for="radio_2" class="wrapit">this option has a style attached setting it to wrap, as its quite long</label>
</p>
<p class="option">
<input type="radio" name="radio1" id = "radio_3" value=3" />
<label for="radio_3">option 3 333 3333</label>
</p>
<p class="option">
<input type="radio" name="radio1" id = "radio_4" value="4" />
<label for="radio_4">option 44 444 4444444 444 4444</label>
</p>
<p class="option">
<input type="radio" name="radio1" id = "radio_5" value="5" />
<label for="radio_5">option 5555555 5555555 5555555 555555 555555</label>
</p>
</td>
<td class="r"> </td>
</tr>
</table>
the css for that lot
*{
padding:0;
margin:0;
font-family:arial;
}
body{
background-color:#e03108;
color:#fff;
}
/* TEXT FORMATTING */
p{
font-weight:bold;
clear:both;
}
p.option{
font-weight:normal;
white-space: nowrap;
text-align:left;
}
p.q{
text-align:center;
}
p.textbox{
font-weight:bold;
}
/* QUESTION FORMATTING */
label{
margin-left:18px;
display:block;
clear:none;
}
label.wrapit{
white-space:normal;
}
input{
float:left;
vertical-align:center;
margin-top:.2em;
color:#000;
}
/* TABLE FORMATTING */
table{
width:100%;
margin:20px 0px;
}
td.c{
text-align:center;
vertical-align:top;
padding:0px 10px;
}
td.l{
width:40%;
text-align:right;
}
td.r{
width:40%;
text-align:left;
}
td.c table td{
padding: 10px;
vertical-align:top;
}
I could assume the question is about the "float drop" i.e. the label drops beneath the input in IE, but I don't like assuming and I also see different things in all 3 aforementioned browsers so,
My main thought, if that is the case is that the input and label elements are both inline elements by default and you want them to display side by side, wrapped in a <p> which has nowrap set, so why use floats/display block at all?
and some random questions which may help us get to solution if inline isn't what you're after..
1. do you need this form in a table
2. do the left and right cells contain actual content (width when narrowed) or is it just a method of centering the form or applying a background.
Add a border to the table (or if via CSS add to both table and td) then add some cellspacing to the table and this will help see exactly what is(or isn't) happening :)
I tried various permutations of what you *might* be looking for, and I actually got all 3 browsers FF, Opera and IE to show 3 x different scenarios but I can't get them all to show the same one at the same time :o
why doesnt it ever do what its supposed to
FF Opera & IE are handling the degradation of the wrapper table differently, as to which one is right I'm not sure there is a "right" ;) to wit, herein lies the devil in the detail for table layout:
17.5.2 Table width algorithms: the 'table-layout' property [w3.org]CSS does not define an "optimal" layout for tables since, in many cases, what is optimal is a matter of taste. CSS does define constraints that user agents must respect when laying out a table. User agents may use any algorithm they wish to do so, and are free to prefer rendering speed over precision, except when the "fixed layout algorithm" is selected.
My emphasis.. the browsers have a choice and if you know exactly what you want you may need to help them make that choice. It's going to help us to help you find the best solution for you if we know exactly what it is you expect from the layout.
Suzy
thanks for taking the time to reply.
Let me try to expand a little..
so why use floats/display block at all?
Initially I hadn't used any floats, id stuck with the same markup and let both the input and the label just sit next to each other, as like you say they are both inline elements. However this means that when you have a long option it wraps underneath the input rather than continuing underneath where the previous line of text started.
I figured (maybe wrongly) the only way around this was to block up the label, which then needs floating to sit on the same line as the input itself.. (again please step in if I'm talking nonsense)
Would be happy to find a different solution. changing the markup is not a problem at this point. Maybe this is where the problem lies..
1. do you need this form in a table?
Well I had hoped not to tbh, but couldn't see a way around it.
basicaly i am trying to come up with a 'fluid' form design that will happily center form elements on the page, without knowing how wide the various options for the radio buttons/checkboxes etc are. It also has to retain the left alignment of these options within their group. I just put a radio group in this example but need this to work for checkboxes, and well all other form elements.
I had wanted to use centered divs but again I assumed (again maybe wrongly) that in order to center a div, you have to give it a width and then set the side margins to 'auto', but I cant specify a width.
If you underspecify the width of this centered div, it centers on the underspecified width, not the 'no wrapped' expanded one. So went down the overspecified width of the side cells and nowrap on the center cell (p within the cell) to expand the center to its biggest width automatically.
2. do the left and right cells contain actual content (width when narrowed) or is it just a method of centering the form or applying a background?
Yes, just to get it nicely in the middle.
I do seem to have it pretty much doing it, although the radios arent always sitting nicely in the center of the line they are on. but it sounds like maybe i am making things hard on myself by starting from the wrong place, maybe markup is what needs to change..?
On top of all this I am hoping to use the
unicode-bidi:bidi-override;
direction:rtl;
Settings to get all this to reverse - having played with this, by adding another stylesheet with these settings and the couple of styles that needed reversing, it seems ok.
I am hoping that this is a reliable way of doing this and im not in for having to rewrite a lot more of this additional stylesheet
I am using the strict doctype.
Many thanks again suzy
nat
thanks for detailed reply, it helps figure how much you tried and the thought process behind it. I did wonder about the wrapping of the inline elements being the reason behind the floats, and no you're not talking nonsense, and as far as I can see you logically tried what most others would have, blocking and floating :) This is the logical thing to do, however it's behaviour/interaction inside the table cell is not consistent across browsers.
I can see why you put it a table for the fluid centering without a width reason, again you're right in order to use margin: 0 auto; the container would need a width. I have a solution for you if you want to stick with this method, which to me at the minute seems to be the safest, stability wise
As you asked for more ideas, The more correct property to use for the container is likely
display: inline-block;---- a little while later
I really though I had this went to get the code that should work without you changing any source, but when I checked in IE7 and it was no longer working grrr and this time it really is weird
The solution I am going to suggest is to float as you are doing then put a negative right margin on the float say about 20px then use a margin on the label which is equal to or greater than the negative right one. This seems to get IE and Opera to force the width to include the float.
However IE stopped working on me and what had I done.. removed a background color from the input, I'd been using one to visualise grrr this could be fixed by putting background transparent on the input but see later in this post...
I did think there might be another way if you wanted to 'neaten' the source - remove the <p>,wrap the input in the label, make the label display block, and still float the input however Opera still doesn't like that one..
if using ( on the <p> )
unicode-bidi:bidi-override;
direction:rtl;the reverse logic also appears to work, eg: right float the input, negative left margin on input, positive right margin on label.
The negative margining thing appears to stabilise all Browsers that I checked in.. Opera was copying IE and FF wasn't quite centering, not that anyone would likely notice that, it was overflowing into the right cell by the width of the input+margin. this would be of bigger concern when it comes to your wider inputs
I too am using a strict doctype - but then when I looked in at it in IE6, it still didn't work there!
Solution for IE6 is to trigger hasLayout on the <p> element which then also fixes that background color oddity in IE7 so some final code for you to test out with your other inputs if you want - note: the actual margins will depend on the width of the inputs, and maybe approximating using ems would be better than pixels as this would allow the gap to resize with the inputs
have fun and do let us know if you come with another way!
CSS:
html, body{
padding:0;
margin:0;
background-color:#000;
color:#fff;
font-family: verdana, arial;
}table{
width:100%;
margin: 20px 0px;
border: 1px solid #f00; /*red */
}td.l, td.r {width:40%; border: 1px solid #0f0;}
td.c {padding: 10px; border: 1px solid #ff0;}p {margin: 5px 0; width: 100%; /* hasLayout trigger required for IE */}
/* a negative right margin on the float with a corresponding left margin on the label element
fixes the float drop in both IE and Opera and the overflow in FF, (auto layout mode) */
input{
float:left;
margin: 0 -20px 0 0;
}label{
margin: 0 0 0 20px; /* left margin = negative margin on input - increase it to make a bigger gap */
display: block;
background: #00f;
color: #fff;
white-space: nowrap;
}label.wrapit {white-space:normal;}
HTML:
<table border="1" cellspacing="5">
<tr>
<td class="l">.</td>
<td class="c">
<p>
<input type="radio" name="r1" id = "r1" />
<label for="r1">option 5555555 5555555 5555555 555555 555555</label>
</p>
<p>
<input type="radio" name="r2" id = "r2" />
<label for="r2" class="wrapit">this option has a style attached setting it to wrap, as its quite long</label>
</p>
<p>
<input type="radio" name="r3" id = "r3" />
<label for="r3">option 3 333 3333</label>
</p>
<p>
<input type="radio" name="r4" id = "r4" />
<label for="r4">option 44 444 4444444 444 4444</label>
</p>
<p>
<input type="radio" name="r5" id = "r5" />
<label for="r5">option 5555555 5555555 5555555 555555 555555</label>
</p>
</td>
<td class="r">.</td>
</tr>
</table>
thanks again for your detailed reply. that works a treat.
sounds like i was on the right track, but just as i reach the finish line, the goalposts move.. :(
the centering bit is perfect i think, and i am always needing to go for the most reliable way of doing things really, and if its tables so bit it.
but i do think that maybe my markup needs to change.
as i now need to construct markup and styles that will allow the formatting of form elements, in a side by side AND above and below (centered) layout - hopefully relying on the styling to cover the two ways of displaying.
i have had another play around with it all, and maybe this is completely impossible with a single load of html, its not too hard in radio lists/checkbox lists, to get the same markup to allow side by side and above and below (horizontal options vs vertical ones)
but then to make the vertical ones line up as they do in the previous example, AND get the inline too, i think is impossible. but feel free to prove me wrong :)
but even still, maybe i should change the markup to be
instead of
<p>
<input....../>
<label for..... </label>
</p>
[code]is it more semantically correct to do
[code]
<label for ....
<input ..... />
</label>
remebering as i have mentioned - that if possible this same markup should allow the most flexibility with allowing the styling to change the layout..
any thoughts as ever, gratefully recieved
thanks
nat
unless i were to add a span or something inside the label..
i really want the cleanest most reliably stylable markup that i can muster..
thanks again
im thinking that if i enclose the input, inside the label, then maybe im more scuppered getting the text inthe label not to wrap under the input..
Yea, I was going to suggest that way of coding, but you're right it's back to square one re: the float alignment. Adding a span would do it, does seem unnecessary but it's up to you, putting the input inside the label does allow for other ways to align so it might be worth it for maximum future design choices, the span would purely be a hook that can be used or not.
I suppose semantically speaking these 'lines' shouldn't be a <p> anyway, the "natural" flow of a form should be imho, <fieldset, legend, label...>
I will take a proper read of your different alignment things over the weekend as I just popped in today, what do you think of using fieldset? I wonder if that would solve the original float "issues", never thought to check that earlier.
once again thanks for your time on this one
i am not adversed to using anything formy at all, and im happy to get things semantically correct, and also hadnt thought of fieldsets etc..
i will be giving this a good go over tomorrow too, will post any of my findings
many thanks
have a nice weekend
nat
I've had some more thoughts ;) and I'm going to U-turn.. I'm never comfy with workarounds that then need more .. the table/center workaround just seems too clunky, would be OK if there was no other problem perhaps
Having looked at this further and realising the need to have different alignments to the "fieldsets" (up and over, side by side etc..) - I *think* it would be better to go with
inline-blockWhat you want is to have blocks (fieldsets, sets of options) that are capable of centering no matter their width (like an image) and to have the choice to display those blocks side by side (like images). The formatting of the elements inside these blocks should not be interfered with i.e. they should be formatted like block elements without the restrictions that the table cell workaround was showing, If so that is what display: inline-block; is for
9.2.4 The Display Property [w3.org]
inline-block
This value causes an element to generate a block box, which itself is flowed as a single inline box, similar to a replaced element. The inside of an inline-block is formatted as a block box, and the element itself is formatted as an inline replaced element.
so as I said before, I think this is the better property for the job
plusses and minuses here: everyone supports it except FF (below version3). FF has a proprietary property which achieves close to the same thing, and support for inline-block is in FF3. IE supports it though does not apply it to elements that are block level by default, BUT you can force it to.
Why don't I think this is as bad as hacking the table?.. because in this case we are backwards hacking without forcing the property to do something it's not supposed to do.. and the degradation, or non css version should be more graceful.
the workaround for IE which all versions still need is to give it the
display: inline-blockdisplay: inline;firefox property is
-moz-inline-boxanyhow, haven't tested in FF3 (not downloaded the beta yet) so if someone can test this.. it would be great!
here's the code with which it should work..
html, body {padding: 0; margin: 0; border: 0; background: #00f;}.rowbox {
background: #fff;
margin: 10px 10%; /* this could be adjusted to create the effect of min width? */
border: 1px solid #f00;
padding: 5px;
text-align: center; /* center inline blocks */
}.inlinebox {
/* display: -moz-inline-box; /* For FF2 and below */
display: inline-block; /* IE needs a wee bit of help see conditional below */
background: #eee;
margin: 5px;
border: 1px solid #000;
text-align: left; /* to reset text alignment within divs when container has been set to center */
vertical-align: top; /* vertically aligns side by side boxes with preceding ones */
}fieldset {padding: 0 20px 0 5px;}
label {display: block;}
label input {float: left; clear: left;}
label span {
display: block;
margin-left: 25px; /* this would need to change depending on width of input
adding a class to the labels would be one way to differentiate */
}
If that works in FF3 all is good and support is there; but then uncomment the moz property in
.inlinebox<!--[if lte IE 7]>
<style type="text/css" media="screen">
/*
IE needs the inline-block value given to it in 2 x parts
if the element you are using it on is not an inline-element by default.inlinebox {display: inline-block;}
is already in main stylesheet so only second bit needs to be in here
*/
.inlinebox {display: inline;}/* star html hack used inside IE7 conditional
to get code to IE6 and below only */
* html fieldset {float: left;}
</style><![endif]-->
the display: inline; is the only bit IE really needs, but then I noticed IE6 and below don't shrinkwrap the content properly not a huge issue in terms of degrdation but float: left added to first child element did it.
HTML structure:
<div class="rowbox"><div class="inlinebox">
<fieldset>
<legend>Options for..</legend>
<label><input type="radio" /><span>option 5555555 </span></label>
<label><input type="radio" /><span> its quite long</span></label>
<label><input type="radio" /><span>option 3 333 3333</span></label>
<label><input type="radio" /><span>option 44 444</span></label>
<label><input type="radio" /><span>option 5555555 </span></label>
</fieldset>
</div><div class="inlinebox">
<fieldset>
<legend>Options for..</legend>
<label><input type="radio" /><span>option 5555555 </span></label>
<label><input type="radio" /><span>option 44 444</span></label>
<label><input type="radio" /><span>option 5555555 </span></label>
</fieldset>
</div><!--//rowbox --></div>
you can as many "inlinebox" cells inside a "rowbox" as required making for the side by side, or just one inside a "rowbox" for above and below display
ayup.. nothings ever easy, I think the unnecessary bit in this method, if you were to want perfectly "clean" code, would be the "inlinebox" div as the fieldsets could be made to do the work, however due to IE6's foible and the fact that the fieldset has x-browser formatting differences of it's own, and you may not actually want to rely on separate fieldsets (or any other inner element for that matter) all the time it's possibly safest to have the two divs do the generic work.
What do you think this time?
-Suzy
PS: yes I'm naughty using a IE6 hack inside the IE7 conditional this is for speed and demo only, though I personally do not disagree with hacks if they're already in a backwards compatible file ;)
[edited by: SuzyUK at 3:49 pm (utc) on Feb. 3, 2008]
..the original problem being caused by the use white-space:nowrap to force the center table cell to stretch.
From what I see with this method, you should no longer have to use this white-space forcing, and instead if you do want a very long line to break, instead of adding an exceptional class to the HTML of the label, you would just need to add a <br> in the line of text you do want to break.
You could I presume use min/max-width on the spans too, but IE support especially below IE7 will be dodgy, and I think this is where the FF2 discrepancies (between inline-box, and inline-block) will show - it really depends on whether you just think of the original "wrapit" line break as an enhancement or a necessity, whether you force the break using <br> or max-width
-Suzy
once again thanks so much for your time on this one..
sadly though, im not sure that is quite doing it..
maybe if i try to completely explain the brief, it may make more sense..
we have an app that allows the construction of i guess sort of 'surveys'. the 'questions' are added into this app - allowing the normal form elements, for instance
for a radio question:
prompt:
which of these options do you like the most?
options:
this option
that option
this incredibly long option, which is rather long
another shorter option
now, previously we were able to format these questions by hand - ie setting the left margin (actually setting the table cell that sat in to be x% across the page) - this was all done in a wysiwyg gui thing, so you clearly cold seee how it was going to look. we have now ditched the wysiwyg thing, and are just adding these questions blind.
so i need to come up with the markup and styles for all these standard types of form elements, so that they can be added hands-off - ie the person adding them will not have to specify any of the formatting - apart from maybe choosing 'above and below' or 'side by side' - and possibly the otion to wrap certain particularly long options so the page they are on, looks a bit nicer.
when i say above and below, i mean the prompt sits above the options, with the options left aligned but centered, and for side by side, the prompt sits on the left, the options sit on the right (for rtl langs anyhow)
now idealy, i would like to - as i may have said - stick with the same markup for each of these display types (above & below, side by side), but i cant see how this is going to be possible. and its not a complete no no to have diff markup for this..
the tabluar layout seemed to certainly do the above below thing wonderfully. and with your help was working across browsers too (one of my requirements)
on the semantically correct note, again, ideally particularly from my point of view, in order for me to feel that i have done this correctly, i would like to stick with markup that is semantically correct..
but.. in saying that, if its going to cause me too many problems, ill ditch that want.
i guess that about sums it up..
again as i keep saying, i am eternally gratefull for your assistance with this, noone else here cares about getting it right as much as i do.
many thanks
nat
ok, i have been playing around with all this lot, to come up with some sort of markup/css combination that allows the same markup (maybe an extra class here or there) to display the prompt and answer options side by side, or above and below
this is the best i have managed so far..
once again, no luck with IE6, as am using first child selectors.. and surprise surpise IE6 doesnt deal with that lot.. now there is a shocker..
maybe there is a more reliable way of doing this..
anyhow here is all the bumf..
have changed back to HTML 4.01 after having read stuff about the lack of proper XHTML support in .. now wait for it.. IE6, well im shocked.. NOT
Doctype
<!DOCTYPE html PUBLIC "-//W3C//DTD html 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
css
html, body {padding: 0; margin: 0; border: 0; background: #00f;}
.horiz,.vert {
background: #fff;
margin: 10px 10%; /* this could be adjusted to create the effect of min width? */
border: 1px solid #f00;
padding: 5px;
text-align: center; /* center inline blocks */
}
.inlinebox {
display: -moz-inline-box; /* For FF2 and below */
display: inline-block; /* IE needs a wee bit of help see conditional below */
background: #eee;
margin: 0px;
border: 1px solid #000;
text-align: left; /* to reset text alignment within divs when container has been set to center */
vertical-align: top; /* vertically aligns side by side boxes with preceding ones */
}
div.vert > div.inlinebox:first-child{
background-color:red;
display:block;
text-align:center;
}
legend{display:none;}
div.vert fieldset {padding: 0 20px 0 5px;border:0;}
div.vert label {display: block;}
div.vert label input {float: left; clear: left;}
div.vert label span {
display: block;
margin-left: 25px;
}
fieldset{
padding:5px;
}
fieldset label{
display:inline;
}
fieldset label input {float: none; clear: none;}
fieldset label span {
display:inline;
margin-left:0;
}
markup
<div class="vert"><div class="inlinebox">
<p>here is the prompt</p>
</div><div class="inlinebox">
<fieldset>
<legend>zzzzzzzzzzz</legend>
<label><input type="radio" ><span>option 1</span></label>
<label><input type="radio" ><span>option 2</span></label>
</fieldset>
</div><!--//rowbox --></div>
<div class="horiz">
<div class="inlinebox">
<p>here is the prompt</p>
</div><div class="inlinebox">
<fieldset>
<legend>zzzzzzzzzzzz</legend>
<label><input type="radio" ><span>option 1</span></label>
<label><input type="radio" ><span>option 2</span></label>
</fieldset>
</div>
</div>
have hidden the legend bit, as cant get this to display the prmot how i would like, it doesnt seem to act like a normal element. ideally , semantically this would be the correct element i assume
anyhow, if anyone can come up with a better way of doing this, i would put them at the top of my xmas card list
have nice days
nat
