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

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

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.

I don't understand that at all. I thought the whole point of the DOM was
so that you could write scripts to create elements, change their
attributes, etc.

Note also that the DOM interfaces allow you to create a tree that can't
be represented by valid HTML at all-- you can make a <span> a child of a
<tr> if you want to.

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

Can you tell me where I can find a standard or specification saying
anything like this about the DOM? If it is a matter of technical
correctness then there ought to be one.

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

OK I didn't mean literally hurt anyone.

There are technical reasons why HTML has to be valid, and there are
pragmatic reasons why it is good style to make appropriate use of the
HTML elements to represent the structure and content.

But I don't see that any of reasons apply to a DOM tree you create only
with scripting.

Ben C wrote:

On 2007-12-31, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:
[...]
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.

I don't understand that at all. I thought the whole point of the DOM was
so that you could write scripts to create elements, change their
attributes, etc.

Yes, but not *invalid* ones. The DOM is a hierarchical object *model* of
the document. If you use it to build a representation of an *invalid*
document, then the representation is invalid. If you use it to build a
representation of a semantically flawed document, then you have a
semantically flawed representation. A paragraph is still supposed to be
a paragraph, a title a title, a table a table, a list a list, a
quotation a quotation, and so forth. A misrepresentation of any of these
is a misrepresentation. If the DOM tree has something labeled as a
"table" that isn't a table, it's a misrepresentation.

If you find it useful to introduce misrepresentations, to overcome
shortcomings in either the HTML model or commonly used browsers, or to
inject special functionality (as when people nest elements in
superfluous divs for the sake of permitting extra-fancy CSS tricks),
justify it however you may, but don't imagine that that makes it
anything other than an incorrect representation.

On Dec 31 2007, 7:45 pm, Bergamot <berga... (AT) visi (DOT) com> wrote:

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.
Mainly I refer to behavior of tables and table cells with height set

to 100%

On Dec 31 2007, 7:41 pm, Bergamot <berga... (AT) visi (DOT) com> wrote:

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.
Browser can render same visual result with different DOM trees so they

are already separate. I'm not separating anything artificially.

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.
They do care about what they see, and some of them do care what is

read from server (since it's not always rendered, sometimes it's just
analyzed and used to update index of some search engine).
They certainly do not care about what browser does between the thing
they see when they "View Source" and what they see when they look at
page.

On Dec 31 2007, 7:36 pm, Bergamot <berga... (AT) visi (DOT) com> wrote:

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.
In html I just need BraveLayout.start(layout) before elements that

need to be put in layout, BraveLayout.end() after them and
Bravelayout.fill() at the end of the file or in onload event.
That is all the clutter you have to introduce to your html file no
matter how complex your layout is. Apart from that you can organize
html file as meaningful and semantic as you can.

On Dec 31 2007, 6:28 pm, Rob Waaijenberg <robwaaijenb... (AT) hotmail (DOT) com>
wrote:

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'.
You completely misunderstood me and the whole concept. So I'll try to

explain it step by step since you are interested.

1. You place you content in html file organizing it according to
contents structure so it is semantic, meaningful, etc.(It's the divs
you see while viewing source of my example)
2. Before your meaningful html tags you put BraveLayout.start(layout)
where "layout" is description of desired layout as javascript object.
3. After the content you place BraveLayout.end(), and at the end of
your file you place BraveLayoyut.fill()

When page is loaded and browser reaches BraveLayout.start(layout) it
generates dom tree necessary to achieve desired layout. It does this
by generating table, tr, td nodes in DOM Tree of currently loading
page.
When all of the page is loaded and BraveLayout.fill() is run browser
rips meaningful content tags (in my example divs) and places them in
proper spots of generated layout (table cells generated by my library)
indicated in layout definition.

So it ends up looking nice, being defined easily and keeping html
source file clean.

On Dec 31 2007, 6:12 pm, Rob Waaijenberg <robwaaijenb... (AT) hotmail (DOT) com>
wrote:

brave1979 schreef:

Yes. But HTML generated by code is HTML. The precept is not "HTML
written by hand and stored in a file should be clean and meaningful" but
"HTML should be clean and meaningful".
Generated HTML is not HTML anymore.

First you generate something (quote: "Generated HTML" )

and after you do, it magically turns into something else? (quote: "is
not HTML anymore")

It is DOM Tree, and no one ever
suggested (as far as I know) that DOM Tree should be clean and
meaningful.

Clean and meaningful,
those are qualities that should applie to thoughts
and usenet-posts.
Sorry. "Genrated HTML" and "is not HTML anymore" actually mean the

same thing. "Genreated HTML" is just a shorthand for "generated parts
of dom tree" since you cannot actually generate HTML (as seen in "View
Source") using javascript. You can only modify DOM tree built from
HTML file read from the webserver.

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

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.
Semantically correct HTML DOM *tree* ?

I think that's a new sermon. I never heard anyone preaching that. ;-)

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

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.

Some objections to table layouts are especially targeted at things
seen by people who "View Source" and by search engine robots who try
to index your page so it's not completely irrelevant.

On Dec 31 2007, 7:56 pm, Bergamot <berga... (AT) visi (DOT) com> wrote:

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.
So if you cripple your browser in a way that you can't view my layout

properly than it's an argument against my layout.
And If I cripple my browser in a way that I can't view your layout
properly it's argument *for* your layout?
Isn't it a little bit unfair?

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.
Tell this to you client or employer.

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

Yes, and... ?
And the person sitting behind photoshop can invent something you won't

be able to do in few hours because he does not know the pitfalls of
pure css layouts.
And even If you can get it at some point as intended you will spend to
much of your time on this so you are wasting valuable resource.
And at some point layout can be slightly redesigned to fit clients
changing needs, and changing pure css layout is rarely easy.

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.
Sorry. I fail to see the connection with 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?
World is not perfect. Often you need things that may be considered

inappropriate at some time or another.
Competent coder is a valuable resource and letting him waste many
hours of his time on converting psd to html is not very rational use
of this resource.