No TABLES in html. No hacks in CSS. Any layout possible,crossbrowser. Try it.

Can you show me some hard data backing up your claim that 10% of
visitors do not have Javascript enabled? Even for such people all
content is still readable and if you really care you can provide them
with something easy on eyes.

http://www.w3schools.com/browsers/browsers_stats.asp
varies between 6-12% over the last few years. Note I said *~* 10%. That
means circa 10%. There are other stat sites which you can probably find
via Google.
Thanks. I don't know why did you average this form 2002 to 2007

though. I think you should look at number for 2007 which is 6% and
seems to be dropping (probably due ajax people don't want to cripple
themselves anymore).

I would have expected you to have at least a link to a demonstration
page at the link you mentioned.
..and do you have one of these?
I am sorry but I still don't know what do you mean by demonstration.

Link I have given point to my wiki directly to simples example.

You say, "You just need to write something like this!"
but it is a *lot* easier just to write regular old HTML than your
script, with its errors. A *lot* easier.

This is very simple example. True strength of my approach is ability
to nest layouts, and ability to change them as requirements change.

What kind of "nesting" would I want to do? Nest tables?
Nest layout components inside layout components. Split footer into

columns, give left column it's own footer. Split content area into
three columns and give them their own header.

You also say, "HTML is horrible. It's not suitable for anything more
visually complicated than a short school essay. " You must be new to
this game. HTML and CSS can do much more than you seem to realize.

Actually I'm pretty old to this game and tired from countless
occasions when I tried to get something look good and do what I want
in different browsers. I joined this game before such thing as
tableless layout was even possible.

Me too, but that's not an excuse.
It's not an excuse. It's a motivation.

And I'll bet the total weight in bytes of a plain HTML/CSS page is quite
a bit less than your convoluted approach.
It's not weight in bytes that matters.
Of *course* it matters! Ever use dial-up?
Yes. Please give these argument to all the people cramming video

adverts on webpages.
I know it matters but there are things that matter more.

It's weight in hours of programmer time stolen that matters.
That applies to one person, not thousands of visitors' time. You would
rather churn out pages quickly, then penalize all of the visitors with
bloated pages?
Pages done with help of my lib are not bloated. For bigger more

complex pages it should be about same size or even smaller than css
+html equivalent.

And for more complex layout there should be no significant difference
in size between my approach and css hacking.
CSS hacking? Hacking? You think we need to 'hack'? <g
Every time you use float to make a column you hack. Floats were not

intended to be used as columns so you use something in clever
unintended way to achieve some goal therefore you hack.

More important is that with my lib you can achieve being
crossbrowser almost effortless and your html files and even css
files stay clean hack-free, table-free.

My HTML and CSS files are already "hack-free". You will have to
explain in some detail why you think differently.

Then you are lucky guy, browsing internet tells me not everybody is
as lucky as you. Explain? underscore hack, asterisk hack, .clearfix
... I'm sure you know what I'm talking about.

Oh, you are talking about *authoring* "hacks"... I don't consider good,
semantic HTML or carefully crafted CSS "hacking". I thought you meant
someone - some black hat person - could hack your server files. <shrug
Sorry. I'm not native speaker? Would it be clearer If I used bunny

ears around word hack like you did?

Your other post:

I'm not using tables in my html, isn't that enough?

No. It is still using "tables for layout", a process we keep stressing
should be avoided.

Could you remind me real quick why this should be avoided?

Read the archives of these groups.
That was even quicker than I expected.

Semantic html, uncluttered html, crossbrowser comes to my mind.

Semantic. How is a column of menu items related to a block of content
adjacent to it? Tables are for data.
If you use my lib you can put them at the end of the file, at the

beginning of the file, near other ways of navigating .... anywhere!
Because order of things in your html file has nothing to do with where
they will appear on your webpage. Perhaps I have not stated this
clearly enough in my wiki.

My approach has this qualities. Or maybe tables has been declared as
devils spawn by vatican and should be as such?

For layout, yes. The Pope told me.
Ok, but do you see any of them in my html source file?

I keep my html clean and I can order content any way I want. It's
human friendly and robot friendly.

