By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,422 Members | 1,614 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,422 IT Pros & Developers. It's quick & easy.

table-less layout & forms

P: n/a
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
================================================== ======================
Jul 20 '05 #1
Share this Question
Share on Google+
39 Replies


P: n/a
Zak McGregor wrote:

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 >
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

Jul 20 '05 #2

P: n/a
On Wed, 09 Jul 2003 07:09:15 +0200, Brian <"Brian"
<br***@wfcr.org.invalid-remove-this-part>> wrote:
Zak McGregor wrote:

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 > not a table in site. I
did this page, so ask if you have questions about what's there.


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
================================================== ======================
Jul 20 '05 #3

P: n/a
[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
================================================== ======================
Jul 20 '05 #4

P: n/a
Zak McGregor <za*@mighty.co.za> wrote in news:beg6a8$mge$1@ctb-
nnrp2.saix.net:
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.


Does this help?
http://www.webweaver.org/dan/css/cssforms.html

--
Kayode Okeyode
Jul 20 '05 #5

P: n/a
In article <be**********@ctb-nnrp2.saix.net>, Zak McGregor wrote:
Hi all

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


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.

Jul 20 '05 #6

P: n/a
Zak McGregor wrote:
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


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.


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?
I have subsequently found this:
http://studioid.com/cgi-bin/links/jump.cgi?ID=444
which recommends using the <label> element.
I'm not sure that the label tag is meant for this either, which may
explain some bugginess wrt the displaying of it.


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
--
Brian
follow the directions in my address to email me

Jul 20 '05 #7

P: n/a
Zak McGregor wrote:

Right, I'm going to be flambed for this
No flames here. But I am going to correct you where I believe you are
wrong.
but IMHO css is unable to handle laying out something as simple as
a form.
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?
Why on earth did css end up being so absolutely crap at placing
elements on an html page?
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).
You can place elements, sure, I do not dispute that, but you've got
a choice between liquid design _or_ reasonable positioning.


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

Jul 20 '05 #8

P: n/a
On Wed, 09 Jul 2003 18:09:56 +0200, Lauri Raittila <"Lauri Raittila"
<la***@raittila.cjb.net>> wrote:
In article <be**********@ctb-nnrp2.saix.net>, Zak McGregor wrote:
[snip]

Right, I'm going to be flambed for this,


For reason.


Or not, possibly.
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 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.


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.
You can
place elements, sure, I do not dispute that, but you've got a choice
between liquid design _or_ reasonable positioning.


And with HTML you have? How?


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
================================================== ======================
Jul 20 '05 #9

P: n/a
On Wed, 09 Jul 2003 20:18:37 +0200, Brian <"Brian"
<br***@wfcr.org.invalid-remove-this-part>> wrote:
Zak McGregor wrote:

Right, I'm going to be flambed for this
No flames here. But I am going to correct you where I believe you are
wrong.


Fine, let's reason this out on that level :)
but IMHO css is unable to handle laying out something as simple as a
form.


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?


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.
Why on earth did css end up being so absolutely crap at placing
elements on an html page?


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).


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.
You can place elements, sure, I do not dispute that, but you've got a
choice between liquid design _or_ reasonable positioning.


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


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.
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.


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 "_absolutely_ crap".

Ciao

Zak

--
================================================== ======================
http://www.carfolio.com/ Searchable database of 10 000+ car specs
================================================== ======================
Jul 20 '05 #10

P: n/a
On Wed, 09 Jul 2003 20:09:24 +0200, Brian <"Brian"
<br***@wfcr.org.invalid-remove-this-part>> wrote:
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.
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.


Yup, looks great with Moz 1.3 here.
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?


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.
I have subsequently found this:
http://studioid.com/cgi-bin/links/jump.cgi?ID=444


which recommends using the <label> element.


OK I see that <label> can be styled, which I was mistaken in thinking it
was not supposed to have.
I'm not sure that the label tag is meant for this either, which may
explain some bugginess wrt the displaying of it.


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


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
================================================== ======================
Jul 20 '05 #11

P: n/a

"Zak McGregor" <za*@mighty.co.za> wrote in message
news:be**********@ctb-nnrp2.saix.net...
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?


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
Jul 20 '05 #12

P: n/a
Zak McGregor wrote:
On Wed, 09 Jul 2003 20:18:37 +0200, Brian <"Brian"
<br***@wfcr.org.invalid-remove-this-part>> wrote:
[snip] 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.


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]
You can place elements, sure, I do not dispute that, but you've got a
choice between liquid design _or_ reasonable positioning.


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


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.


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

