table-less layout & forms

[Zak McGregor]

Hi all

Are there any good solutions to aligning form field names and input boxes
without resorting to tables? I am struggling to do this nicely at the
moment.

Thanks
Ciao

Zak

--
=============== =============== =============== =============== ============
http://www.carfolio.com/ Searchable database of 10 000+ car specs
=============== =============== =============== =============== ============

[Brian]

Re: table-less layout & forms

Zak McGregor wrote:[color=blue]
>
> Are there any good solutions to aligning form field names and input
> boxes without resorting to tables?[/color]

Assuming you have marked up the form with <label> for each form element:

assign a width to the label, and float it left. See
< http://www.julietremblay.com/site/contact.html >
not a table in site. I did this page, so ask if you have questions
about what's there.

--
Brian
follow the directions in my address to email me

[Zak McGregor]

Re: table-less layout &amp; forms

On Wed, 09 Jul 2003 07:09:15 +0200, Brian <"Brian"
<brian@wfcr.org .invalid-remove-this-part>> wrote:
[color=blue]
> Zak McGregor wrote:[color=green]
>>
>> Are there any good solutions to aligning form field names and input
>> boxes without resorting to tables?[/color]
>
> Assuming you have marked up the form with <label> for each form element:
>
> assign a width to the label, and float it left. See <
> http://www.julietremblay.com/site/contact.html > not a table in site. I
> did this page, so ask if you have questions about what's there.[/color]

Thanks, but label support[1] is not great and in some browsers it displays
buggily when given a display: css rule. Mozilla springs to mind for
example.

I have subsequently found this:

http://studioid.com/cgi-bin/links/jump.cgi?ID=444

which goes some way to sorting me out.

Ciao

Zak
[1] I'm not sure that the label tag is meant for this either, which may
explain some bugginess wrt the displaying of it.
--
=============== =============== =============== =============== ============
http://www.carfolio.com/ Searchable database of 10 000+ car specs
=============== =============== =============== =============== ============

[Zak McGregor]

Re: table-less layout &amp; forms

[snip]

Right, I'm going to be flambed for this, but IMHO css is unable to handle
laying out something as simple as a form. Why on earth did css end up
being so absolutely crap at placing elements on an html page? You can
place elements, sure, I do not dispute that, but you've got a choice between
liquid design _or_ reasonable positioning.

</grumble>

--
=============== =============== =============== =============== ============
http://www.carfolio.com/ Searchable database of 10 000+ car specs
=============== =============== =============== =============== ============

[kayodeok]

Re: table-less layout &amp; forms

Zak McGregor <zak@mighty.co. za> wrote in news:beg6a8$mge $1@ctb-
nnrp2.saix.net:
[color=blue]
> Are there any good solutions to aligning form field names and input boxes
> without resorting to tables? I am struggling to do this nicely at the
> moment.[/color]

Does this help?

http://www.webweaver.org/dan/css/cssforms.html

--
Kayode Okeyode

[Lauri Raittila]

Re: table-less layout &amp; forms

In article <beg6a8$mge$1@c tb-nnrp2.saix.net> , Zak McGregor wrote:[color=blue]
> Hi all
>
> Are there any good solutions to aligning form field names and input boxes
> without resorting to tables?[/color]

Yes.
[color=blue]
> I am struggling to do this nicely at the moment.[/color]

And your form is where? URL?. And your description of how it should look?

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

[Brian]

Re: table-less layout &amp; forms

Zak McGregor wrote:[color=blue]
>[color=green][color=darkred]
>>>Are there any good solutions to aligning form field names and input
>>>boxes without resorting to tables?[/color]
>>
>>Assuming you have marked up the form with <label> for each form element:
>>
>>assign a width to the label, and float it left. See
>>http://www.julietremblay.com/site/contact.html[/color]
>
> Thanks, but label support[1] is not great and in some browsers it displays
> buggily when given a display: css rule. Mozilla springs to mind for
> example.[/color]

The form I designed (url above) looks quite nice in Mozilla, thank you
very much. :) Also works on O7/Win, IE5-5.5-6.0/Win, IE5.x/Mac,
N7/Mac, N7/Win.

I just tested display: block, inline, and none in Moz 1.3/Win on the
form in question. All 3 worked. Do you have any examples where it
does not work?
[color=blue]
> I have subsequently found this:
> http://studioid.com/cgi-bin/links/jump.cgi?ID=444[/color]

which recommends using the <label> element.
[color=blue]
> I'm not sure that the label tag is meant for this either, which may
> explain some bugginess wrt the displaying of it.[/color]

Pardon? That's what the label element is for. Why else would you use it?

http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL

--
Brian
follow the directions in my address to email me

[Brian]

Re: table-less layout &amp; forms