Your sample code is using a Transitional doctype. What are you
transitioning from? That's for legacy pages; use Strict instead.

Maybe you can put browser in quirks mode with strict doctype
declaraion, I haven't tried that yet. It's work in progress.

What?
I guess you can't help me with this. :-)

You assign font size in pixels; that too has gone the way of the dodo
bird. Use percentages instead. See:http://k75s.home.att.net/fontsize.html

This has nothing to do with my lib so you can specify fonts any way
you like while using it. I like pixels for this simple example.

Most of us prefer percentages for font sizing because when the visitor
hits the "upsize" key, the content won't jump out of your pixel-sized
boxes. And IE won't resize, thus annoying your visitors with less than
perfect vision.
Wasn't that the rationale for specifying box sizes with em instead of

pixels ?
Are you sure that this is what specifying font sizes in percents is
all about?
Page you've linked to just says something about IE not being able to
resize texts with fonts specified in pixels.

Clean code? <lol> See:
http://validator.w3.org/check?verbos...2Fwww.bravelay...

This page is not Valid XHTML 1.0 Transitional!
Result: Failed validation, 119 Errors

Why do you try to validate it as XHTML if it's indicated as HTML
Transitional in DOCTYPE?
It's valid HTML 4.01 Transitional (after some minor fixes).

Read the validator link again. It's your page .. the link you posted.
Your site. My sites have no errors.
Oh. Sorry. You checked the wiki I use. Sure It does not validate. I

just used standard template, perhaps you should communicate this
validation issue to template author. Perhaps he will be interested.
This template does not use my lib.

If you are so surprised that I can do something such nasty as
publishing nonvalidating webpage then I must want you that I also
visit toilet each single day! ;-)

When I validate example using my lib with validator
http://validator.w3.org/check?uri=ht...Inline&group=0
I get message that this page is valid with only one warning about me
not specifying charset.

Human friendly, perhaps, to the other 90%.
Robots (search engines?) don't read and execute JavaScript.

And that's good because visual layout of a page is none of their
interest.

So anything in your JavaScript is ignored.
Yes! That's the whole point. Ignored same way as your css file is

ignored by any search engine robot.

brave1979 wrote:

Actually I'm pretty old to this game and tired from countless
occasions when I tried to get something look good and do what I want
in different browsers. I joined this game before such thing as
tableless layout was even possible.

And I'll bet the total weight in bytes of a plain HTML/CSS page is quite
a bit less than your convoluted approach.
It's not weight in bytes that matters. It's weight in hours of
programmer time stolen that matters.

That's what *server*-side programming is good for. You write routines to
automate the generation of HTML on the *server* to save yourself the
effort of coding it all manually. Then the user gets HTML, not script
that may or may not work in his browser.

..oO(brave1979)

This is very simple example. True strength of my approach is ability
to nest layouts, and ability to change them as requirements change.

What kind of "nesting" would I want to do? Nest tables?
Nest layout components inside layout components. Split footer into
columns, give left column it's own footer. Split content area into
three columns and give them their own header.

And why does this require unreliable client-side scripting? The same can
be done with server-side scripting and clean, appropriate HTML as the
result.

And for more complex layout there should be no significant difference
in size between my approach and css hacking.
CSS hacking? Hacking? You think we need to 'hack'? <g
Every time you use float to make a column you hack. Floats were not
intended to be used as columns so you use something in clever
unintended way to achieve some goal therefore you hack.

I beg to differ. The behaviour of floats is exactly defined and
described in detail in the CSS spec. That's not what I'd call a hack.

Semantic html, uncluttered html, crossbrowser comes to my mind.

Semantic. How is a column of menu items related to a block of content
adjacent to it? Tables are for data.
If you use my lib you can put them at the end of the file, at the
beginning of the file, near other ways of navigating .... anywhere!
Because order of things in your html file has nothing to do with where
they will appear on your webpage. Perhaps I have not stated this
clearly enough in my wiki.

The order of elements _does_ matter. If you need scripting or CSS to
bring the elements in a senseful order and make your site usable, then
it's a broken design right from the beginning.

My approach has this qualities. Or maybe tables has been declared as
devils spawn by vatican and should be as such?

