Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers

Webmaster Forum / HTML, CSS, Scripts / CSS / November 2007



Tip: Looking for answers? Try searching our database.

CSS text alignment question

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Matthew - 28 Nov 2007 16:14 GMT
Hi,

I'm mainly a coder, PHP at the moment, but from time to time need to
design and use some css.

I've a css text alignment issue. Mostly to align text neatly in the past
I've used tables. But now I know I should be getting into the 21st C and
using css properly.

Here are 2 mock up pages with some forms on them, obviously I want the
text boxes aligned neatly. The first page shows a nice alignment, the
second does not, take a look.

http://tinyurl.com/2ef9o5
http://tinyurl.com/27rf4e

My form alignment uses 2 css entries:

ItemLeft
{
position: relative;
left: 10px;
}

ItemRight
{
position: relative;
left: 75px;
}

To achieve the first page -the one neatly aligned- I used a fixed-width
font (Courier New), and then added multiple entries so that the number
of chars in the text on the left is the same, so that the alignment of the
text boxes is neat.

EG.

<FormItemLeft>
Subject:
</FormItemLeft>

<FormItemRight>
<input name="subject" type="text" /> <br />
</FormItemRight>

<FormItemLeft>
CC:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</FormItemLeft>

<FormItemRight>
<input name="cc" type="text" /> <br />
</FormItemRight>

Here you can see for the <FormItemLeft> entries 'Subject:' is 8 chars and
'CC:' is 3, so I've added 5 &nbsp; entries after 'CC:'.

Obviously this is a work-around which is rather amateurish and it does not
work with non-fixed-width fonts. My instinct was to use a table, but this
is exactly what css is supposed to stop.

How do I get my alignment to work with non-fixed-width fonts, no forced
spaces, and no tables? I just can't seem to find the right way to do this.

Thanks all.
Ben C - 28 Nov 2007 16:58 GMT
> Hi,
>
[quoted text clipped - 30 lines]
> of chars in the text on the left is the same, so that the alignment of the
> text boxes is neat.
[...]
> Obviously this is a work-around which is rather amateurish and it does not
> work with non-fixed-width fonts. My instinct was to use a table, but this
> is exactly what css is supposed to stop.
>
> How do I get my alignment to work with non-fixed-width fonts, no forced
> spaces, and no tables? I just can't seem to find the right way to do this.

You could use floats. Something like this:

.Label
{
   float: left;
   clear: left;
   width: 10em;
   margin-left: 10px;
}
input { float: left; }

...

<form>
   <span class="Label">User:</span>
   <input type="text" name="user">

   <span class="Label">Password:</span>
   <input type="text" name="password">
</form>

Use margin-left on .Label, not position: relative, if you want to indent
them a bit.

To adjust the spacing between labels and text inputs, just change the
width of .Label. So don't use position: relative at all.
DonO - 28 Nov 2007 18:18 GMT
> > Hi,
>
[quoted text clipped - 64 lines]
> To adjust the spacing between labels and text inputs, just change the
> width of .Label. So don't use position: relative at all.

I've been doing something similar with...

#loginForm label {
    float:left;
    width: 6em;
}

Where I put an ID of "loginForm" in the form tag and then do this...
<p>
<label>item here</label> <input type... />
</p>

That way I can control the vertical spacing with CSS on the paragraph
tags...

HTH.

D.
Matthew - 28 Nov 2007 19:51 GMT
Ben C emailed this:
>> Hi,
>>
[quoted text clipped - 64 lines]
> To adjust the spacing between labels and text inputs, just change the
> width of .Label. So don't use position: relative at all.

Thanks very much for your help. That works very well.

One question what is the purpose of the line...

input { float: left; }

...it does not seem to make any difference to how the layout looks - I've
tried it with that line in and out of the css file?

Thanks again.
DonO - 28 Nov 2007 20:29 GMT
> Ben C emailed this:
>
[quoted text clipped - 77 lines]
>
> Thanks again.

I think you were asking Ben C. but I may be able answer...

Having "float:left" for two items next to each other should hopefully
keep them on the same line next to one another I believe. I think it's
somewhat optional in the case of form elements like the one's we've
described above though.

FWIW... I'm a PHP programmer primarily as well, having to learn to use
CSS where I would have been using tables in the past, so I feel your
pain. Luckily, I work with a designer who has more experience using
CSS so I've picked up a lot. The A List Apart website has been pretty
helpful too.

Good luck.
D.
Matthew - 28 Nov 2007 21:57 GMT
DonO emailed this:
>> Ben C emailed this:
>>
[quoted text clipped - 73 lines]
> CSS so I've picked up a lot. The A List Apart website has been pretty
> helpful too.

Thanks for the help and the pointer to 'a list apart', look what's on that
site, a page dedicated to my question called, 'Prettier Accessible Forms',
here's the URL:

http://alistapart.com/articles/prettyaccessibleforms

Cheers all.
Ben C - 28 Nov 2007 22:23 GMT
> Ben C emailed this:
[...]
>> You could use floats. Something like this:
>>
[quoted text clipped - 31 lines]
> ...it does not seem to make any difference to how the layout looks - I've
> tried it with that line in and out of the css file?

It depends how much width is available. If there's quite a bit, then if
you don't float the inputs you could end up with two labels one
underneath each other on the left, but the two text inputs side by side
on the same line.

The inputs are inline, so they just line up from left to right like
words until there isn't enough space. Floats do the same kind of thing,
but setting "clear: left" on the labels prevents that. It means that
each label has to go below any preceding left floats, so they stack up
vertically.