Zak McGregor wrote:[color=blue]
>
> Right, I'm going to be flambed for this[/color]

No flames here. But I am going to correct you where I believe you are
wrong.
[color=blue]
> but IMHO css is unable to handle laying out something as simple as
> a form.[/color]

Here's the url (again):

http://www.julietremblay.com/site/contact.html

The layout was done with css. Not with tables. Now, you were saying?
[color=blue]
> Why on earth did css end up being so absolutely crap at placing
> elements on an html page?[/color]

I don't know what you are looking for. I can imagine, but I'd rather
let you state what you are after, keeping in mind the medium(s).
[color=blue]
> You can place elements, sure, I do not dispute that, but you've got
> a choice between liquid design _or_ reasonable positioning.[/color]

css is about flexible design, which is what I think you mean by liquid.

You are making bogus generalizations , the sort that trolls commonly
use to start arguments. If you are looking for help, ask for it --
without vague complaints that css is "crap." Then you won't see any
flames.

--
Brian
follow the directions in my address to email me

[Zak McGregor]

Re: table-less layout &amp; forms

On Wed, 09 Jul 2003 18:09:56 +0200, Lauri Raittila <"Lauri Raittila"
<lauri@raittila .cjb.net>> wrote:
[color=blue]
> In article <begc5d$p85$1@c tb-nnrp2.saix.net> , Zak McGregor wrote:[color=green]
>> [snip]
>>
>> Right, I'm going to be flambed for this,[/color]
>
> For reason.[/color]

Or not, possibly.
[color=blue][color=green]
>> but IMHO css is unable to handle
>> laying out something as simple as a form. Why on earth did css end up
>> being so absolutely crap at placing elements on an html page?[/color]
>
> You mean, IE don't support CSS. CSS3 will enable lot more, but there is
> no hurry untill even current CSS is supported by _some_ browser.[/color]

Nope, I mean even my spiffy Mozilla with better-than-most CSS support
will struggle to do the simplest two-column layout with CSS without
hard-coding things like margin-left or other fixed-width foppery.
[color=blue][color=green]
>> You can
>> place elements, sure, I do not dispute that, but you've got a choice
>> between liquid design _or_ reasonable positioning.[/color]
>
> And with HTML you have? How?[/color]

A basic grid made with a table, with % widths on tds.

I have yet to see a reasoned explanation why a simple table (ie no
nesting) is any worse than nested and floated divs in terms of
accessibility. Would you like to try?

Ciao
Zak
--
=============== =============== =============== =============== ============
http://www.carfolio.com/ Searchable database of 10 000+ car specs
=============== =============== =============== =============== ============

[Zak McGregor]

Re: table-less layout &amp; forms

On Wed, 09 Jul 2003 20:18:37 +0200, Brian <"Brian"
<brian@wfcr.org .invalid-remove-this-part>> wrote:
[color=blue]
> Zak McGregor wrote:[color=green]
>>
>> Right, I'm going to be flambed for this[/color]
>
> No flames here. But I am going to correct you where I believe you are
> wrong.[/color]

Fine, let's reason this out on that level :)
[color=blue][color=green]
>> but IMHO css is unable to handle laying out something as simple as a
>> form.[/color]
>
> Here's the url (again):
> http://www.julietremblay.com/site/contact.html
>
> The layout was done with css. Not with tables. Now, you were saying?[/color]

I was saying that the <label> element is supported to differnt degrees on
different browsers. I have been convinced that your use of it is perfectly
within the spec from w3.

In terms of label displaying buggily, at least on Mozilla, I *know* that
to be the case as my very first attempt at table-less CSS forms was
exactly your approach. It was scuppered by Mozilla not displaying label
elements correctly even when explicitly given display: directives in the
CSS. I forget the specific Moz version though, sorry. Can't find my
bugzilla entry for that either, even though I'm pretty sure I did file a
bug report.
[color=blue][color=green]
>> Why on earth did css end up being so absolutely crap at placing
>> elements on an html page?[/color]
>
> I don't know what you are looking for. I can imagine, but I'd rather
> let you state what you are after, keeping in mind the medium(s).[/color]

In a nutshell, I want to easily position at least 2 elements side-by-side
on an html page with the following requirements:

- their heights are the same
- they are positioned without hard-coding margins or widths or position. -
their widths are flexible and determined by their content, not by any
specific css values.

A further thing that I would *like* but is not a neccessity is that the
elements are not nested. IE I would prefer to not see <elem>
<nested_elem1 ></nested_elem1>
<nested_elem2 ></nested_elem2>
</elem>

That is it, I think.
[color=blue][color=green]
>> You can place elements, sure, I do not dispute that, but you've got a
>> choice between liquid design _or_ reasonable positioning.[/color]
>
> css is about flexible design, which is what I think you mean by liquid.[/color]