For layout, yes. The Pope told me.
Ok, but do you see any of them in my html source file?

Doesn't matter. Written in the HTML or generated by a script - it's the
same thing. If your script generates tables, then you _are_ using tables
to layout the HTML.

Your sample code is using a Transitional doctype. What are you
transitioning from? That's for legacy pages; use Strict instead.

Maybe you can put browser in quirks mode with strict doctype
declaraion, I haven't tried that yet. It's work in progress.

What?
I guess you can't help me with this. :-)

It would help if you would explain your problems with a strict DTD.

Human friendly, perhaps, to the other 90%.
Robots (search engines?) don't read and execute JavaScript.

And that's good because visual layout of a page is none of their
interest.

So anything in your JavaScript is ignored.
Yes! That's the whole point. Ignored same way as your css file is
ignored by any search engine robot.

Usually a CSS is not required in order to make a site usable, whereas
your JavaScript is. No JS, no content. CSS is optional and properly
built sites work perfectly well without it, so SEs don't have to care
about it at all.

Micha

Michael Fesser wrote:

.oO(brave1979)

This is very simple example. True strength of my approach is ability
to nest layouts, and ability to change them as requirements change.
What kind of "nesting" would I want to do? Nest tables?
Nest layout components inside layout components. Split footer into
columns, give left column it's own footer. Split content area into
three columns and give them their own header.

And why does this require unreliable client-side scripting? The same can
be done with server-side scripting and clean, appropriate HTML as the
result.

And for more complex layout there should be no significant difference
in size between my approach and css hacking.
CSS hacking? Hacking? You think we need to 'hack'? <g
Every time you use float to make a column you hack. Floats were not
intended to be used as columns so you use something in clever
unintended way to achieve some goal therefore you hack.

I beg to differ. The behaviour of floats is exactly defined and
described in detail in the CSS spec. That's not what I'd call a hack.

Semantic html, uncluttered html, crossbrowser comes to my mind.
Semantic. How is a column of menu items related to a block of content
adjacent to it? Tables are for data.
If you use my lib you can put them at the end of the file, at the
beginning of the file, near other ways of navigating .... anywhere!
Because order of things in your html file has nothing to do with where
they will appear on your webpage. Perhaps I have not stated this
clearly enough in my wiki.

The order of elements _does_ matter. If you need scripting or CSS to
bring the elements in a senseful order and make your site usable, then
it's a broken design right from the beginning.

My approach has this qualities. Or maybe tables has been declared as
devils spawn by vatican and should be as such?
For layout, yes. The Pope told me.
Ok, but do you see any of them in my html source file?

Doesn't matter. Written in the HTML or generated by a script - it's the
same thing. If your script generates tables, then you _are_ using tables
to layout the HTML.

Your sample code is using a Transitional doctype. What are you
transitioning from? That's for legacy pages; use Strict instead.
Maybe you can put browser in quirks mode with strict doctype
declaraion, I haven't tried that yet. It's work in progress.
What?
I guess you can't help me with this. :-)

It would help if you would explain your problems with a strict DTD.

Human friendly, perhaps, to the other 90%.
Robots (search engines?) don't read and execute JavaScript.
And that's good because visual layout of a page is none of their
interest.
So anything in your JavaScript is ignored.
Yes! That's the whole point. Ignored same way as your css file is
ignored by any search engine robot.

Usually a CSS is not required in order to make a site usable, whereas
your JavaScript is. No JS, no content.

In fairness, that's not an issue in the OP's case. The content *is*
present in HTML, in more or less the same form it would be if CSS
instead of Javascript was being used for the layout.

On 2007-12-31, brave1979 <brave1979 (AT) o2 (DOT) pl> wrote:

On Dec 31, 12:31 am, Harlan Messinger
hmessinger.removet... (AT) comcast (DOT) net> wrote:
brave1979 wrote:
On Dec 30, 7:02 pm, Harlan Messinger
hmessinger.removet... (AT) comcast (DOT) net> wrote:
brave1979 wrote:
Please check out my javascript library that allows you to create any
layout for your web page, nested as deep as you like, adjusting to
width and height of a browser window. You just describe it in
javascript object and that's all. No need to know CSS hacks, no need
to clutter your html with tables.
http://www.bravelayout.scarabeo.biz/Quickstart
You are using tables, you're just using Javascript to create them:

I'm not using tables in my html, isn't that enough?

Enough for what? Evidently you're misunderstanding the intent of the
guidance to avoid using tables for layout.
I thought tables were avoided for some real benefits like semantic
content, clean html, separating defining visual aspects from defining
content. My lib does all that, and it's easy to use.

Those are some of the reasons given, but there is another one, which is
that many features of table layout aren't defined precisely in any
specification, and many things are deliberately undefined.

That means the best you can do is test in a few browsers, but you don't
know if your page will look how you intended on browsers you didn't test
in or on future versions of the ones you did test in, unless you stick
only to the subset of table layout behaviour that is defined, which is
likely to be too restrictive.

You have a point that floats weren't really intended for doing columns
with either, but at least the behaviour you should get is well-defined.

On Dec 31, 7:02 am, Michael Fesser <neti... (AT) gmx (DOT) de> wrote:

.oO(brave1979)

This is very simple example. True strength of my approach is ability
to nest layouts, and ability to change them as requirements change.

What kind of "nesting" would I want to do? Nest tables?
Nest layout components inside layout components. Split footer into
columns, give left column it's own footer. Split content area into
three columns and give them their own header.

And why does this require unreliable client-side scripting? The same can
be done with server-side scripting and clean, appropriate HTML as the
result.
I think you misunderstood me. I am no saying about enabling or

disabling this elements on some of you subpages.
I am saying that you can take standard pure 2 column CSS layout from
internet (where it was put by smart people who figured way how to
force browser to display it).
But if you want to have right column of this layout similar way (to
have its own header footer and two columns) then there is no easy way
to do it.

And for more complex layout there should be no significant difference
in size between my approach and css hacking.
CSS hacking? Hacking? You think we need to 'hack'? <g
Every time you use float to make a column you hack. Floats were not
intended to be used as columns so you use something in clever
unintended way to achieve some goal therefore you hack.

I beg to differ. The behaviour of floats is exactly defined and
described in detail in the CSS spec. That's not what I'd call a hack.
Does the word "column" appear anywhere on this spec? Does any example

of use in specs shows how to use it to make column?
http://www.w3.org/TR/REC-CSS2/visuren.html#floats

Clever way of exploiting system for your own purposes is called a
hack.

Semantic html, uncluttered html, crossbrowser comes to my mind.

Semantic. How is a column of menu items related to a block of content
adjacent to it? Tables are for data.
If you use my lib you can put them at the end of the file, at the
beginning of the file, near other ways of navigating .... anywhere!
Because order of things in your html file has nothing to do with where
they will appear on your webpage. Perhaps I have not stated this
clearly enough in my wiki.

The order of elements _does_ matter. If you need scripting or CSS to
bring the elements in a senseful order and make your site usable, then
it's a broken design right from the beginning.
When doing table layouts you must order your content to fit tables.

When you are doing pure css layouts you often have to order your
content to fit adjecent columns simulated by floats.
When you are doing BraveLayout you may order your content exactly
according to its meaning, you are not constrained by visual layout of
a page in any way.

My approach has this qualities. Or maybe tables has been declared as
devils spawn by vatican and should be as such?

For layout, yes. The Pope told me.
Ok, but do you see any of them in my html source file?

Doesn't matter. Written in the HTML or generated by a script - it's the
same thing. If your script generates tables, then you _are_ using tables
to layout the HTML.
But I still don't understand what is wrong with doing this.

I know what's wrong with putting tables in your html to achieve visual
effect but I can't understand why you consider them evil when they are
used the way I use them. I have not seen any argument for this yet.
Because so far I've just seen statement "tables for layout are evil"
repeated like a mantra.

Human friendly, perhaps, to the other 90%.
Robots (search engines?) don't read and execute JavaScript.

And that's good because visual layout of a page is none of their
interest.

So anything in your JavaScript is ignored.
Yes! That's the whole point. Ignored same way as your css file is
ignored by any search engine robot.

