tables are evil

[Magnus Warker]

Hi,

what would be a CSS substitute for this?

<table width='100%'>
<tr>
<td>Attribute</td>
<td align='right'>Value</td>
</tr>
</table>

Magnus

[Philip Herlihy]

In article <k5mpfc$jlg$1...@news.m-online.net>, mag...@mailinator.com
says...

Use a definition list (which is an HTML alternative) and style it how
you like. Lots of interesting articles on the web.

--

Phil, London

[Jukka K. Korpela]

2012-10-17 20:24, Magnus Warker wrote:

> what would be a CSS substitute for this?

I'm sure you can set up a jungle of <div> tags and throw in display:
table, display: table-row etc., sit back and wait for five to ten years
to see non-supporting browsers fade away.

> <table width='100%'>
> <tr>
> <td>Attribute</td>
> <td align='right'>Value</td>
> </tr>
> </table>

This looks like an artificially crippled form of a table of data. If you
have been indoctrinated into thinking that tables are evil, there is
little hope, though. People don't just abandon absurd religious beliefs;
but they may trade them for some more tempting beliefs of another religion.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Jukka K. Korpela]

2012-10-17 20:53, Philip Herlihy wrote:

> Use a definition list (which is an HTML alternative)

Exactly how is using <dl>, definition list, which misrepresents the data
(this is not about defining the term "Attribute") an improvement over
using <table>?


--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Cezary Tomczyk]

W dniu 2012-10-17 19:24, Magnus Warker pisze:

Why you need to create some "substitute" for this? If data semantically
match to tables then just use tables. The only one thing I would change
to this:

<table>
<caption>This is my data</caption>
<thead>
<tr>
<th>Attribute</th>
<th>Value</th>
</tr>
</thead>
<tbody>
<tr>
<td>My attribute</td>
<td>My value</td>
</tr>
</tbody>
</table>

--
Cezary Tomczyk
http://www.ctomczyk.pl/

[Danny]

Could be done with a DL/DT combination, or with just Divs, thus far is rather very ambiguous as we don't have any context to pin to it. Why don't you just give us a mock up of what you want, just make a quick pic/screenshot of it, so we can suggest better :)

[Gus Richter]

A CSS substitute meaning a non-table version using some CSS and here is
one way:

<style>
#left {float:left;width:50%;}
#right{float:right;}
</style>

<h1>Table version</h1>

<table width='100%'>
<tr>
<td>Attribute</td>
<td align='right'>Value</td>
</tr>
</table>

<h1>Non-Table version</h1>
<div id="left">Attribute</div><div id="right">Value</div>

--
Gus

[dorayme]

In article <k5mpfc$jlg$1...@news.m-online.net>,

HTML and CSS are different things. One can no more substitute one for
the other than one can substitute a smile for a mouth, the smile is a
way a mouth can be. CSS is a powerful way to style HTML.

So, one possible unobjectionable meaning to your question is how do
you style a table without HTML attributes. You would get an equivalent
with something like:

<table>
<tr>
<td>Attribute</td>
<td class="value">Value</td>
</tr>
</table>

table {width: 100%;}
.value {text-align: right;}

--
dorayme

[Gus Richter]

If you mean to use the CSS "display" property to display elements as
tables, rows, and cells, then:

<style>
#displaywrapper {display:table;width:100%;}
#leftdiv,#rightdiv {display:table-cell;}
h1 {display:table-row;width:100%;background:orange;}
.notes {padding-top:50px;}

</style>

<h1>Table version:</h1>
<table width='100%'>
<tr>
<td>Attribute</td>
<td align='right'>Value</td>
</tr>
</table>

<div id="displaywrapper">
<h1>Version using CSS "display" property with values of table,
table-row, and table-cell:</h1>
<div id="leftdiv">Attribute</div><div id="rightdiv">Value</div>
</div>

<div class="notes">
Browser Support:<br>
<a href="http://caniuse.com/#feat=css-table">caniuse.com</a>
</div>

--
Gus

[Philip Herlihy]

In article <k5mrt9$em3$1...@dont-email.me>, jkor...@cs.tut.fi says...