Jul 20 '05 #13

P: n/a
Zak McGregor wrote:
On Wed, 09 Jul 2003 18:09:56 +0200, Lauri Raittila <"Lauri Raittila"
<la***@raittila.cjb.net>> wrote:

[snip]
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.


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.


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.

You can
place elements, sure, I do not dispute that, but you've got a choice
between liquid design _or_ reasonable positioning.


And with HTML you have? How?


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?


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

Jul 20 '05 #14

P: n/a


Brian wrote:
Zak McGregor wrote:
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

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.

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.


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.

Jul 20 '05 #15

P: n/a
On Thu, 10 Jul 2003 14:02:41 +0200, Jim Dabell <"Jim Dabell"
<ji********@jimdabell.com>> wrote:
Zak McGregor wrote:
On Wed, 09 Jul 2003 18:09:56 +0200, Lauri Raittila <"Lauri Raittila"
<la***@raittila.cjb.net>> wrote: [snip]
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.


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.


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.


Css tables? Apologies, but you've completely lost me now.
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.
Um I *never* use IE and don't even have a machine capable of running it.
This whole discussion is about the CSS spec's failing (IMHO) to deliver a
simple layout mechanism that does not depend on hard-coding some values to
achieve positioning. At least that's what I thought it was ;-)
You can
place elements, sure, I do not dispute that, but you've got a choice
between liquid design _or_ reasonable positioning.

And with HTML you have? How?


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?


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.


It's a table. I don't understand where the UA problem would stem from in
this instance. Tables for displaying data have been in the html spec for a
long time. A UA that doesn't understand a tag in any case should then
ignore the tag unless I misunderstand the spec.
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).


Well div or other non-table tags that are then coerced into a position via
css are also binding content to layout, not so?

Ciao

Zak

--
================================================== ======================
http://www.carfolio.com/ Searchable database of 10 000+ car specs
================================================== ======================
Jul 20 '05 #16

P: n/a
On Thu, 10 Jul 2003 13:37:14 +0200, Jim Dabell <"Jim Dabell"
<ji********@jimdabell.com>> wrote:
Zak McGregor wrote:
[snip]
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".

Unfortunately I can't see css being able to meet my simple set of
criteria. A fundamental need that tables-for-layout fixes quickly and
easily is that of 2 or 3 or more columns for content. That CSS seemingly
does not present a clean solution to this indicates to me a failure. That
CSS and seperation of layout from content and structurally efficient
documemts are all good things is indisputable. What is in dispute (IMHO
again) is whether or not CSS hits the mark. In my opinion our choices are
structurally compromised html documents or using CSS in a hit-and-hope
fashion.
[snip]
You can place elements, sure, I do not dispute that, but you've got a
choice between liquid design _or_ reasonable positioning.

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


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.


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


OK, it is clearly time for a test case.

Coming up.

Ciao

Zak

--
================================================== ======================
http://www.carfolio.com/ Searchable database of 10 000+ car specs
================================================== ======================
Jul 20 '05 #17

P: n/a
Zak McGregor wrote:
A fundamental need that tables-for-layout fixes quickly and
easily is that of 2 or 3 or more columns for content. That CSS seemingly
does not present a clean solution to this indicates to me a failure.


It indicates to me that you are keener to criticise than to check your
facts. CSS 2 has had this capability for over five years, and every
popular screen browser except for Internet Explorer has an implementation.

<URL:http://www.w3.org/TR/REC-CSS2/tables.html>
[snip]
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.


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


OK, it is clearly time for a test case.


Are you claiming that { width: 20%; } is a fixed width? I consider a fifth
of the parent element to be a variable width - you do not?

--
Jim Dabell

Jul 20 '05 #18

P: n/a
Zak McGregor wrote:
On Thu, 10 Jul 2003 14:02:41 +0200, Jim Dabell <"Jim Dabell"
<ji********@jimdabell.com>> wrote:
Zak McGregor wrote:
On Wed, 09 Jul 2003 18:09:56 +0200, Lauri Raittila <"Lauri Raittila"
<la***@raittila.cjb.net>> wrote:
[snip] 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.
Css tables? Apologies, but you've completely lost me now.


Laying out elements in a grid-like fashion, which you claim is impossible
with CSS:

<URL:http://www.w3.org/TR/REC-CSS2/tables.html>

