«

Adrienne Boswell wrote:
> Here's the test page:http://silverlakereservoirs.org/testadduser.html
>
> In IE (IE6, 7, the input for firstname is jumping all the way to the
> left, which pushes all the labels one field down and is confusing as
> heck for users. Eg:

FF as well.

I do labels the other way round. Instead of using the for attribute, nest
the input field within the label:
<label>whatever<input ...></label>

That way they can't get lost.

Why the massive crosspost to those microsoft groups, which my news server
does not have and are therefore snipped?

Gazing into my crystal ball I observed "rf" <> writing in
news9ljm.13082$:

> Adrienne Boswell wrote:
>> Here's the test page:http://silverlakereservoirs.org/testadduser.html
>>
>> In IE (IE6, 7, the input for firstname is jumping all the way to
>> the left, which pushes all the labels one field down and is confusing
>> as heck for users. Eg:
>
> FF as well.

I'm not seeing that in FF (except with the IE tab). Which version?

>
> I do labels the other way round. Instead of using the for attribute,
> nest the input field within the label:
><label>whatever<input ...></label>

I like to use it to line everything up. I don't seem to be able to do
that with nesting.

>
> That way they can't get lost.

I'm doing this all server side anyway. They don't get lost. The server
loops through the fields and puts all the requisite properties in. (Of
course you are only looking at the rendered HTML).

>
> Why the massive crosspost to those microsoft groups, which my news
> server does not have and are therefore snipped?
>
>
>

Sometimes the people in the microsoft groups have more clues about why
their f*d up browser is doing something. S'all right, I can follow from
here (and I'm glad you trimmed just because of my response).


--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Adrienne Boswell wrote:
> Gazing into my crystal ball I observed "rf" <> writing in
> news9ljm.13082$:
>
>> Adrienne Boswell wrote:
>>> Here's the test
>>> page:http://silverlakereservoirs.org/testadduser.html
>>>
>>> In IE (IE6, 7, the input for firstname is jumping all the way to
>>> the left, which pushes all the labels one field down and is
>>> confusing as heck for users. Eg:
>>
>> FF as well.
>
> I'm not seeing that in FF (except with the IE tab). Which version?

Er, 3.0.5. Same with seamonkey 1.1.7. FWIW with Safari the asterisks are in
the wrong place (to the very left of the form, on a "line" by themselves.).
Is that where they are supposed to be? But, on a seperate line?


Speaking of those asterisks, remove them (or put them inside the label
element) and everything is fixed. I suspect it is the combination of an *
followed by a float: left; label followed by an input field is confusing the
browsers. This also explains the behaviour in Safari.

Should not happen I agree but then...

>> I do labels the other way round. Instead of using the for attribute,
>> nest the input field within the label:
>> <label>whatever<input ...></label>
>
> I like to use it to line everything up. I don't seem to be able to do
> that with nesting.

Quite possible. Just put the label text inside some container with a width,
as you are doing right now.

> I'm doing this all server side anyway. They don't get lost.

Well, actually, they do. Hence your post

>The
> server loops through the fields and puts all the requisite properties
> in. (Of course you are only looking at the rendered HTML).

and it is the rendered HTML that is causing you the problem. The browser
doesn't care if somethng is done "server side" or if it is carefully hand
crafted by typing the stuff into a hexadecimal editor. It is the end result
that is displayed and, in this case, incorrectly. I'd still like to know why
though. Perhaps it's those breaks in there as well. What does <br> mean when
it's after something that is floated?

Gazing into my crystal ball I observed "rf" <> writing in
news:qfmjm.13092$:

> Speaking of those asterisks, remove them (or put them inside the label
> element) and everything is fixed. I suspect it is the combination of
> an * followed by a float: left; label followed by an input field is
> confusing the browsers. This also explains the behaviour in Safari.
>
> Should not happen I agree but then...
>

rf... pucker up - I'm sending you a big, huge kiss. It was those astericks
that was doing it. Thanks so much. My hero!

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

On Fri, 21 Aug 2009 00:54:46 GMT, rf wrote:

> Adrienne Boswell wrote:
>> Gazing into my crystal ball I observed "rf" writing in
>> news9ljm.13082$:
>>
>>> Adrienne Boswell wrote:
>>>> Here's the test page:
>>>> http://silverlakereservoirs.org/testadduser.html
>>>>
>>>> In IE (IE6, 7, the input for firstname is jumping all the way to
>>>> the left, which pushes all the labels one field down and is
>>>> confusing as heck for users. Eg:
>>>
>>> FF as well.
>>
>> I'm not seeing that in FF (except with the IE tab). Which version?
>
> Er, 3.0.5. Same with seamonkey 1.1.7. FWIW with Safari the asterisks are in
> the wrong place (to the very left of the form, on a "line" by themselves.).
> Is that where they are supposed to be? But, on a seperate line?
>
>
> Speaking of those asterisks, remove them (or put them inside the label
> element) and everything is fixed. I suspect it is the combination of an *
> followed by a float: left; label followed by an input field is confusing the
> browsers. This also explains the behaviour in Safari.

And apparently Adrienne has removed the asterisks, which is why I don't see
them or the original alignment problem in any of my browsers.

Case closed?

--
John

Adrienne Boswell wrote:
> Gazing into my crystal ball I observed "rf" <> writing in
> news:qfmjm.13092$:
>
>> Speaking of those asterisks, remove them (or put them inside the
>> label element) and everything is fixed. I suspect it is the
>> combination of an * followed by a float: left; label followed by an
>> input field is confusing the browsers. This also explains the
>> behaviour in Safari.
>>
>> Should not happen I agree but then...
>>
>
> rf... pucker up - I'm sending you a big, huge kiss. It was those
> astericks that was doing it. Thanks so much. My hero!

<blush> Not in front of the wife </blush>

It alway pays to have a wife *and* a girlfriend. Wife will think you are
over at the girlfriends place and girlfriend will think you are home with
the wife, when in reality you are down at the pub shooting pool with the
boys.

Ben C wrote:
> On 2009-08-21, rf <> wrote:
> [...]
>> and it is the rendered HTML that is causing you the problem. The
>> browser doesn't care if somethng is done "server side" or if it is
>> carefully hand crafted by typing the stuff into a hexadecimal
>> editor. It is the end result that is displayed and, in this case,
>> incorrectly. I'd still like to know why though. Perhaps it's those
>> breaks in there as well. What does <br> mean when it's after
>> something that is floated?
>
> It just puts a line break in the text, and doesn't particularly get
> involved in the floats (unless you set clear on it).
>
> For example, you might have a bit of text, then a big left float. Then
> more text which carries on down the right hand side of that float. If
> there's a <br> in the text, it'll start a new line just below the
> previous one in the normal way, all still to the right of the float.

You are correct, the <br> has nothing to do with this.

As Adrienne has fixed her page I have put up an example.
http://barefile.com.au/t.html

Her problem was as in the second fieldset, the label element was dropping
below the input field.

The * was the problem. On thinking about it the browser is doing what it
should. There is an *. Then there is the label element which is correctly
layed out below the *. Then comes the input element which quite rightly
appears directly after the *, the label element having been removed from the
flow.

It's odd that Safari does it completely differently, and IMHO wrong. The
floated label element appears before the *, not below it.

Glad we cleared that up Adrienne

In article <>,
Ben C <> wrote:

> Why should it go below the *? The label element should float to the
> left, and then have the * and the input to the right of it, on the same
> line, which is what Konqueror is doing (don't have Safari).

Can't see it on my Mac Safari 3... looks same as FF

--
dorayme