>
> 2012-10-17 20:53, Philip Herlihy wrote:
>
> > Use a definition list (which is an HTML alternative)
>
> Exactly how is using <dl>, definition list, which misrepresents the data
> (this is not about defining the term "Attribute") an improvement over
> using <table>?

OP asked for a 'substitute'. Do you believe site visitors will be
misled by the use of a DL in this context? Personally, I've no problem
with the use of a table here, although a DL has less potential for
complexity for this particular structure.

Perhaps it should be called an "associative list"...

We had a discussion here some weeks back in which I was castigated
(kindly) for putting a single word in a <P>, just to pick up the
conventional layout provided by browser stylesheets. Folk here took
sides on how respectable it was to deviate from the founding fathers'
conception of what HTML denoted, and I tend towards the pragmatic rather
than the purist. To me, <P> just means a chunk of text clearly
distinguished from from the next similar chunk. Similarly, a DL is just
a list where the bullets can be whatever you like, and it suits this
application if you don't get hung up on the word "Definition". If a
page doesn't make sense, no amount of exactitude over the tags used will
save it. And if it does make sense, the tags hardly matter. True, we
should consider user agents which might be radically different from a
conventional browser, and so I wouldn't stray grossly from the original
conception of a tag. But that battle was lost a decade ago (look at the
code generated by FrontPage). If you need structured data, you need
something like XML, and you need your own definition of the terms.

Lets not go back over all that. So much HTML is hideously written that
fussing over the top 10% isn't going to achieve much.

--

Phil, London

[Philip Herlihy]

In article <k5mrt9$em3$1...@dont-email.me>, jkor...@cs.tut.fi says...
>

> 2012-10-17 20:53, Philip Herlihy wrote:
>
> > Use a definition list (which is an HTML alternative)
>
> Exactly how is using <dl>, definition list, which misrepresents the data
> (this is not about defining the term "Attribute") an improvement over
> using <table>?

(This doesn't seem to have made it to the thread after several hours, so
I'm re-posting it.)

[tlvp]

On Wed, 17 Oct 2012 21:03:23 +0300, Jukka K. Korpela wrote:

> 2012-10-17 20:53, Philip Herlihy wrote:
>
>> Use a definition list (which is an HTML alternative)
>
> Exactly how is using <dl>, definition list, which misrepresents the data
> (this is not about defining the term "Attribute") an improvement over
> using <table>?

Why is it *not* a (short) list of (just one) definition(s)? Agreed, it's
not 'about defining the term "Attribute"' -- it's about defining Attribute
as Value -- we do that all the time -- I have a jpg graphic, for example,
and I define its width to be 480px and its height to be 640px, for example
-- every relevant attribute (alt, title, src, what-have-you) for that IMG I
define -- provide -- with a suitable value. N'est-ce pas?

Or am I using this language too flexibly for your taste :-) ?

Myself, of course, I'd use the table approach, for the greater layout
flexibility it affords me; but I could easily defend the DL approach (and,
in fact, just did :-) ).

Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[Jukka K. Korpela]

2012-10-18 19:02, tlvp wrote:

> On Wed, 17 Oct 2012 21:03:23 +0300, Jukka K. Korpela wrote:
>
>> 2012-10-17 20:53, Philip Herlihy wrote:
>>
>>> Use a definition list (which is an HTML alternative)
>>
>> Exactly how is using <dl>, definition list, which misrepresents the data
>> (this is not about defining the term "Attribute") an improvement over
>> using <table>?
>
> Why is it *not* a (short) list of (just one) definition(s)? Agreed, it's
> not 'about defining the term "Attribute"'

Exactly. That's why <dl> is not an improvement over <table>. The implied
(in the Subject line) idea is that tables should not be used because
they are not "semantically right" - at least this is a common argument
against tables. Now, a table is just a structure, an array, and says
nothing about any meaning, i.e. semantics. The <dl> element, on the
other hand, is semantic, too, as per HTML 4.01, and the semantics is
just *wrong* here.

> -- it's about defining Attribute
> as Value -- we do that all the time -- I have a jpg graphic, for example,
> and I define its width to be 480px and its height to be 640px, for example

No, you set the width and the height. Defining the terms "width" and
"height" would be something completely different.

In HTML5, and elsewhere, there is a strong tendency to redefine <dl> as
a list of value/name pairs, or just a list of pairs. Logically, that's a
table with two columns only. But it is less flexible. You now have
attributes and values - what would you do if you wanted to add comments
for them? It's easy to add a column to a table.