What I mean by liquid is that it can handle different displays, types of
displays and resolutions without breaking. Using any fixed-width
positioning in particular will break such design instantly. CSS cannot be
used to position elements on a page (assuming you need more than
top-to-bottom positioning) without one of a float: or position: directive,
either of which creates a need for hardcoded margins or positions. Float
because the floated element then is excluded from calculations on
positioning other elements relative to it, the position: directive
obviously also needs hard-coded values in order to place it alongside
another element.

Obviously CSS loses some meaning especially with respects to any sort of
positioning when certain classes of UA encounter it. That does not mean
(IMHO) that for those classes of UAs that can handle and should respond to
CSS positioning directives that they should have difficulty rendering
liquid designs done in CSS.
[color=blue]
> You are making bogus generalizations , the sort that trolls commonly use
> to start arguments. If you are looking for help, ask for it -- without
> vague complaints that css is "crap." Then you won't see any flames.[/color]

If I use emotive terms, it is because I am frustrated that a good theory
has been (IMHO) completely fscked up in practice. For whatever reason.

My complaint was not in the slightest bit vague or bogus though. My
statement was "Why on earth did css end up being so absolutely crap at
placing elements on an html page?" which is not vague in the slightest.
Read it again in the original post for even more context for my statement.
In addition, it's not only "crap", but "_absolutel y_ crap".

Ciao

Zak

--
=============== =============== =============== =============== ============
http://www.carfolio.com/ Searchable database of 10 000+ car specs
=============== =============== =============== =============== ============

[Zak McGregor]

Re: table-less layout &amp; forms

On Wed, 09 Jul 2003 20:09:24 +0200, Brian <"Brian"
<brian@wfcr.org .invalid-remove-this-part>> wrote:
[color=blue][color=green]
>> Thanks, but label support[1] is not great and in some browsers it
>> displays buggily when given a display: css rule. Mozilla springs to
>> mind for example.[/color]
>
> The form I designed (url above) looks quite nice in Mozilla, thank you
> very much. :) Also works on O7/Win, IE5-5.5-6.0/Win, IE5.x/Mac,
> N7/Mac, N7/Win.[/color]

Yup, looks great with Moz 1.3 here.
[color=blue]
> I just tested display: block, inline, and none in Moz 1.3/Win on the
> form in question. All 3 worked. Do you have any examples where it does
> not work?[/color]

As I mentioned in another post, styling the label element was my very
first attempt at table-less forms, and with whichever version of Mozilla
I was using at the time (it would have been the current release version),
styled label support was buggy and ultimately aborted my attempt at that
approach to table-less form layouts.
[color=blue][color=green]
>> I have subsequently found this:
>> http://studioid.com/cgi-bin/links/jump.cgi?ID=444[/color]
>
> which recommends using the <label> element.[/color]

OK I see that <label> can be styled, which I was mistaken in thinking it
was not supposed to have.
[color=blue][color=green]
>> I'm not sure that the label tag is meant for this either, which may
>> explain some bugginess wrt the displaying of it.[/color]
>
> Pardon? That's what the label element is for. Why else would you use
> it?
>
> http://www.w3.org/TR/html401/interac...tml#edef-LABEL[/color]

Well yes. The primary reason to use label is to associate the text
description of the field in the form to the actual form element, so that
focus can be transferred appropriately, amongst other things.

Ciao

Zak

--
=============== =============== =============== =============== ============
http://www.carfolio.com/ Searchable database of 10 000+ car specs
=============== =============== =============== =============== ============

[Jonathan Snook]

Re: table-less layout &amp; forms


"Zak McGregor" <zak@mighty.co. za> wrote in message
news:bejbbi$q4s $1@ctb-nnrp2.saix.net. ..[color=blue]
> I have yet to see a reasoned explanation why a simple table (ie no
> nesting) is any worse than nested and floated divs in terms of
> accessibility. Would you like to try?[/color]

A table should be used to represent tabular data. A table represents a
correlation of information in its rows and columns. Using a table for layout
purposes, breaks this model by creating an association where none exists.

(btw: I understand the point you're trying to make... JAWS and HPR do fine
reading off a page where the content is laid out with tables, as I'm sure
most other browsers out there do...they'd have to considering how 90% of the
sites out there are built. but just because you CAN do something, doesn't
mean you should.)

My slightly off-topic 2¢: designers put too much effort into pixel perfect
"designs". The average person just doesn't care (look at the increasing
popularity of blogs with their simple layout and minimalist design).

Jonathan

[Jim Dabell]

Re: table-less layout &amp; forms