Please, if you are going to call something "absolutely crap", how about
becoming familiar with it first?

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.


Um I *never* use IE and don't even have a machine capable of running it.
This whole discussion is about the CSS spec's failing (IMHO) to deliver a
simple layout mechanism that does not depend on hard-coding some values to
achieve positioning. At least that's what I thought it was ;-)


Lauri was pointing out that if it wasn't for Internet Explorer's lack of
support, you _could_ go ahead and use this part of CSS today. There is no
failing of the CSS 2 specification in this area. If floating and
positioning aren't suitable for you, then you can blame Microsoft entirely.
They are the ones with the mainstream browser who haven't implemented CSS 2
properly and refuse to do so for the next couple of years.
[snip]
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.


It's a table. I don't understand where the UA problem would stem from in
this instance.


HTML tables are meant to contain tabular data. A visual layout is not
tabular data. That's the basic problem.

Tables for displaying data have been in the html spec for a
long time.
Tables for _describing_ tabular data have been in the HTML specification for
a long time, yes. I'm not saying that you should avoid tables because UAs
don't understand them.

A UA that doesn't understand a tag in any case should then
ignore the tag unless I misunderstand the spec.


It's not about not understanding <table> elements, it's about rendering them
appropriately. The most appropriate rendering often is not, or cannot, be
what you want it to be. So, failing that, the UA has to interpret the
table for the user as it sees fit. This may well be different depending on
whether it's proper tabular data, or just a layout that somebody bodged
together. For instance, rotating a table to conserve horizontal space is
an option for tabular data, it often isn't for layout hacks.

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).


Well div or other non-table tags that are then coerced into a position via
css are also binding content to layout, not so?


Not so. Taking the <label> example, given:

<label for="username">Username:</label>
<input type="text" name="username" id="username" />
<label for="password">Password:</label>
<input type="password" name="password" id="password" />

Now, is this HTML arranged in a table-like layout, with the labels to the
left of the input fields? Or are the labels above the input fields? Or is
it some other layout entirely? You see, in different circumstances, the
different layouts are appropriate. If I want to conserve horizontal space,
I'll probably use the second layout, otherwise I'll use the first. I can
offer both options, or use different options for different media.

The CSS stylesheets _loosely_ couple content and presentation. Abusing HTML
tables _strongly_ couple them.

--
Jim Dabell

Jul 20 '05 #19

P: n/a
On Thu, 10 Jul 2003 15:54:32 +0200, Jim Dabell <"Jim Dabell"
<ji********@jimdabell.com>> wrote:
Zak McGregor wrote:
[snip]
Css tables? Apologies, but you've completely lost me now.


Laying out elements in a grid-like fashion, which you claim is
impossible with CSS:

<URL:http://www.w3.org/TR/REC-CSS2/tables.html>

Please, if you are going to call something "absolutely crap", how about
becoming familiar with it first?


I am familiar with css psuedo-table display directives, just didn't make a
connection to this discussion. I am also familiar with css. There is no
need to take a personal dig at me, after all I've only attacked the
current CSS (actually CSS2) spec. And that in the search for answers. I
don't appreciate this comment much Jim. If you feel this discussion too
far beneath you, please feel free to opt out but don't sit there flinging
faeces.

[snip]
Lauri was pointing out that if it wasn't for Internet Explorer's lack of
support, you _could_ go ahead and use this part of CSS today. There is
no failing of the CSS 2 specification in this area. If floating and
positioning aren't suitable for you, then you can blame Microsoft
entirely. They are the ones with the mainstream browser who haven't
implemented CSS 2 properly and refuse to do so for the next couple of
years.
Every time I blame Micorsoft I get labelled a "zealot". :) I'll happily
apportion blame to them if that's where it lies.

[snip]
HTML tables are meant to contain tabular data. A visual layout is not
tabular data. That's the basic problem.
I do grok that distinction. However, I don't see where the actual
difficulty in _this specific_ instance comes in. There is a (admittedly
weak) argument for using tables for forms in that a relationship between
the label and the widget exists. I do not rate this argument on the same
level as <td><img src="spacer.gif" width="220" height="15" alt=""></td>
type of tables-for-layout.
Tables for displaying data have been in the html spec for a long time.


Tables for _describing_ tabular data have been in the HTML specification
for a long time, yes. I'm not saying that you should avoid tables
because UAs don't understand them.


OK.

[snip]
Well div or other non-table tags that are then coerced into a position
via css are also binding content to layout, not so?