But most importantly, <dl> are not an alternative to <table> if we think
that "tables are evil" because they are "not semantic" or because they
are "for layout only". In that ideology, if it is applied in any logical
manner, <dl> should be evil, too. Maybe more evil.

In fact, using
<div class=table><div class=tr><span class=td>Attribute</span>
<span class=td>Value</span></div>
</div>
would be a more *logical* approach if you think that "tables are evil".
If your elements lack any defined semantics, you cannot be semantically
*wrong*.

> Myself, of course, I'd use the table approach, for the greater layout
> flexibility it affords me; but I could easily defend the DL approach (and,
> in fact, just did :-) ).

From the styling perspective, there is one reason to favor <dl> over
<table> in some cases, but it has nothing to do with "tables are evil".

According to pragmatic HTML authoring principles,
http://www.cs.tut.fi/~jkorpela/pragmatic-html.html8
we should select markup so that the default rendering is acceptable, or
at least the least of evils. This tends to imply ease of styling. So if
the default rendering should be anything table-like, use <table>.

Now, the default rendering of <dl> tends to show <dt> items on the left
and <dd> items nested, as in

foobar
some text here

zipzap
some other text here

If this looks good as default rendering, or at least better than tabular
rendering, use it. It's mostly suitable for glossaries and things like
that (which are more or less definition lists!) but also e.g. for a list
of products with some info about each product.

In principle, you can render a <table> that way, and you can render a
<dl> in a tabular manner, using CSS. In practice, this is still to a
considerable degree just theory, since bad old IE versions don't let you
do that: they render a <table> in tabular manner, and that's it.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[tlvp]

On Thu, 18 Oct 2012 23:11:09 +0300, Jukka K. Korpela wrote:

>
> Exactly. That's why <dl> is not an improvement over <table>. ...

No, of course not. As I see it, <table> is the HTML counterpart of
the mathematical construct "rectangular matrix"; and, with that as guiding
light, <DL> and two-column table,each being counterpart of 2-column matrix,
are largely interchangeable from my perspective.

As for ...

> ... The implied

> (in the Subject line) idea is that tables should not be used because

> they are not "semantically right" - at least this is a common argument ...

I thought the Subject: line: was just there as an attention grabber, and
the message itself had little if anything to do with it -- a non-sequitur
in reverse, if you will :-) -- so I paid it little (if any) mind.

> ... against tables. Now, a table is just a structure, an array, and says

> nothing about any meaning, i.e. semantics. The <dl> element, on the
> other hand, is semantic, too, as per HTML 4.01, and the semantics is
> just *wrong* here.
>
>> -- it's about defining Attribute
>> as Value -- we do that all the time -- I have a jpg graphic, for example,
>> and I define its width to be 480px and its height to be 640px, for example
>
> No, you set the width and the height. Defining the terms "width" and
> "height" would be something completely different.

You mean, it's wrong to think "define this attribute (on this occasion) to
have that value"? I'll have to mull over whether that accords with my
understanding of mathematical variables and their instantiation,
specialization, and evaluation.

Anyway, I'm not pushing for converts, or proseletyzing, so for now I'll
just stop here :-) .

Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

>

[BootNic]

In article <k5mpfc$jlg$1...@news.m-online.net>,
Magnus Warker <mag...@mailinator.com> wrote:

<style type="text/css">

div[data-left],
div[data-right] {
min-width: 30em;
}
div[data-left]:before {
content: attr(data-left);
}
div[data-left]:before,
div[data-right]:after {
border: rgb(255, 0, 0) solid 1px;
box-sizing: border-box;
display: inline-block;
width: 50%;
}
div[data-right]:after {
content: attr(data-right);
text-align: right;
}

</style>

<div data-left="Attribute" data-right="Value"></div>


--
BootNic Fri Oct 19, 2012 02:04 pm
A conclusion is the place where you get tired of thinking.
*Arthur Bloch*

[Gus Richter]

As of today; FF 16.01, 17 or 18 Gecko doesn't yet have a non-prefixed
implementation. You must have tested it only in the other 4 of the 5 big
browsers. So, to include all 5 browsers, you must have:

-moz-box-sizing: border-box;
box-sizing: border-box;

<http://caniuse.com/#search=box-sizing>

--
Gus

[BootNic]

In article <k5sqad$1oq$1...@dont-email.me>,

Gus Richter <gusri...@netscape.net> wrote:

> On 10/19/2012 2:04 PM, BootNic wrote:

[snip]

>> div[data-left]:before,
>> div[data-right]:after {
>> border: rgb(255, 0, 0) solid 1px;
>> box-sizing: border-box;
>> display: inline-block;
>> width: 50%;
>> }

[snip]

> As of today; FF 16.01, 17 or 18 Gecko doesn't yet have a
> non-prefixed implementation. You must have tested it only in the
> other 4 of the 5 big browsers. So, to include all 5 browsers, you
> must have:

> -moz-box-sizing: border-box;
> box-sizing: border-box;

> <http://caniuse.com/#search=box-sizing>

It does appear that firefox still needs the prefix. I would not have know if
you did not point it out, as my firefox displayed it as intended.

Totally my error and spotty memory. Thanks to a little project I started and
never finished, as of yet, my server added the webkit and moz prefixes for me.


--
BootNic Fri Oct 19, 2012 11:54 pm
The only thing that saves us from the bureaucracy is inefficiency. An
efficient bureaucracy is the greatest threat to liberty.
*Eugene McCarthy*

[Swifty]

On 18/10/2012 11:44, Philip Herlihy wrote:
> Perhaps it should be called an "associative list"...

The original table had Attributes in column 1 and Values in column 2.
Sure, you could display this with a <DL>, but then imagine the plight of
a blind person, using a screen reader when faced with the statement:

"The definition of 'difficulty' is 'moderate'"

I'm also a pragmatist in most cases (and am roundly castigated), but I
shy away from inappropriate use of DL.

--
Steve Swift
http://www.swiftys.org.uk/

[Philip Herlihy]

In article <k682ch$f2p$1...@speranza.aioe.org>, steve....@gmail.com
says...

Is that what actually happens, or is this a "thought experiment"? I've
never experienced a screen reader (can you download them easily?) and I
wonder if you're speaking from experience - it would be good to know.

I certainly buy the proposition that it would benefit screen readers to
include ALT text, and to put navigation code at the end of HTML (using
CSS to place it conveniently on the page for conventional browsers) but
I'd be surprised to hear it confirmed that they would render code
audibly as you suggest. I'd imagine that many screen readers would be
reduced to gibbering nonsense by a lot of web pages out there. Do they
really interpret HTML tags semantically? Can anyone with experience of
these readers clarify this?

What does Ebay sound like?

I've tracked down this screen-reader:
http://www.nvda-project.org/

.. via the RNIB website:
http://www.rnib.org.uk/

This is interesting:
http://www.rnib.org.uk/professionals/webaccessibility/
designbuild/structure/Pages/page_structure.aspx