Usually a CSS is not required in order to make a site usable, whereas
your JavaScript is. No JS, no content. CSS is optional and properly
built sites work perfectly well without it, so SEs don't have to care
about it at all.
Please see my example. Disable javascript. You will still see all the

content. There just will be no layout. http://bravelayout.scarabeo.biz/examples/example0.html

On Dec 31, 7:01 am, Harlan Messinger
<hmessinger.removet... (AT) comcast (DOT) net> wrote:

brave1979 wrote:
Actually I'm pretty old to this game and tired from countless
occasions when I tried to get something look good and do what I want
in different browsers. I joined this game before such thing as
tableless layout was even possible.

And I'll bet the total weight in bytes of a plain HTML/CSS page is quite
a bit less than your convoluted approach.
It's not weight in bytes that matters. It's weight in hours of
programmer time stolen that matters.

That's what *server*-side programming is good for. You write routines to
automate the generation of HTML on the *server* to save yourself the
effort of coding it all manually. Then the user gets HTML, not script
that may or may not work in his browser.

So you say that programmers who do html and css don't spend any time?
Someone has to code this html and his time I intend to save.

On Dec 31, 9:25 am, Ben C <spams... (AT) spam (DOT) eggs> wrote:

Those are some of the reasons given, but there is another one, which is
that many features of table layout aren't defined precisely in any
specification, and many things are deliberately undefined.

That means the best you can do is test in a few browsers, but you don't
know if your page will look how you intended on browsers you didn't test
in or on future versions of the ones you did test in, unless you stick
only to the subset of table layout behaviour that is defined, which is
likely to be too restrictive.

You have a point that floats weren't really intended for doing columns
with either, but at least the behaviour you should get is well-defined.

I agree with you. If I could achieve the flexibility I require with
floats I would generate floats not tables with my lib. Just for the
sake of mental health of people who hate for the tables running
through their veins.

But your point is at the moment rather theoretical than practical.
You also don't know how your pure css layout will look on browsers you
have not tested. You know only how it should look if browser was built
according to full specs which rarely happens. So it's more like
placing the blame on someone else than really addressing the problem.

As for future versions of common browsers, they are no problem because
BraveLayout relies on quirks mode which is currently never touched by
browser developers. They improve standards mode, but they keep quirks
mode for backwards compatibility with older pages. It's highly
unlikely that some browser development team decides to remove quirks
mode from their browser as some point in near future. And even then my
lib could probably be improved to support such browser.

On 2007-12-31, brave1979 <brave1979 (AT) o2 (DOT) pl> wrote:

On Dec 31, 9:25 am, Ben C <spams... (AT) spam (DOT) eggs> wrote:
[...]
As for future versions of common browsers, they are no problem because
BraveLayout relies on quirks mode which is currently never touched by
browser developers. They improve standards mode, but they keep quirks
mode for backwards compatibility with older pages. It's highly
unlikely that some browser development team decides to remove quirks
mode from their browser as some point in near future.

It's not that simple. The problem is that the unspecified parts of table
formatting are a complicated mess.

Look at Firefox's documentation of quirks mode:

http://developer.mozilla.org/en/docs..._Mode_Behavior

It's all nice and clear, until we get to the bottom of the Tables
section. "The basic table layout strategy handles widths differently in
some way"

I wonder what QA tests exist for this different handling, and if they
cover all of the processing that the output of your lib needs. I wonder
if anyone really knows what it does, or if the plan is just to try to
ignore it until it goes away.

Perhaps developers won't be touching that part intentionally, but a
change elsewhere could easily affect the way it works.

And what about browsers that aren't IE, Gecko, Opera or KHTML? As more
browsers, and therefore the web itself, get closer to conforming to the
W3C standards, the playing field opens up because, with specifications,
it's much easier for anyone to implement a browser. How much cursory
support for unspecified quirks-mode table column width calculations do
you expect these newer browsers will attempt?

You would be better off to output strict mode tables, avoid rowspan and
colspan altogether, and be careful with percentages.

And even then my lib could probably be improved to support such
browser.

Your lib provides authors with an alternative way of describing layouts
that isn't CSS or tables, although it has more in common with tables,
which is probably why the output is in the form of tables.