Not so. Taking the <label> example, given:

<label for="username">Username:</label> <input type="text"
name="username" id="username" /> <label for="password">Password:</label>
<input type="password" name="password" id="password" />

Now, is this HTML arranged in a table-like layout, with the labels to
the left of the input fields? Or are the labels above the input fields?
Or is it some other layout entirely? You see, in different
circumstances, the different layouts are appropriate. If I want to
conserve horizontal space, I'll probably use the second layout,
otherwise I'll use the first. I can offer both options, or use
different options for different media.


Sure, that is fine for certain instances (most instances, even). However,
for the specific application of a form from which sprang my original
query, there was/is a need for some degree of horizontal alignement over
rows of form markup.
The CSS stylesheets _loosely_ couple content and presentation. Abusing
HTML tables _strongly_ couple them.


I agree, I understand. However I do think that spewing forth table-less
html markup and then wrestling with CSS to achieve an _effect_ similar to
if one had tossed a little puritanism out the window and presented a form
in markup better suited to tabular data essentially _does_ achieve a
result very similar, both on a semantic/strucutral level as well as a
layout one.

Ciao

Zak

--
================================================== ======================
http://www.carfolio.com/ Searchable database of 10 000+ car specs
================================================== ======================
Jul 20 '05 #20

P: n/a
On Thu, 10 Jul 2003 15:39:25 +0200, Jim Dabell <"Jim Dabell"
<ji********@jimdabell.com>> wrote:
A fundamental need that tables-for-layout fixes quickly and easily is
that of 2 or 3 or more columns for content. That CSS seemingly does not
present a clean solution to this indicates to me a failure.


It indicates to me that you are keener to criticise than to check your
facts. CSS 2 has had this capability for over five years, and every
popular screen browser except for Internet Explorer has an
implementation.

<URL:http://www.w3.org/TR/REC-CSS2/tables.html>


Jim, as I have stated previously I _do_ know about css tabular display
properties.

[snip]
OK, it is clearly time for a test case.


Are you claiming that { width: 20%; } is a fixed width? I consider a
fifth of the parent element to be a variable width - you do not?


Do not put words into my mouth. I said it was clearly time for a test
case.

It seems that someone is very keen to attack the proponent, not the
argument.

Ciao

Zak

--
================================================== ======================
http://www.carfolio.com/ Searchable database of 10 000+ car specs
================================================== ======================
Jul 20 '05 #21

P: n/a
Le 10/07/2003 15:10, Zak McGregor a écrit :
OK, it is clearly time for a test case.


you can look at my form here :
http://www.chevrelbureau.com/formul.php

It's a hack using non breaking spaces, I did it about a year ago just to
see if I could find a way to replace my table layout, it's not really
elegant but it looks ok I think.

Petrsonnally, I agree with you that aligning form elements is difficult
in CSS, ig you have more than a field per line.

Pascal

--
FAQ Mozilla/Netscape 7 en français : http://pascal.chevrel.free.fr/
Drag me, drop me, treat me like an object

Jul 20 '05 #22

P: n/a
Zak McGregor wrote:
On Thu, 10 Jul 2003 15:54:32 +0200, Jim Dabell <"Jim Dabell"
<ji********@jimdabell.com>> wrote: [snip]
Please, if you are going to call something "absolutely crap", how about
becoming familiar with it first?


I am familiar with css psuedo-table display directives, just didn't make a
connection to this discussion. I am also familiar with css. There is no
need to take a personal dig at me, after all I've only attacked the
current CSS (actually CSS2) spec. And that in the search for answers. I
don't appreciate this comment much Jim. If you feel this discussion too
far beneath you, please feel free to opt out but don't sit there flinging
faeces.