(http://bit.ly/XflLKO)

As are these:
http://www.w3.org/TR/WCAG10-TECHS/ (root document)

http://www.w3.org/TR/WCAG10-HTML-TECHS/ (on HTML)

I quote from Section 4 of the above:
"The HTML list elements DL, UL, and OL should only be used to create
lists, not for formatting effects such as indentation."
But what is and is not a list? Navigation bars are often coded as
undordered lists, but is that a stretch? On reflection, I'd argue that
HTML tags are simply structural patterns inviting flexible use, and that
a DL is simply a structure which provides an association between pairs
of arbitrary child elements and which might, for example, lend itself to
a list of definitions - but use your creativity if you have any! Here's
a discussion from someone with plenty of that:
http://www.maxdesign.com.au/articles/definition/

Personally, I've found myself gravitating to a view which distinguishes
three independent considerations: structure, formatting, and semantics.
Structure is the domain of HTML, but I see it (YMMV) as rightly
semantic-free. Formatting/presentation is provided independently by
CSS. Semantics is in your content. Of course, you can disrupt
intelligibility with ill-chosen structure (every third word an H1?) or
formatting (black text on a black background?) but my own view is that
fretting about whether something is *allowed* to be a DL is pointless.
The test should be whether your use of those three elements of design
combine to make your overall meaning intelligible to users of the user
agents you target.

If your goal is accessibility to "unconventional" user agents, it's not
as easy as I'd thought to get it right using tables. If you look at
section 5 of the HTML guidelines (above), which talks about
"linearising" you might get a fright! The whole of section 5 is good
reading.

I must say that what I've just found has opened my eyes to this whole
subject, and it's not something to be mastered quickly, I think. We've
been skirmishing in "religious wars" about the primacy of the original
semantic purpose of tags, but if we're serious about making pages
accessible there are some equally serious and hard questions:

Is it worth the considerable effort? How many visually-impaired people
try to use screen-readers? For which types of site? If few, is this
because we're not doing enough to help them? Meanwhile, if few other
designers are really committed to fully-accessible code, is there any
point in my doing this? Must I insist my customers pay for the extra
effort or should the extra time be on my own account? Should we be
gravitating towards development tools which make adjustments for us?

This is a much harder subject than I'd appreciated.

--

Phil, London

[Philip Herlihy]

In article <MPG.2af212bd6...@news.demon.co.uk>,
bounc...@you.com says...

>
> In article <k682ch$f2p$1...@speranza.aioe.org>, steve....@gmail.com
> says...
> >
> > On 18/10/2012 11:44, Philip Herlihy wrote:
> > > Perhaps it should be called an "associative list"...
> >

Just spotted this article which argues that a DL is semantically
stronger for the sort of use originally sought:

http://css-tricks.com/
utilizing-the-underused-but-semantically-awesome-definition-list/

(http://bit.ly/5jiHdb)

So it's not just me!

--

Phil, London

[Jukka K. Korpela]

2012-10-24 17:59, Philip Herlihy wrote:

> In article <k682ch$f2p$1...@speranza.aioe.org>, steve....@gmail.com
> says...

[...]

>> Sure, you could display this with a <DL>, but then imagine the plight of
>> a blind person, using a screen reader when faced with the statement:
>> "The definition of 'difficulty' is 'moderate'"

[...]

> Is that what actually happens, or is this a "thought experiment"?

As far as I know, it is speculation on what could happen. I have
presented such speculations myself, usually trying to be clear about
their hypothetical nature.

But speculations can be turned to reality. Some time ago, I wrote a
"semantic style sheet", intended to express the semantics of HTML
elements as defined in specifications, and little else. Demo:
http://www.cs.tut.fi/~jkorpela/styles/semantic-test.html
The style sheet uses generated content to add a symbol for "is by
definition equal to", but generated content could easilybe used to turn
<dt>difficulty<dd>moderate to "The definition of 'difficulty' is 'moderate'"

> Do they [screen readers]

> really interpret HTML tags semantically?

Not really. As a converted pragmatist, I found this "semantic" talk
rather dull. First, "semantic HTML" is something that could have been
created in the 1990s but wasn't; and it's too late now. Second, it was
never much about semantics, it was about relationships. The definition
of "difficulty", for example is a semantic question. But defining a <dl>
element as a set of term/definition pairs is structural rather than
semantic.

> I quote from Section 4 of the above:
> "The HTML list elements DL, UL, and OL should only be used to create
> lists, not for formatting effects such as indentation."

Oh really? And yet, the HTML 4.01 specification itself uses, in its
table of content, <ul> when they find it comfortable (they want bullets,
not numbers), at some level of nesting lists, see
http://www.cs.tut.fi/~jkorpela/html/ul-ol.html#demo

> But what is and is not a list?

Whatever you call a list. Anything can be seen as a list, as a one-item
list if necessary. It's funny how often authors set up a list of links
as <ul> and then take much trouble in removing all the default
formatting they introduced that way. And if someone dares to do
otherwise, he will get crucified on "semantic grounds".

> On reflection, I'd argue that
> HTML tags are simply structural patterns inviting flexible use, and that
> a DL is simply a structure which provides an association between pairs

It's not quite that simple. Even we pragmatists make a note of actual
effects of markup beyond that. First, many HTML elements imply some
default rendering. If that's a suitable starting point and at least
tolerable fallback in non-CSS rendering, go for it. Second, some
elements have functional implications. Form fields take input, headings
are taken seriously by search engines, and tables have accessibility
features at least in some modern software. So the Pragmatist's Manifesto
is really saying: take *real* implications seriously, but ignore
speculation, for the most of it:
http://www.cs.tut.fi/~jkorpela/pragmatic-html.html8

> Personally, I've found myself gravitating to a view which distinguishes
> three independent considerations: structure, formatting, and semantics.
> Structure is the domain of HTML, but I see it (YMMV) as rightly
> semantic-free.

Almost completely, yes. There are some semantic features in metadata,
though. Mostly misunderstood, but still.

Using HTML elements could be compared to using "styles" in MS Word. You
pick up, say, "heading 2" (like you use <h2>), then perhaps later
consider tweaking the definitions of the style (like writing a CSS rule
with h2 as the selector), and at times you set up a new style (like you
might use an element with class attribute in HTML).

--
Yucca, http://www.cs.tut.fi/~jkorpela/

[Philip Herlihy]

In article <k693df$pdg$1...@dont-email.me>, jkor...@cs.tut.fi says...

>
> 2012-10-24 17:59, Philip Herlihy wrote:
>

...

>
> > Personally, I've found myself gravitating to a view which distinguishes
> > three independent considerations: structure, formatting, and semantics.
> > Structure is the domain of HTML, but I see it (YMMV) as rightly
> > semantic-free.
>
> Almost completely, yes. There are some semantic features in metadata,
> though. Mostly misunderstood, but still.
>

.. (other shrewd observations trimmed)

I was much influenced by your contributions when the topic first came
up, and I think you express a very appropriate position on these issues
very well. The scientist still in me now wants empirical data - I hope
before long to download that screen reader (the one the RNIB mention
must be fairly representative) and try out some tests. But having spent
rather too long pontificating here I should devote the rest of the
afternoon to some work!

Thanks!

--

Phil, London

[Swifty]

On 24/10/2012 15:59, Philip Herlihy wrote:
> Is that what actually happens, or is this a "thought experiment"? I've
> never experienced a screen reader (can you download them easily?) and I
> wonder if you're speaking from experience - it would be good to know.

I've had some limited experience with screenreaders. I had a colleague
with macular degeneration, and he used to run a 28" display in VGA mode
and then read the screen from a distance of about 2". I suspect his
display was a plasma screen, as he got uncomfortably hot. When the heat
was too much, he'd use a screenreader for a while until his nose had
cooled off. The screenreader read the words, but also included hints
from the context; for example it said "Paragraph" when encountering "<P>".

This was some time ago, and I have only a vague memory. Having seen how
he'd struggled on one of my simple HTML pages, because I'd used tags for
effect rather than semantically, I vowed to be a bit more careful in future.

This seems to be a pattern in my life. I saw a post with text lIKE THIS
in it. I replied that the person should be more careful with CapsLock,
and got the answer "I would if I could; I'm blind". I researched this
and discovered "togglekeys" (In Windows) and that made up for my gaffe
when I told the other about it. I still cringe though.

[Philip Herlihy]

In article <k6iq2g$33i$1...@speranza.aioe.org>, steve....@gmail.com
says...

>
> On 24/10/2012 15:59, Philip Herlihy wrote:
> > Is that what actually happens, or is this a "thought experiment"? I've
> > never experienced a screen reader (can you download them easily?) and I
> > wonder if you're speaking from experience - it would be good to know.
>

> ...The screenreader read the words, but also included hints

> from the context; for example it said "Paragraph" when encountering "<P>".
>

It's quite plausible, then that a screen reader would mutter
"Definitions" if presented with a DL. Or maybe just "list". I wonder
if this is configurable?

--

Phil, London

[dorayme]

In article <MPG.2af75a7a2...@news.demon.co.uk>,

Philip Herlihy <bounc...@you.com> wrote:

> It's quite plausible, then that a screen reader would mutter
> "Definitions" if presented with a DL. Or maybe just "list". I wonder
> if this is configurable?

It would be programable. But whether it would be a good idea is
another matter. It is easy to imagine it being useful but anyway, it
is not going to happen anytime soon. Be awkward for when authors use
the element for non definitions though or annoying (patronising?) for
when the context makes it quite clear anyway. Remember, the latest
thing is do anything you like with tags, whatever works (seen the
Woody Allen film with Larry David, Whatever Works?).

--
dorayme