Zak McGregor wrote:
[color=blue]
> On Wed, 09 Jul 2003 20:18:37 +0200, Brian <"Brian"
> <brian@wfcr.org .invalid-remove-this-part>> wrote:
>[/color]
[snip][color=blue]
> In terms of label displaying buggily, at least on Mozilla, I *know* that
> to be the case as my very first attempt at table-less CSS forms was
> exactly your approach. It was scuppered by Mozilla not displaying label
> elements correctly even when explicitly given display: directives in the
> CSS. I forget the specific Moz version though, sorry. Can't find my
> bugzilla entry for that either, even though I'm pretty sure I did file a
> bug report.[/color]

There was a bug in Mozilla where floated <label> elements were not
displayed. As I recall, it never made it into a released Mozilla version,
however, it did appear in one Netscape version. The workaround is simply
to include a <span> element.

I don't consider that to be equivalent to "<label> elements are buggy, I
should avoid them", nor "CSS is not capable of doing what I want it to".


[snip][color=blue][color=green][color=darkred]
>>> You can place elements, sure, I do not dispute that, but you've got a
>>> choice between liquid design _or_ reasonable positioning.[/color]
>>
>> css is about flexible design, which is what I think you mean by liquid.[/color]
>
> What I mean by liquid is that it can handle different displays, types of
> displays and resolutions without breaking. Using any fixed-width
> positioning in particular will break such design instantly. CSS cannot be
> used to position elements on a page (assuming you need more than
> top-to-bottom positioning) without one of a float: or position: directive,
> either of which creates a need for hardcoded margins or positions.[/color]

Hardcoded != fixed width. You are free to use ems, %, etc.


--
Jim Dabell

[Jim Dabell]

Re: table-less layout &amp; forms

Zak McGregor wrote:
[color=blue]
> On Wed, 09 Jul 2003 18:09:56 +0200, Lauri Raittila <"Lauri Raittila"
> <lauri@raittila .cjb.net>> wrote:[/color]
[snip][color=blue][color=green]
>> You mean, IE don't support CSS. CSS3 will enable lot more, but there is
>> no hurry untill even current CSS is supported by _some_ browser.[/color]
>
> Nope, I mean even my spiffy Mozilla with better-than-most CSS support
> will struggle to do the simplest two-column layout with CSS without
> hard-coding things like margin-left or other fixed-width foppery.[/color]

Mozilla derivatives, Opera, Konqueror, Safari, and the next version of
Omniweb all support CSS tables. Those are all the current CSS supporting
screen browsers I can think of, off the top of my head, excluding Internet
Explorer.

So, yes, you mean Internet Explorer doesn't support the five-year-old CSS 2
specification. Not surprising, as it still doesn't conform to HTTP 1.1 (4+
years old), PNG (7+ years old), or HTML 4 (5+ years old). Only the last is
really forgivable, as it seems no browser has managed to get this
completely right. Oh, and remember that Microsoft is a member of the W3C,
and have contributed to most of these specifications themselves.

[color=blue][color=green][color=darkred]
>>> You can
>>> place elements, sure, I do not dispute that, but you've got a choice
>>> between liquid design _or_ reasonable positioning.[/color]
>>
>> And with HTML you have? How?[/color]
>
> A basic grid made with a table, with % widths on tds.
>
> I have yet to see a reasoned explanation why a simple table (ie no
> nesting) is any worse than nested and floated divs in terms of
> accessibility. Would you like to try?[/color]

It raises the bar in terms of what a UA has to do to understand a page.
Instead of seeing a <table> element and expecting a table, it has to guess
at whether it's a table or not. This isn't reliable, and it sucks up
developer time.

Yes, to a certain extent, if you test well, and keep it simple, you'll avoid
most problems, but you can't escape the fact that you are misusing HTML
(and there are also the other reasons, like coupling layout and content too
closely).

--
Jim Dabell

[Simon Andrews]

Re: table-less layout &amp; forms



Brian wrote:[color=blue]
> Zak McGregor wrote:
>[color=green]
>>[color=darkred]
>>>> Are there any good solutions to aligning form field names and input
>>>> boxes without resorting to tables?
>>>
>>>
>>> Assuming you have marked up the form with <label> for each form element:
>>>
>>> assign a width to the label, and float it left. See
>>> http://www.julietremblay.com/site/contact.html[/color]
>>
>>
>> Thanks, but label support[1] is not great and in some browsers it
>> displays
>> buggily when given a display: css rule. Mozilla springs to mind for
>> example.[/color]
>
>
> The form I designed (url above) looks quite nice in Mozilla, thank you
> very much. :) Also works on O7/Win, IE5-5.5-6.0/Win, IE5.x/Mac,
> N7/Mac, N7/Win.[/color]

Err, doesn't work here. The labels on the form aren't visible. This is
using Netscape 7.0 Win2K. It looks fine on IE 6 on the same machine
though and on Moz 1.3 on XP.

Simon.