Hey, I take no personal offense to people criticising the CSS 2
specification (I've done it myself), but having a go at it for omitting
something when it clearly does not, and then claiming to be familiar with
that feature is disingenuous. I don't consider "hey, check your facts
before mouthing off" comments to be flinging faeces, and this thread
offshoot started when you followed up your own posting just to vent.

[snip]
HTML tables are meant to contain tabular data. A visual layout is not
tabular data. That's the basic problem.


I do grok that distinction. However, I don't see where the actual
difficulty in _this specific_ instance comes in. There is a (admittedly
weak) argument for using tables for forms in that a relationship between
the label and the widget exists. I do not rate this argument on the same
level as <td><img src="spacer.gif" width="220" height="15" alt=""></td>
type of tables-for-layout.


I agree that forms are a grey area. I don't think this generalizes to all
non-nested tables though.
[snip]
The CSS stylesheets _loosely_ couple content and presentation. Abusing
HTML tables _strongly_ couple them.


I agree, I understand. However I do think that spewing forth table-less
html markup and then wrestling with CSS to achieve an _effect_ similar to
if one had tossed a little puritanism out the window and presented a form
in markup better suited to tabular data essentially _does_ achieve a
result very similar, both on a semantic/strucutral level as well as a
layout one.


In the context of forms, yes, I agree. In the context of table layouts in
general (even simple, non-nested ones), I disagree. There just doesn't
seem to be any need to do things this way any more.

The two main justifications I hear for table layouts are that it's simpler,
and it works the same on all browsers. I don't think either are true; this
doesn't make table layout evil, but it does make you question the utility
of them now that partial CSS 2 is mainstream.

--
Jim Dabell

Jul 20 '05 #23

P: n/a
Zak McGregor wrote:
On Thu, 10 Jul 2003 15:39:25 +0200, Jim Dabell <"Jim Dabell"
<ji********@jimdabell.com>> wrote:
Zak McGregor wrote:
OK, it is clearly time for a test case.


Are you claiming that { width: 20%; } is a fixed width? I consider a
fifth of the parent element to be a variable width - you do not?


Do not put words into my mouth. I said it was clearly time for a test
case.


I was trying to clarify what you said here, not to put words in your mouth.
It seemed to me that you were disagreeing, it's hard to know what you meant
when you said that.

--
Jim Dabell

Jul 20 '05 #24

P: n/a
Simon Andrews wrote:
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.


Err, doesn't work here. The labels on the form aren't visible. This is
using Netscape 7.0 Win2K.


N7? Really? Not N6? I tested it on N6/Mac, and the labels were not
visible. It does not seem to handle floats very well. I've read that
N6 was based on 0.x Mozilla, and not quite ready for release. AFAIK,
here is nothing I can do to work around that.

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

Jul 20 '05 #25

P: n/a
Zak McGregor wrote:

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?


This seems like a losing battle [1], but ok. Divs are a generic block
level element. Gathering information which is related into a div
helps organize it. Using css to suggest a different presentation for
that div is a good idea. It's hard to think of how even overusing div
where it is not necessary will cause problems.

Tables are another matter. They are for tabular data. Using them for
layout is a misuse of the element. It prevents users from presenting
a document in a manner that suits them better. Two hypothetical examples:

1. There's a paper published on the web about using wind energy for
electricity generation. An engineering student wants to print a copy
out while she makes her coffee. She plans on reading it on the bus
into school. She doesn't need the tables of data in the paper; she'll
reread the paper on a computer in the lab, with the tables, where she
can verify the data with equipment. Thus, she turns on her user
stylesheet with the rule table {display: none}. If the document used
tables as they were meant to be used, she'd be in luck. Alas, no!
The author used a table -- simple, unnested, mind you -- for layout,
so the page went blank when she turned on her stylesheet.

2. A physicist also uses the web to read papers. She finds that too
many of her colleagues publish tables in their papers with no borders
at all. This makes the tables hard for her to read. Not to worry,
she can create a user stylesheet with the rule TD {border: thin solid
green}. It works great, except that the author of the web documents
used table layout -- again, simple, unnested -- and now there are
green boxes all over the place.

Let the web be the web. Stop trying to make it into print media,
which is what I think you want based on your complaints about css and
column layout.
[1] I get the feeling that the bar will be raised shorty after I post
this.

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

Jul 20 '05 #26

P: n/a
Els

"Jonathan Snook" <go***************@snook.ca> schreef in bericht
news:u5********************@news01.bloor.is.net.ca ble.rogers.com...

"Zak McGregor" <za*@mighty.co.za> wrote in message
news:be**********@ctb-nnrp2.saix.net...
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?
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).


Dear Jonathan:
please take a look at the site I made for a friend photographer, I did
use tables on all pages, and I think it's the only way to make the
site look the way it does. I also think that the average person does
care about this, as it is nice to see pictures in a nice frame.
(compare: in the museum the paintings are all framed and at certain
distances from each other. It enhances the pleasure of looking at
them.)

But, if you can show me a better way of displaying this site without
tables, please say so.