A float can never go higher than a float that appears earlier in the
document. So if the inputs are also floated, they have to go next to
their corresponding labels (or below them if there isn't enough width
available) but never above them. An inline box on the other hand can and
will go above a float that appeared earlier if there's enough width.
Matthew - 28 Nov 2007 23:15 GMT
Ben C emailed this:
>> Ben C emailed this:
> [...]
[quoted text clipped - 49 lines]
> available) but never above them. An inline box on the other hand can and
> will go above a float that appeared earlier if there's enough width.

I see. Many thanks for the detailed explanation.

Is there any reason why I can't enclose the inputs like this (in case in
future I wish to have different behaviour for different inputs in the same
stylesheet? EG:

Instead of:

input { float: left; }

doing this:

UserFormInput { float: left; }

and then reference it with:

<form>
    <span class="Label">User:</span>
    <UserFormInput>
        <input type="text" name="user">
    </UserFormInput>

    <span class="Label">Password:</span>
    <UserFormInput>
        <input type="text" name="password">
    </UserFormInput>
</form>

Or am I designing that incorrectly?

Thanks again Ben.
Ben C - 29 Nov 2007 08:11 GMT
[...]
> Is there any reason why I can't enclose the inputs like this (in case in
> future I wish to have different behaviour for different inputs in the same
[quoted text clipped - 23 lines]
>
> Or am I designing that incorrectly?

You can't just make up elements, you need to stick to HTML. There's no
such element as UserFormInput in HTML.

But you can give elements whatever class attributes like you like, so
<input class="UserFormInput"> is the way to do it. Then in the
stylesheet,

   .UserFormInput { float: left; }

These are the elements to choose from:

   http://www.w3.org/TR/html401/index/elements.html

Then you have to validate (http://validator.w3.org/), because not all
nesting combinations of elements are allowed, and you don't want the
browser unpredictably re-arranging things (which it will do if the HTML
isn't valid).
Matthew - 29 Nov 2007 19:38 GMT
Ben C emailed this:
> [...]
>> Is there any reason why I can't enclose the inputs like this (in case in
[quoted text clipped - 42 lines]
> browser unpredictably re-arranging things (which it will do if the HTML
> isn't valid).

I just realized I forgot to reply to this post, oops, sorry. Many thanks
again for your help.
Nik Coughlin - 28 Nov 2007 20:32 GMT
> Hi,
>
[quoted text clipped - 11 lines]
> http://tinyurl.com/2ef9o5
> http://tinyurl.com/27rf4e

Some people would say that a form with labels *is* tabular data and that a
table is therefore appropriate.
Matthew - 28 Nov 2007 21:54 GMT
Nik Coughlin emailed this:

>> Hi,
>>
[quoted text clipped - 14 lines]
> Some people would say that a form with labels *is* tabular data and that
> a table is therefore appropriate.

...but they would be wrong and have failed to understand what the term
'tabular data' means. :-)
dorayme - 28 Nov 2007 22:09 GMT
> Nik Coughlin emailed this:
> >
[quoted text clipped - 5 lines]
> ...but they would be wrong and have failed to understand what the term
> 'tabular data' means. :-)

They would be wrong? OK, what is the deep meaning of "tabular"
that excludes a layout being tabular in which the item in a
column in one row relates as indicator of type of information to
be typed into a field in a cell on the same row in an adjoining
column, both columns able to be meaningfully headed?

Signature

dorayme

Matthew - 29 Nov 2007 11:24 GMT
dorayme emailed this:

>> Nik Coughlin emailed this:
>>> "Matthew" <matthew@spamkiller.com> wrote in message
[quoted text clipped - 9 lines]
> be typed into a field in a cell on the same row in an adjoining
> column, both columns able to be meaningfully headed?

I have no interest in taking part in a semantic discussion about this. If
you wish to consider layouts as tabular data that's your business.
dorayme - 29 Nov 2007 20:21 GMT
> dorayme emailed this:
> >
[quoted text clipped - 14 lines]
> I have no interest in taking part in a semantic discussion about this. If
> you wish to consider layouts as tabular data that's your business.

You misread what I said. I do not consider it wise in general to
layout web pages with tables. Look again at the wording of my
question and think about it, and have a discussion with your
self, no need to close your mind or discuss it with me.

Signature

dorayme

Nik Coughlin - 29 Nov 2007 01:28 GMT
> Nik Coughlin emailed this:
>>
[quoted text clipped - 19 lines]
> ...but they would be wrong and have failed to understand what the term
> 'tabular data' means. :-)

The W3C created the HTML table model to "arrange data - text, preformatted
text, images, links, forms, form fields, other tables, etc. - into rows and
columns of cells." They specifically state that tables are not to be used
for layout.

Tabular data indicates a logical relationship between cells.  So, that in
mind, how is this not a logical relationship?

<tr>
 <th>Name</th>
 <td><input type="text" name="name"></td>
</tr>

Cheers
Matthew - 29 Nov 2007 11:31 GMT
Nik Coughlin emailed this:

>> Nik Coughlin emailed this:
>>>
[quoted text clipped - 34 lines]
>  <td><input type="text" name="name"></td>
> </tr>

That 'argument' can be applied to any layout issue. A photograph on a web
page has a 'logical relationship' to the text below it which says who the
photograph is of. Just cos something has a logical relationship with
something else does not mean you should use tables to format its layout.
dorayme - 29 Nov 2007 20:31 GMT
[in reply to Nick]

> A photograph on a web
> page has a 'logical relationship' to the text below it which says who the
> photograph is of. Just cos something has a logical relationship with
> something else does not mean you should use tables to format its layout.

The entry criteria for proper use of tables is not any sort of
logical relationship between parts but quite specific ones. You
are missing this point.

Signature

dorayme

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.