It's possible that it does provide a way of writing more succintly the
things some people wanted to do with tables in the days when they used
them for layout.

But you're relying on consistent JS implementation between browsers
instead. Is that any more reliable than their CSS implementations? Not
much if at all.

I don't see the need to-- why not instead write your preprocessor in
some reasonably reliable cross-platform programming language (Python,
Java, etc.) and then people can run it on their own development machines
or servers and just put the output on the web? I don't see the need to
run it on the client's JS interpreter at all.

On Dec 31, 12:39 pm, Ben C <spams... (AT) spam (DOT) eggs> wrote:

On 2007-12-31, brave1979 <brave1... (AT) o2 (DOT) pl> wrote:

On Dec 31, 9:25 am, Ben C <spams... (AT) spam (DOT) eggs> wrote:
[...]
As for future versions of common browsers, they are no problem because
BraveLayout relies on quirks mode which is currently never touched by
browser developers. They improve standards mode, but they keep quirks
mode for backwards compatibility with older pages. It's highly
unlikely that some browser development team decides to remove quirks
mode from their browser as some point in near future.

It's not that simple. The problem is that the unspecified parts of table
formatting are a complicated mess.

Look at Firefox's documentation of quirks mode:

http://developer.mozilla.org/en/docs..._Mode_Behavior

It's all nice and clear, until we get to the bottom of the Tables
section. "The basic table layout strategy handles widths differently in
some way"

I wonder what QA tests exist for this different handling, and if they
cover all of the processing that the output of your lib needs. I wonder
if anyone really knows what it does, or if the plan is just to try to
ignore it until it goes away.
Despite the things you mentioned behavior of tables seems to be pretty

consistent across different modern browsers. Even sometimes more
consistent than standards mode especially in areas when specs are
lacking like in case of 100% height for tables and table cells.

Perhaps developers won't be touching that part intentionally, but a
change elsewhere could easily affect the way it works.
As I understand standards mode rendering is quite independent of

quirks mode in modern browsers so there is low probability that quirks
mode will be affected during development of standards. And my lib is
not carved in stone. It's not even compiled. Anyone can change it to
adjust it to "features" introduced in some browsers. It's just layer
of abstraction isolating layout definition from inconsistent rendering
engines.

And what about browsers that aren't IE, Gecko, Opera or KHTML? As more
browsers, and therefore the web itself, get closer to conforming to the
W3C standards, the playing field opens up because, with specifications,
it's much easier for anyone to implement a browser. How much cursory
support for unspecified quirks-mode table column width calculations do
you expect these newer browsers will attempt?
I really hope that before that newer browser gain market share HTML5

(or six or something else) and next versions of CSS will be widely
adopted standards and my lib will evolves into something that uses
those standards. I may even imagine compiler that automatically
translated my layout definition to proper CSS3 or CSS4 or whatever
will be best used for layouts in the future.

You would be better off to output strict mode tables, avoid rowspan and
colspan altogether, and be careful with percentages.
I don't know about strict mode (it varies greatly across browsers in

areas where the specs are lacking) but I learned early that colspans
and rowspans should be avoided at all costs, and that percentages
should be used carefully. BraveLayout.js was written with this things
in mind.

And even then my lib could probably be improved to support such
browser.

Your lib provides authors with an alternative way of describing layouts
that isn't CSS or tables, although it has more in common with tables,
which is probably why the output is in the form of tables.

It's possible that it does provide a way of writing more succintly the
things some people wanted to do with tables in the days when they used
them for layout.

But you're relying on consistent JS implementation between browsers
instead. Is that any more reliable than their CSS implementations? Not
much if at all.
Actually yes, I learned from experience that it's much more

consistent. And inconsistencies are much easier to deal with.

I don't see the need to-- why not instead write your preprocessor in
some reasonably reliable cross-platform programming language (Python,
Java, etc.) and then people can run it on their own development machines
or servers and just put the output on the web? I don't see the need to
run it on the client's JS interpreter at all.
This preprocessor would have to generate css and tables in html

because I have not seen any way of doing things BraveLayout does in
pure css. And there should not be tables cluttering your html source.
If not for that the preprocessor would be preferred solution.