Sincerely,
Els
(the site's url: http://www.rachelrijsdijk.com/)
Jul 20 '05 #27

P: n/a


Brian wrote:
Simon Andrews wrote:
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.

Err, doesn't work here. The labels on the form aren't visible. This
is using Netscape 7.0 Win2K.

N7? Really? Not N6? I tested it on N6/Mac, and the labels were not
visible. It does not seem to handle floats very well. I've read that
N6 was based on 0.x Mozilla, and not quite ready for release. AFAIK,
here is nothing I can do to work around that.


Yes really. To quote:

Netscape 7.0
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
Netscape/7.0

Microsoft Windows 2000 5.00.2195 Service Pack 3

Jul 20 '05 #28

P: n/a
In article <be**********@ctb-nnrp2.saix.net>, Zak McGregor wrote:
On Fri, 11 Jul 2003 04:47:52 +0200, Brian <"Brian"
<br***@wfcr.org.invalid-remove-this-part>> wrote:
Let the web be the web. Stop trying to make it into print media, which
is what I think you want based on your complaints about css and column
layout.


Not at all. I am tired of people assuming a whole bucketload of things
about me based on 2 things: my description of CSS for positioning elements
on an html page as "absolutely crap", and my stubborn refusal to merely
buy into the "all tables for layout is baaaaaaaa-d. Baaaaa-d".


Why? Those are only things we know about you.
I do see where my approach (for point #2) is weak or lacking - I never
claimed it to be a perfect position, but I really felt (still do,
actually) that I have a point.
That's true. Could you please tell us why some layout is better done in
tables than with CSS? I can tell that I haven't been able to figure out
one, that don't involve browser support.
Your examples frankly didn't do the trick for me,
Propably because you think it is not practical to change userstylesheet
to accommodate page? Or if that is not true, because?
It will take 15 second for me to change userstylesheet and apply it.
alt + s c r
bar {foo:0}
alt + f s
alt + s r
I do that all the time

You see, I had to assume why they didn't do the trick, as you didn't say.
Plese don't come and say "Don't put words in my mouth", but tell _why_
you think what you say.
but I am
now tired of not only defending my positions but also fighting
misperceptions arising from assumptions like these made about my approach
to web
Assumptions arise because you don't say your reasons. I think we all are
wrong. Maybe you just don't have any reason. Reasons are for those that
don't know?
Based on? FFS, what did I do to deserve that assumption? *shakes head*


Happenend about always when those reasons have been said. Do you know how
many times this argument is happenend in this group? It is certainly not
first time someone says "I may be flamed, but I think CSS is useless".
The common detonator is that people don't seem to be able to say they are
wrong.

And BTW, If I was in situations like the person in Brians examples, I
would use that CSS. I alreaady ignore all widths assigned to tables which
hardly ever breaks anything but look of page (the looks can break pretty
ugly though).

--
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.

Jul 20 '05 #29

P: n/a
Zak McGregor wrote:

Not at all. I am tired of people assuming a whole bucketload of
things about me based on 2 things: my description of CSS for
positioning elements on an html page as "absolutely crap", and my
stubborn refusal to merely buy into the "all tables for layout is
baaaaaaaa-d. Baaaaa-d".
A cartoonish dismissal of my argument, in I showed two cases where
using table for layout decreases accessibility. And that's what you
had asked. Here's your question again, just to be thorough:

<quote from news:be**********@ctb-nnrp2.saix.net> 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? </quote>
I do see where my approach (for point #2) is weak or lacking - I
never claimed it to be a perfect position, but I really felt (still
do, actually) that I have a point.
That using a simple table for layout is preferable to css? How is it
preferable?
Your examples frankly didn't do the trick for me,
A less-than-convincing argument. *Why* didn't it do the trick. What
are you looking for? Why did you clip both the examples I gave? That
was the meat of my message, not the post-script about the web as web
and not as print.

In this thread, you've made a couple of erroneous statements about the
languages used for web authoring, so it's hard to take you very
seriously when you complain about the shortcomings of those languages.
but I am now tired of not only defending my positions but also
fighting misperceptions arising from assumptions like these made
about my approach to web and related issues based solely on my
unwillingness to back down


poor thing. You're not defending your position, but hurling
invective. Don't act suprised at the reaction.

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

Jul 20 '05 #30

P: n/a
Simon Andrews wrote:
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.

Err, doesn't work here. The labels on the form aren't visible. This
is using Netscape 7.0 Win2K.


N7? Really?


Yes really. To quote:

Netscape 7.0
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
Netscape/7.0

Microsoft Windows 2000 5.00.2195 Service Pack 3


<whine> waaaaaaaaaaaaaaaaaaaaaa! </whine> I apparently tested only on
N7/Mac, and got mixed up. Shoot. I'm stuck now. I've already handed
this off to the client to maintain. I'll have to try out something
else for that form, I suppose.

Thanks much for the heads up.

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

Jul 20 '05 #31

P: n/a
Brian wrote:

<disclaimer>
I recently handed control of the site to the client. She just informed
me that she put in code to open external links in a new window.
Argghh! Time for a little usability lesson.
</disclaimer>


Success is mine! She has removed the offending (and offensive!) code.
If only all clients were so willing to listen.

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

Jul 20 '05 #32

P: n/a
Els

"Nikolaos Giannopoulos" <ni******@solmar.ca> schreef in bericht
news:G1********************@magma.ca...
Els wrote: - snip! -
(the site's url: http://www.rachelrijsdijk.com/)


Okay - for starters - what's up with:

(1) The splash screen - is it necessary? In one word: NO!

(2) No wording on the splash screen - oh hum, yup click on the

portrait? Very user friendly I imagine.

(3) This junk about popping up a new window when I click on the splash. Do you know what this does in Mozilla? It breaks out a new window
when I keep my windows in tabs and most of all ticks me off! Is this necessary - no but for some reason you seem to think so.

(4) What do you think the resizing of the window to max and not making it available to be resized does on a dual head monitor? Yup half your portraits are on one side of my screen and the other half are on the
other. Absolute junk is what I think!!!! The photos are nice but no point in looking beyond the first one.

(5) Please don't offer this site as anything to model on - even if it is only the tables that you are talking about.

Converting this site from table layout to CSS is the least of your
worries. And yes, it can be done but you need to stop using bells and whistles and put real "creativity" into a site first - "NOT" technical junk that you borrowed from elsewhere that adds ZERO value to the site (actually that's not true it adds NEGATIVE value which is not zero).


Hi Nikolaos (and others)

I have taken all of the above into a new version, would you be so kind
as to check it out?
The url is http://www.mediatech.nl/~rachel/Fram...hel/index.html
only a testversion so far, the only links that work, are from the
menu: 'home', 'music', and 'live pictures'. One pic is missing on
purpose; I wanted to test the alt attribute.

I've tested it in IE6, NN7, Opera7 and MozillaFirebird0.6.1, but I
don't have a dual head monitor to see what happens there.

Please give your opinion?

And if anyone could test it for me in Safari, I'd be greatful!

Thanks,
Els
Jul 20 '05 #33

P: n/a
In article <bg**********@reader1.tiscali.nl>,
el*********@PLEASEtiscali.nl says...
.... I have taken all of the above into a new version, would you be so kind
as to check it out? The url is http://www.mediatech.nl/~rachel/Fram...hel/index.html

....
I get a vertical scrollbar in IE6 & Mozilla 1.5b 1024/768 at all text
sizes.
Jul 20 '05 #34

P: n/a
Els

"Jacqui or (maybe) Pete" schreef:
In article <bg**********@reader1.tiscali.nl>,
Els says...
...
I have taken all of the above into a new version, would you be so kind as to check it out?

The url is http://www.mediatech.nl/~rachel/Fram...hel/index.html

...
I get a vertical scrollbar in IE6 & Mozilla 1.5b 1024/768 at all

text sizes.


Aren't you talking about the horizontal scrollbar?
I got rid of it now. (by making the black border a bit narrower)
(To get rid of the vertical one, press F11)
That is, at regular text size.
But I kinda like the artistic view after pressing Ctrl+ 7 times in
Mozilla and Netscape ;-))

Thanks for reminding me to check in 1024/768 after each change I make.
- and I now found out that in Opera they don't just enlarge the font,
but the complete page! -

Sincerely,
Els


Jul 20 '05 #35

P: n/a

Good afternoon Els,
It was foretold that on 1-8-2003 @ 10:46:03 GMT+0200 (which was
10:46:03 where I live) Els would mumble:

<snipped a bit>

E> I have taken all of the above into a new version, would you be so kind
E> as to check it out?
E> The url is http://www.mediatech.nl/~rachel/Fram...hel/index.html
E> Please give your opinion?

IE6, Opera 7.11 and Moz 4.1 on 800x600: i still get get a horizontal
scrollbar, no matter how many times i refresh :-(

Best regards,
lukie

--------------------------------------------
Powered by The Bat! version 1.63 Beta/7 with Windows 2000 (build
2195), version 5.0 Service Pack 3 and using the best browser: Opera.

"Don't worry about the world ending today . . . It's already tomorrow
in Australia."
--------------------------------------------
__________________________________________________ ______________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)
Jul 20 '05 #36

P: n/a
Els

"lukie" <lu******@yahoo.co.uk> schreef in bericht
news:11***********************@yahoo.co.uk...

Good afternoon Els,
It was foretold that on 1-8-2003 @ 10:46:03 GMT+0200 (which was
10:46:03 where I live) Els would mumble:

<snipped a bit>

E> I have taken all of the above into a new version, would you be so kind E> as to check it out?
E> The url is http://www.mediatech.nl/~rachel/Fram...hel/index.html
E> Please give your opinion?

IE6, Opera 7.11 and Moz 4.1 on 800x600: i still get a horizontal
scrollbar, no matter how many times i refresh :-(


Yes, that's intentionally. Because where you see the collection of
pics now, will be the showing of bigger pics later. If I would let the
page get narrower as the user's screen does, these pics would either
not be entirely visible, or mess up the layout all together.
The way it is now, you can (coming to the big pics) scroll the page so
that an 800x600 screen is showing exactly the pic and info.

Me desculpe ... ;-)

It shouldn't however have a horizontal scrollbar on any browser on a
1024x768 screen or bigger.

Sincerely,
Els
Jul 20 '05 #37

P: n/a

Good afternoon Els,
It was foretold that on 1-8-2003 @ 16:14:08 GMT+0200 (which was
16:14:08 where I live) Els would mumble:

<snipped a bit>

E> The way it is now, you can (coming to the big pics) scroll the page so
E> that an 800x600 screen is showing exactly the pic and info.

The way it is now?

E> Me desculpe ... ;-)

De nada :-)

E> It shouldn't however have a horizontal scrollbar on any browser on a
E> 1024x768 screen or bigger.

That is affirmative (as in 'no scroll')

Best regards,
lukie

--------------------------------------------
Powered by The Bat! version 1.63 Beta/7 with Windows 2000 (build
2195), version 5.0 Service Pack 3 and using the best browser: Opera.

"The motor-car will help solve the congestion of traffic." - A. J.
Balfour, c.1910.
--------------------------------------------
__________________________________________________ ______________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)
Jul 20 '05 #38

