Ah well, from your first post, we all just assume this is a site, possibly starting from scratch, meant for the General Public.
When you’re writing browser-based applications where the users have a certain set environment, you do indeed have much more leeway. There are people who get to build stuff Just for Firefox or just for Safari because they can set the user environment. Also, sometimes you can go around the usual accessibility rules, if you KNOW nobody visiting these sites are using a screen reader for example, or if google is not a consideration.
I have read a lot of articles and blogs where people make it look like it is a sin to not use a specific facility/feature. I do agree in some cases but in most cases it is not really that simple on the field. For example, i know i will have a very hard time convincing my manager that we use doctype on all our templates because all our pages work fine we’ve not had any issues given that our pages have been live for > 15 years. He is a strong believer of the “If it aint broke dont fix it” motto.
It’s a sin to not use a doctype for any new sites meant for the general public… and for that matter, for old sites meant for the general public. This is because using a doctype allows you-the-developer to know you’re working in standards mode and not also quirks mode, and helps when you’re dealing with lord-knows how many possible user agents, some of which aren’t even human (bots) and some of which are modified with AT (accessibility technology).
[quote]Second, floated children means a container like Wrapper isn’t going to “see” them. It’ll collapse to no height, thinking that it’s empty. Except in IE… IE has a bug where, if you’ve triggered IE’s mysterious Haslayout property (which you did when you set a width on wrapper), it will (incorrectly!) wrap those floats.
I didnt quite understand this. I thought that floated children will float to the edge of its container and not the page[/quote]
They do, you’re right. To “see” what I’m talking about, make a throw away page with this:
(head etc)…
<div id=“wrapper”>
<div id=“float1”>
<p>Throw enough Lorem Ipsum in here to get several lines of content, or just throw an explicit height on this box.</p>
</div>
</div>
#wrapper {
width: 500px; /by setting a width, we’re gonna trigger Haslayout in IE/
margin: 0 auto;
background-color: #f00; /red/
}
#float1 {
float: left;
width: 200px;
height if you want to set some height…
background-color: #0f0; /green/
}
After building that, take a look in IE and in FF. Uh, Haslayout was removed from IE8 except I assume when it’s in “compatability mode” so I mean IE6 or 7. You should see the centered, red wrapper.
In all other browsers, you should NOT see the red container. The width is still there, but the CSS rules state that normally a box will enclose its children (boxes have normally height: auto, and auto means "determined by the amount of content inside) but when those children are floated, that doesn’t happen.
So developers have come up with lots of ways to make wrappers enclose floats, because a lot oif the time, or most of the time, we want that to happen.
If in your case the wrapper is invisible (no background, colour or borders) there’s pretty much little difference, with the exception that when containers wrap/enclose their floated children you’re able to put a bottom margin on that container to push the following content down, and that following content may not have to have “clear” on them.
An example you can look at in IE6 or 7 and then some Compliant Modern Browser. IE6 doesn’t like those pages very much though : )
I did try this and it works fine if i use px on the wrapper container. The problem with this is that the container will always have a fixed width whereas i would like it to take up whatever space is available to it. I guess the other option is to use the maximum width but im guessing it would be difficult as people dont use the same resolutions on their monitor.
Well, when you have width: 100% (which, btw, a static box or even a position: relative box doesn’t necessarily need that statement… normally that’s what a block tries to be anyway, 100% width of its container… in your case, the body element), that’s fine but when you start making the viewport smaller (that’s when you say you’re getting the dropping right?) at some point, there’s a minimum width these forms have. Even though the boxes they are in are 50% wide, there’s also a point where the forms won’t squish any smaller, and then one of them simply has to drop.
So normally you’d measure at what width they are simply too wide to fit side-by-side (and here, if your wrapper encloses its floats and you have a bg colour on it, it’s nice and helps you “see” what’s going on), you can set a min-width on that container. So the container can continue to do it’s normal width: 100%, except when the viewport gets too small. At that point, a scrollbar is introduced and the floats can stay side-by-side.
And like I said you could keep the divs 50% width (or the safer 49% and some negative margins to keep everyone lined up) on the divs but set some width on the forms inside. If the divs have a bg colour and the forms don’t, nobody would know the difference between the div and the form.
… even if you’re sure there aren’t any people using AT you should still see if you can make the forms more sensible.
The text above the inputs should be in labels. So far as I know, you’ve got nothing around that text now so adding labels shouldn’t affect anything visually. Labels should ideally have a “for” attribute that matches the id of the input. This lets people in most browsers be able to click anywhere in the label and they can get the focus on the related input (which is very nice for little things like checkboxes and radio buttons).
Order might or might not matter. The explanation (“clicking this button Does Stuff”) at the bottom comes AFTER the button it’s talking about, meaning anyone who does surf linearly (like screen reader users) are going to have already encountered the button before hearing/reading what it does. You may not have users like that, but now you know in case you ever do get them later, lawlz.
These templates were designed many years ago and are used by people in the Health industry who believe it or not some are still using IE4.
I worked at a small hospital where the patient information was dealt with in the cheapest software the hospital administration could find. It was 10+ year-old Visual Basic and all the developers of it were dead or retired, and the company was very very far away (California). It was extremely difficult to integrate it into the other computer system from Siemens that dealt with patient information and films (this was part of radiography), and it had a lot of trouble dealing with new privacy laws. If the original software had been built better, more robust and flexible, everyone would have saved so much money. As workers, we were always pissed at the system and had dreams of murdering hapless nerds. Lawlz.
Anyway I could have sworn I just saw some thread around here where someone needed two boxes right next to each other and 50% wide and a more precise solution was presented to them… actually that possibly was even in another forum. If I find it I can post the link.
Or Paul O’B can step in and show you in a flourish of genius how to get this working in both old and new browsers… I mean, does this have to work in like IE5.5?
On the occasions that i do get involved in the design of web pages i am usually making changes to the body/content of a page and not the whole page.