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

brave1979 wrote:

I thought tables were avoided for some real benefits like semantic
content, clean html, separating defining visual aspects from defining
content.
They're semantically just as incorrect if you have Javascript generating
them in the browser as they would be if the author had coded them
directly.
Sorry. Maybe I am misunderstanding word "semantic". I thought its
something like "meaningful".

Yes.

And writing semantic html is writing html
that has meaning and structure associated with this meaning not just
html that is the tag soup to force browser to render properly (as with
table layout).

Exactly. And tag soup is tag soup no matter how you generate it, whether
by hand or with Javascript. The contents of your page that aren't
logically a table, don't *become* logically a table just because you let
Javascript generate the table-related tags.

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

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.

I suppose they would be annoying if you used a screen reader or
something.

I think I see your point: nice uncluttered HTML is not just for
authors, but also better for users.

On 2007-12-31, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:

brave1979 wrote:
I thought tables were avoided for some real benefits like semantic
content, clean html, separating defining visual aspects from defining
content.
They're semantically just as incorrect if you have Javascript generating
them in the browser as they would be if the author had coded them
directly.
Sorry. Maybe I am misunderstanding word "semantic". I thought its
something like "meaningful".

Yes.

And writing semantic html is writing html
that has meaning and structure associated with this meaning not just
html that is the tag soup to force browser to render properly (as with
table layout).

Exactly. And tag soup is tag soup no matter how you generate it, whether
by hand or with Javascript. The contents of your page that aren't
logically a table, don't *become* logically a table just because you let
Javascript generate the table-related tags.

Isn't the idea of his system that the HTML stays as nice clean HTML,
and is only munged into a sea of tables by the JS?

brave1979 wrote:

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

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?

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

Nah, I'd call it being creative. Just because the CSS specs don't
explicitly say you may use properties for particular visual effects
doesn't mean you can't.

If your script generates tables, then you _are_ using tables
to layout the HTML.

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.

The document tree is what the browser/user sees. Why do you think
generating it via script instead of coding it in the HTML makes a
difference?

--
Berg

brave1979 wrote:

This template does not use my lib.

You don't use your own product? Why would you expect anyone else to?

--
Berg

On Dec 30, 5:42 am, brave1979 <brave1... (AT) o2 (DOT) pl> 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

There *is* a strong argument for this sort of thing in the
"complex web-app" context. But to fill that niche you
need a system like Google's GWT, that somehow also includes
asynchronous server communication.

I spent 4 months working on a (now defunct) interface
to XML database project that included a drag-and-drop
editor for building complex hierarchical data entry forms (for
describing
experimental data). Those forms, once 'saved,' where
automatically operational--you could fill them out
and save data. Another form allowed dynamic creation
of complex query forms (select all data where creation_date
between xxx and /exp/protocol/ == 'whatever' etc.
And that worked, all built with mouse clicks, with no
intervention by a programmer. It would have been a nightmare
to code without GWT (code in java, compile to javascript).
Mouseover Select Option choices can update the server without re-
drawing the
screen, for instance. But that's just one of many examples.

So, this sort of thing is outside the context of simple "here I am
websites." It's at its best for highly complex, interactive
web-based GUI screens. But you do need the xmlhttpheaderreq
stuff. Else you went to New York but you got off in Chicago.

On Dec 31, 2:11 pm, "Beauregard T. Shagnasty"
<a.nony.m... (AT) example (DOT) invalid> wrote:

I would also love to see a real demo page, with some real content, and
that is still visible when JavaScript is unavailable.
Great to hear that. This is first time I release it to public so more

examples will be coming soon. Actually I already have some running web
application built using BraveLayout but it's little more complex so
It's not good for first example. I also need to clean it up a little
bit. I will keep you informed. Until then please feel free to
experiment with BraveLayout yourself.

On Dec 31, 2:16 pm, Harlan Messinger
<hmessinger.removet... (AT) comcast (DOT) net> wrote:

brave1979 wrote:
I thought tables were avoided for some real benefits like semantic
content, clean html, separating defining visual aspects from defining
content.
They're semantically just as incorrect if you have Javascript generating
them in the browser as they would be if the author had coded them
directly.
Sorry. Maybe I am misunderstanding word "semantic". I thought its
something like "meaningful".

Yes.

And writing semantic html is writing html
that has meaning and structure associated with this meaning not just
html that is the tag soup to force browser to render properly (as with
table layout).

Exactly. And tag soup is tag soup no matter how you generate it, whether
by hand or with Javascript. The contents of your page that aren't
logically a table, don't *become* logically a table just because you let
Javascript generate the table-related tags.

But noone ever sees this tables. You must be able to see current DOM
tree to ever see any table generated by BraveLayout. Most browsers
does not even has that option out of the box. If you just "View
Source" you won't see any table. If you download my page with some
other program like wget you won't see any table either. What does it
matter if browser internally renders tables to display the content if
those tables are not visible anywhere else?

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

On 2007-12-31, Harlan Messinger <hmessinger.removet... (AT) comcast (DOT) net> wrote:



brave1979 wrote:
I thought tables were avoided for some real benefits like semantic
content, clean html, separating defining visual aspects from defining
content.
They're semantically just as incorrect if you have Javascript generating
them in the browser as they would be if the author had coded them
directly.
Sorry. Maybe I am misunderstanding word "semantic". I thought its
something like "meaningful".

Yes.

And writing semantic html is writing html
that has meaning and structure associated with this meaning not just
html that is the tag soup to force browser to render properly (as with
table layout).

Exactly. And tag soup is tag soup no matter how you generate it, whether
by hand or with Javascript. The contents of your page that aren't
logically a table, don't *become* logically a table just because you let
Javascript generate the table-related tags.

Isn't the idea of his system that the HTML stays as nice clean HTML,
and is only munged into a sea of tables by the JS?

Yes. Your html source stays nice and clean. Layout is generated
internally in browser by javscript while the page loads. When it
finishes loading parts of source html are placed in the right spots of
generated layout.

On Dec 31, 2:58 pm, Bergamot <berga... (AT) visi (DOT) com> wrote:

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

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?

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

Nah, I'd call it being creative. Just because the CSS specs don't
explicitly say you may use properties for particular visual effects
doesn't mean you can't.
Kicking the vending machine in the right spot to get some coins is

also creative and the fact that it wasn't built for that doesn't mean
you can't do it (at least when no one is watching ;-)).

If your script generates tables, then you _are_ using tables
to layout the HTML.

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.

The document tree is what the browser/user sees. Why do you think
generating it via script instead of coding it in the HTML makes a
difference?
User does not see DOM tree, he sees rendered page. What actually is in

DOM tree usually does not interest him. But he may be interested in
html source file, and this is kept clean and readable in my method.