P: n/a
Els

"lukie" <lu******@yahoo.co.uk> schreef in bericht
news:31**********************@yahoo.co.uk...

Good afternoon Els,
It was foretold that on 1-8-2003 @ 16:14:08 GMT+0200 (which was
16:14:08 where I live) Els would mumble:

<snipped a bit>

E> The way it is now, you can (coming to the big pics) scroll the page so E> that an 800x600 screen is showing exactly the pic and info.

The way it is now?


Yes, if you don't mind a (requested) pop window that takes up your
entire screen just for this once, you could check out
www.rachelrijsdijk.com. That's the 'old' version of the site, using a
bunch of frames with an inlineframe, no doctype, no charset, and not
enough css ;-).
Just click on the face, and click on any thumbnail until you get the
bigger pics...

It is better though with a 1024x768 screen, I'll be the first to admit
that.

(ik heb die keuze gemaakt ten gunste van de fixed lay-out - zeg dat
nooit hardop: "fixed lay-out" ;-)

Sincerely,
Els

Jul 20 '05 #39

P: n/a

Good afternoon Els,
It was foretold that on 1-8-2003 @ 16:47:17 GMT+0200 (which was
16:47:17 where I live) Els would mumble:

<snipped a bit>

E> Yes, if you don't mind a (requested) pop window that takes up your
E> entire screen just for this once, you could check out
E> www.rachelrijsdijk.com.

Ah yes (eigenlijk had ik die al gevonden: een search op rachel
rijsdijk bracht me op die oude site :-))

Best regards,
lukie

--------------------------------------------
Powered by The Bat! version 1.63 Beta/7 with Windows 2000 (build
2195), version 5.0 Service Pack 3 and using the best browser: Opera.

"To many, no doubt, he will seem blatant and bumptious, but we prefer
to regard him as being simply British." - Oscar Wilde (1854-1900) -
Irish novelist, playwright and wit
--------------------------------------------
__________________________________________________ ______________________
Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)
Jul 20 '05 #40

This discussion thread is closed

Replies have been disabled for this discussion.