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

[Bergamot]

Re: No TABLES in html. No hacks in CSS. Any layout possible, crossbrowser.Tr y it.

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

[Harlan Messinger]

Re: No TABLES in html. No hacks in CSS. Any layout possible, crossbrowser.Tr y it.

brave1979 wrote:

On Dec 31, 2:16 pm, Harlan Messinger
<hmessinger.rem ovet...@comcast .netwrote:

>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 misunderstandin g 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.

[Bergamot]

Re: No TABLES in html. No hacks in CSS. Any layout possible, crossbrowser.Tr y it.

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

[brave1979]

Re: No TABLES in html. No hacks in CSS. Any layout possible,crossb rowser. Try it.

On Dec 31 2007, 7:45 pm, Bergamot <berga...@visi. comwrote:

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%

[brave1979]

Re: No TABLES in html. No hacks in CSS. Any layout possible,crossb rowser. Try it.

On Dec 31 2007, 7:36 pm, Bergamot <berga...@visi. comwrote:

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.sta rt(layout) before elements that
need to be put in layout, BraveLayout.end () after them and
Bravelayout.fil l() 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.

[brave1979]

Re: No TABLES in html. No hacks in CSS. Any layout possible,crossb rowser. Try it.

On Dec 31 2007, 6:28 pm, Rob Waaijenberg <robwaaijenb... @hotmail.com>
wrote:

brave1979 schreef:
>
>
>

