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

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

Yes. But HTML generated by code is HTML.

His code doesn't generate HTML.

He has annoyingly removed whitespace from the source. I wish people
wouldn't do that. But all the same you can see that he's creating the
DOM tree with createElement and appendChild, not innerHTML.

(Seehttp://www.bravelayout.scarabeo.biz/examples/BraveLayout-standalone-m...
andhttp://www.bravelayout.scarabeo.biz/examples/example0.html)
If you want source try: http://www.bravelayout.scarabeo.biz/...-standalone.js

http://www.bravelayout.scarabeo.biz/...ndalone-min.js
is a minified version (quite unreadable)

brave1979 schreef:

On Dec 31, 5:06 pm, Rob Waaijenberg <robwaaijenb... (AT) hotmail (DOT) com
wrote:
brave1979 schreef:



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?
Do you ever read back what you wrote, before you post it?
I'm sorry. I know I can be sometimes hard to understand. :-( Please
ask questions and I'll try to rephrase what I said.

To me it doesn't make sense.

If a page uses tables for lay-out and I use "view source"
I can see them allright.
If they are generated by the javascript you can't. I don't know what
browser you are using but when you do "View Source" in IE, Firefox,
Konqueror, Opera, probably Safari you will see only what was actually
read from the web server, not the things javascript generated in your
browser.

Are you sure that when you go to page: http://www.bravelayout.scarabeo.biz/.../example0.html
and "View Source" you can see any table ?

I can't see any tables, because there are no tables.

In the post that is quoted above, you made several statements that
implied there were tables but that they couldn't be seen.
("..noone ever sees this tables...")
("What does it matter if browser internally renders tables...")

In your exemple-page you don't generate tables, you generate DIV's.

I'm starting to believe that for you 'tables' are the same as 'divs'.

--
Rob

What browser you are using?

Ben C wrote:

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

I bet it's not so uncluttered by the time he's done with all the script-foo.

--
Berg

brave1979 wrote:

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

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.

The browser sees the document tree. The user sees the browser's
rendering of that tree. It's illogical to keep separating the 2.

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.

User's could care less about your HTML source code. They *do* care about
what the browser does with the code.

--
Berg

brave1979 wrote:

I don't know about strict mode (it varies greatly across browsers in
areas where the specs are lacking)

Cite an example, please.

--
Berg

Ben C wrote:

On 2007-12-31, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:
Ben C wrote:
[...]
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. But HTML generated by code is HTML.

His code doesn't generate HTML.

He has annoyingly removed whitespace from the source. I wish people
wouldn't do that. But all the same you can see that he's creating the
DOM tree with createElement and appendChild, not innerHTML.

(See
http://www.bravelayout.scarabeo.biz/...ndalone-min.js
and http://www.bravelayout.scarabeo.biz/.../example0.html)

At no point does nasty HTML exist, unless you count things like the
Firebug turning the DOM tree back into sort of HTML for the purpose of
displaying it.

All right, you're technically correct. So he's creating an HTML DOM
*tree* that is still a semantically incorrect representation of the
logical structure of the document.

brave1979 wrote:

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.

Since the objections to using tables for layouts have nothing to do with
what anyone *sees*, this is irrelevant.

brave1979 wrote:

Is a fact that I disabled CSS in my browser a valid argument against
tableless layouts?

Absolutely not. It is an argument *for* tableless layouts.

Should you use tables and 1px gifs because of that fact?

You are ignoring the fact that CSS is intended to be optional. The days
of "must look the same in all browsers" are over.

Person who knows photoshop and person who knows html are not always
the same person.

Yes, and... ?

You can remove from your design things that you don't
know how to do in html.

If the designer and coder are 2 different people, there should be no
reason to do this. If they are the same person, then it sounds like a
case of The Peter Principle.

But when coders get prepared, discussed and
accepted layout in psd they can only do their best.

If the coder is competent, what's the problem? If they aren't, you hired
the wrong person. Or are you allowing the designer put something
together inappropriate for the web, like rigid pixel-perfect layouts?

--
Berg

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

Ben C wrote:
On 2007-12-31, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:
Ben C wrote:
[...]
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. But HTML generated by code is HTML.

His code doesn't generate HTML.

He has annoyingly removed whitespace from the source. I wish people
wouldn't do that. But all the same you can see that he's creating the
DOM tree with createElement and appendChild, not innerHTML.

(See
http://www.bravelayout.scarabeo.biz/...ndalone-min.js
and http://www.bravelayout.scarabeo.biz/.../example0.html)

At no point does nasty HTML exist, unless you count things like the
Firebug turning the DOM tree back into sort of HTML for the purpose of
displaying it.

All right, you're technically correct. So he's creating an HTML DOM
*tree* that is still a semantically incorrect representation of the
logical structure of the document.

But what's wrong with that? If someone wants to do something else with
the HTML other than display it in a browser (read it, process it with
some other tool, etc.) then they use the source which is the definitive
representation. The DOM tree created by the JS program only exists
temporarily in the browser instance in which it's being displayed. I
don't see how it's hurting anyone.

Ben C wrote:

On 2007-12-31, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:
Ben C wrote:
On 2007-12-31, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:
Ben C wrote:
[...]
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. But HTML generated by code is HTML.
His code doesn't generate HTML.

He has annoyingly removed whitespace from the source. I wish people
wouldn't do that. But all the same you can see that he's creating the
DOM tree with createElement and appendChild, not innerHTML.

(See
http://www.bravelayout.scarabeo.biz/...ndalone-min.js
and http://www.bravelayout.scarabeo.biz/.../example0.html)

At no point does nasty HTML exist, unless you count things like the
Firebug turning the DOM tree back into sort of HTML for the purpose of
displaying it.
All right, you're technically correct. So he's creating an HTML DOM
*tree* that is still a semantically incorrect representation of the
logical structure of the document.

But what's wrong with that?

The whole point of a Document Object Model is to represent a document as
a hierarchical collection of its components labeled according to what
each of them IS. Therefore, if something that isn't a table is added to
the document as a table, it's technically incorrect. Period. The
guidelines against doing this in the markup exist for the same reason.
If you want you *can* use Javascript to wrap blocks of non-heading text
into H1 elements just because you want them to be larger and browsers
will usually display them larger, and you *can* use Javascript to wrap
blocks of non-quoted material into blockquote elements just because you
want them to be indented and you know that browsers will indent them,
but within the context of the Document Object Model, it is *incorrect*.

If someone wants to do something else with
the HTML other than display it in a browser (read it, process it with
some other tool, etc.) then they use the source which is the definitive
representation. The DOM tree created by the JS program only exists
temporarily in the browser instance in which it's being displayed. I
don't see how it's hurting anyone.

It also doesn't hurt anyone if you write HTML in this day and age that
only displays properly in Netscape 4.5. Whether something hurts anyone
isn't the issue. (At least no one has expounded, in any of the messages
that I've read [because I haven't read all of them], on their *right* to
code this way, but I won't be surprised if someone pulls that one out
next. My answer will be the same: *rights* are not the point.)