On Dec 31, 5:06 pm, Rob Waaijenberg <robwaaijenb... @hotmail.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.sta rt(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.fi ll()

When page is loaded and browser reaches BraveLayout.sta rt(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.fil l() 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.

[brave1979]

Re: No TABLES in html. No hacks in CSS. Any layout possible,crossb rowser. Try it.

On Dec 31 2007, 6:12 pm, Rob Waaijenberg <robwaaijenb... @hotmail.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.

[brave1979]

Re: No TABLES in html. No hacks in CSS. Any layout possible,crossb rowser. Try it.

On Dec 31 2007, 7:51 pm, Harlan Messinger
<hmessinger.rem ovet...@comcast .netwrote:

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.

[brave1979]

Re: No TABLES in html. No hacks in CSS. Any layout possible,crossb rowser. Try it.

On Dec 31 2007, 7:56 pm, Bergamot <berga...@visi. comwrote:

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.

[Ben C]

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

On 2008-01-01, brave1979 <brave1979@o2.p lwrote:

On Dec 31 2007, 7:45 pm, Bergamot <berga...@visi. comwrote:

>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%

The rules in strict mode are very simple. "Circular percentages", i.e.
percentage heights of auto-height containers are treated as auto.

You may get differences in browsers resulting from slightly different
interpretations of the "initial containing block". Setting html, body {
height: 100% } should remove those inconsistencies .

In quirks mode however browsers often try to make circular percentages
"work"-- sometimes by making them percentages of the viewport height or
in the case of table cells first computing the auto height of the cell
and then taking a percentage of that. This is where the specs are
lacking.

Better to find a way not to rely on circular percentages and use strict
mode.

If you're finding that some browsers do allow circular percentages of
table cells even in strict mode, then that's not an inconsistency where
the spec is lacking, it's just a violation of the spec, so don't use
it-- it's a bug and might actually get fixed.

[Rob Waaijenberg]

Re: No TABLES in html. No hacks in CSS. Any layout possible, crossbrowser.Tr y it.

brave1979 schreef:

... converting psd to html is not very rational use
of this resource.

IMHO it is not rational *anytime*

--
Rob

[Rob Waaijenberg]

Re: No TABLES in html. No hacks in CSS. Any layout possible, crossbrowser.Tr y it.

brave1979 schreef:

You completely misunderstood me and the whole concept. So I'll try to
explain it step by step since you are interested.
>

Allright, I'll follow in your footsteps...

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)

OK, I understand this
(my only problem is that divs are not meaningful, but we'll let that rest)

2. Before your meaningful html tags you put BraveLayout.sta rt(layout)
where "layout" is description of desired layout as javascript object.

Do I understand correctly that you have different lay-outs ready,
and here you chose one of them in "BraveLayout.st art(layout)"???

3. After the content you place BraveLayout.end (), and at the end of
your file you place BraveLayoyut.fi ll()
>
When page is loaded and browser reaches BraveLayout.sta rt(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.

This is what you meant by "internally rendered tables"?

When all of the page is loaded and BraveLayout.fil l() 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.
>

Here I'm definitely lost.
I will blame this on my ignorance of javascript. I just don't know
enough about it.
But what I read here is:
- there are meaningful tags
- there is a lay-out made by table cells
- tags are put inside the table cells.

This brings to mind two questions:

1. Why not use a ready-made table layout and fill it up with content.

2. In case I misunderstood the last steps: if table-cells can't be seen
(or in fact do not exist), what then is the difference with a css-based
lay-out.

--
Rob

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

[Ben C]

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

On 2008-01-01, brave1979 <brave1979@o2.p lwrote:
[...]

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.

JS (running in a browser) can generate HTML using innerHTML. Although
you still won't see the generated stuff with View Source.

[brave1979]

Re: No TABLES in html. No hacks in CSS. Any layout possible,crossb rowser. Try it.

On Jan 1, 12:04 pm, Rob Waaijenberg <robwaaijenb... @hotmail.com>
wrote:

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)

>
OK, I understand this
(my only problem is that divs are not meaningful, but we'll let that rest)

You are right. I should have used something else like <ulfor
#menu ... this could be clearer.

2. Before your meaningful html tags you put BraveLayout.sta rt(layout)
where "layout" is description of desired layout as javascript object.

>
Do I understand correctly that you have different lay-outs ready,
and here you chose one of them in "BraveLayout.st art(layout)"???

Usually I have only one layout described in javscript variable named
layout. And "BraveLayout.st art(layout)" builds it according to the
description. But I may have more than one layout each described in
different js variable and with
BraveLayout.sta rt(layoutOfRegi strationPage) I may indicate which
layout I need to be created for me.

3. After the content you place BraveLayout.end (), and at the end of
your file you place BraveLayoyut.fi ll()

>

When page is loaded and browser reaches BraveLayout.sta rt(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.

>
This is what you meant by "internally rendered tables"?

Yes.

When all of the page is loaded and BraveLayout.fil l() 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.

>
Here I'm definitely lost.
I will blame this on my ignorance of javascript. I just don't know
enough about it.
But what I read here is:
- there are meaningful tags
- there is a lay-out made by table cells
- tags are put inside the table cells.

Yes, you got it right.

This brings to mind two questions:
>
1. Why not use a ready-made table layout and fill it up with content.

It's easier to describe layout in js object then write all the table
tr td tags by hand. And I still would need javascript to place tags
inside proper table cells.
And if "pure css" people seen any tables in my source files they would
burn me alive. :-)
And by abstracting layout definition from it's implementation
(currently tables) I may some day change implementation to something
else than tables (some new features of html5 or css3) and keep
previously defined layouts working.

2. In case I misunderstood the last steps: if table-cells can't be seen
(or in fact do not exist), what then is the difference with a css-based
lay-out.

Table cells exist only in DOM Tree so table, tr, td tags can't be seen
when viewing source files.
CSS layouts uses only CSS styles for positioning meaningful tags on
page. BraveLayout uses additional generated elements (tables and table
cells) in DOM Tree to do the positioning.
Advantages of BraveLayout is that you can achieve more complex
crossbrowser layouts easier.

[Bergamot]

Re: No TABLES in html. No hacks in CSS. Any layout possible, crossbrowser.Tr y it.

brave1979 wrote:

On Dec 31 2007, 7:56 pm, Bergamot <berga...@visi. comwrote:

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

No, it means I don't need (or want) your layout to use the page. I
disable CSS surprisingly often, usually because poorly thought out
designs don't adapt to my browser set up.

And If I cripple my browser in a way that I can't view your layout
properly it's argument *for* your layout?

You don't seem to get that it's not for *any* layout.

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

Are they experts in web stuff? It is your responsibility as a subject
matter expert to teach them the error of their ways. Unless the
employer/client is a real jerk, they usually listen if you do it in a
respectful manner.

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.

It's not really a matter of CSS layouts vs table layouts here. It's a
matter of designing something suitable for the web in general. Teach
them that the web is not paper. If you aren't willing to do that, then
you'll forever be in a no-win position.

--
Berg