By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,686 Members | 2,589 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,686 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
Dec 30 '07 #1
Share this Question
Share on Google+
53 Replies


P: n/a
On Sun, 30 Dec 2007 13:42:06 +0100, brave1979 <br*******@o2.plwrote:
Please check out my javascript library
Using javascript for layout.... terrible idea. And hardly crossbrowser.

--
Rik Wasmus
Dec 30 '07 #2

P: n/a
On Dec 30, 5:49 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.comwrote:
On Sun, 30 Dec 2007 13:42:06 +0100, brave1979 <brave1...@o2.plwrote:
Please check out my javascript library

Using javascript for layout.... terrible idea. And hardly crossbrowser.
Really? How do you call a thing that works in IE, Firefox, Opera,
Safari and Konqueror then ?

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.
Dec 30 '07 #3

P: n/a
On Sun, 30 Dec 2007 23:46:20 +0100, brave1979 <br*******@o2.plwrote:
On Dec 30, 5:49 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.comwrote:
>On Sun, 30 Dec 2007 13:42:06 +0100, brave1979 <brave1...@o2.plwrote:
Please check out my javascript library

Using javascript for layout.... terrible idea. And hardly crossbrowser.
Really? How do you call a thing that works in IE, Firefox, Opera,
Safari and Konqueror then ?
A thing that works in certain browsers under certain conditions provided
they have certain settings? It would not work in my Opera, as I myself
have javascript disabled for most sites, save a few exceptions.
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.
I have no real trouble getting nice layouts in all browsers without any
hacks in CSS or javascript (oh yes, I do use it to provide extended
usability/features for those who have it enabled, those who have it
disabled don't miss anything). No, they are not pixel for pixel alike,
then again, I don't design them to need that.

Really knowing CSS & HTML, and the way to publish on the www is quite
enough.
--
Rik Wasmus
Dec 31 '07 #4

P: n/a
On Dec 31, 1:56 am, "Rik Wasmus" <luiheidsgoe...@hotmail.comwrote:
On Sun, 30 Dec 2007 23:46:20 +0100, brave1979 <brave1...@o2.plwrote:
On Dec 30, 5:49 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.comwrote:
On Sun, 30 Dec 2007 13:42:06 +0100, brave1979 <brave1...@o2.plwrote:
Please check out my javascript library
Using javascript for layout.... terrible idea. And hardly crossbrowser.
Really? How do you call a thing that works in IE, Firefox, Opera,
Safari and Konqueror then ?

A thing that works in certain browsers under certain conditions provided
they have certain settings? It would not work in my Opera, as I myself
have javascript disabled for most sites, save a few exceptions.
A thing that works in all major modern browser with default settings.

Is that really valid argument against my lib that you have found
proper option in your browser and disabled it?
Is a fact that I disabled CSS in my browser a valid argument against
tableless layouts? Should you use tables and 1px gifs because of that
fact?
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.

I have no real trouble getting nice layouts in all browsers without any
hacks in CSS or javascript (oh yes, I do use it to provide extended
usability/features for those who have it enabled, those who have it
disabled don't miss anything). No, they are not pixel for pixel alike,
then again, I don't design them to need that.
You design them. That's the reason why they are easy for you to code.
And you still can get them right in all browsers.
Person who knows photoshop and person who knows html are not always
the same person. You can remove from your design things that you don't
know how to do in html. But when coders get prepared, discussed and
accepted layout in psd they can only do their best.
Really knowing CSS & HTML, and the way to publish on the www is quite
enough.
Internet is living proof for that but assembler is also quite enough
to implement anything at any machine, it's just not the most efficient
way.

Dec 31 '07 #5

P: n/a
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.
Dec 31 '07 #6

P: n/a
On 2007-12-31, brave1979 <br*******@o2.plwrote:
On Dec 31, 12:31 am, Harlan Messinger
<hmessinger.removet...@comcast.netwrote:
>brave1979 wrote:
On Dec 30, 7:02 pm, Harlan Messinger
<hmessinger.removet...@comcast.netwrote:
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.
Dec 31 '07 #7

P: n/a
On Dec 31, 7:01 am, Harlan Messinger
<hmessinger.removet...@comcast.netwrote:
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.
Dec 31 '07 #8

P: n/a
On Dec 31, 9:25 am, Ben C <spams...@spam.eggswrote:
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.
Dec 31 '07 #9

P: n/a
Harlan Messinger wrote:
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.
I've given up trying to reason with him...

I would also love to see a real demo page, with some real content, and
that is still visible when JavaScript is unavailable.

http://k75s.home.att.net/show/brave.jpg

--
-bts
-Friends don't let friends drive Vista
Dec 31 '07 #10

P: n/a
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.

Dec 31 '07 #11

P: n/a
On 2007-12-31, brave1979 <br*******@o2.plwrote:
[...]
>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.
Dec 31 '07 #12

P: n/a
On 2007-12-31, Harlan Messinger <hm*******************@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 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?
Dec 31 '07 #13

P: n/a
brave1979 wrote:
>
This template does not use my lib.
You don't use your own product? Why would you expect anyone else to?

--
Berg
Dec 31 '07 #14

P: n/a
On Dec 30, 5:42 am, brave1979 <brave1...@o2.plwrote:
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.
Dec 31 '07 #15

P: n/a
On Dec 31, 2:11 pm, "Beauregard T. Shagnasty"
<a.nony.m...@example.invalidwrote:
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.
Dec 31 '07 #16

P: n/a
On Dec 31, 2:16 pm, Harlan Messinger
<hmessinger.removet...@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 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?
Dec 31 '07 #17

P: n/a
On Dec 31, 2:51 pm, Ben C <spams...@spam.eggswrote:
On 2007-12-31, Harlan Messinger <hmessinger.removet...@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 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.
Dec 31 '07 #18

P: n/a
On Dec 31, 2:58 pm, Bergamot <berga...@visi.comwrote:
brave1979 wrote:
This template does not use my lib.

You don't use your own product? Why would you expect anyone else to?
I don't use it in this page. But I already redone one of my webapps
using BraveLayout. I'm gonna show it to you later. I also have done
webpage of some small company with very early protoype of this lib and
it works for almost a year without any complaint whatsoever, but this
I am not going to show you this one because I know how strong some
people feel about css, and i don't want anyone to trouble my client.

Dec 31 '07 #19

P: n/a
Ben C wrote:
On 2007-12-31, Harlan Messinger <hm*******************@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 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. 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".
Dec 31 '07 #20

P: n/a
On Dec 31, 3:10 pm, while-one <Sandy.Pittendr...@gmail.comwrote:
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.
Before I came up with this idea I was so desperate that I wanted to
ditch html altogether for all purposes in favor of something like ZK
or OpenLaszlo but I didn't like the idea of troubling my visitors with
downloading huge framework and learning myself new metalanguage to
probably discover at some point that it also has some severe
limitations.

I just needed small simple library that could allow me to build layout
quickly without cluttering html file. I even considered using flash
not js and generated tables for this purpose, but I don't know flash
that good. Maybe I'll try it in the future as an exercise.
Dec 31 '07 #21

P: n/a
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?
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.

"...internally renders tables..."???????????????????

Huh????

--
Rob
Dec 31 '07 #22

P: n/a
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. It is DOM Tree, and no one ever
suggested (as far as I know) that DOM Tree should be clean and
meaningful.
Dec 31 '07 #23

P: n/a
In article
<7b**********************************@1g2000hsl.go oglegroups.com>,
brave1979 <br*******@o2.plwrote:
On Dec 31, 2:58 pm, Bergamot <berga...@visi.comwrote:
brave1979 wrote:
On Dec 31, 7:02 am, Michael Fesser <neti...@gmx.dewrote:
>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 ;-)).
No, it's theft. And like all hacks, it doesn't scale.
Dec 31 '07 #24

P: n/a
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 ?
What browser you are using?
Dec 31 '07 #25

P: n/a
On 2007-12-31, Harlan Messinger <hm*******************@comcast.netwrote:
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.
Dec 31 '07 #26

P: n/a
On Dec 31, 6:07 pm, Ben C <spams...@spam.eggswrote:
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)

Dec 31 '07 #27

P: n/a
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.

--
Rob
Dec 31 '07 #28

P: n/a
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'.

--
Rob

What browser you are using?
Dec 31 '07 #29

P: n/a
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
Dec 31 '07 #30

P: n/a
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
Dec 31 '07 #31

P: n/a
brave1979 wrote:
On Dec 31, 2:16 pm, Harlan Messinger
<hmessinger.removet...@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 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.
Dec 31 '07 #32

P: n/a
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
Dec 31 '07 #33

P: n/a
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%
Jan 1 '08 #34

P: n/a
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.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.

Jan 1 '08 #35

P: n/a
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.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.
Jan 1 '08 #36

P: n/a
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.
Jan 1 '08 #37

P: n/a
On Dec 31 2007, 7:51 pm, Harlan Messinger
<hmessinger.removet...@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.
Jan 1 '08 #38

P: n/a
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.
Jan 1 '08 #39

P: n/a
On 2008-01-01, brave1979 <br*******@o2.plwrote:
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.
Jan 1 '08 #40

P: n/a
brave1979 schreef:
... converting psd to html is not very rational use
of this resource.
IMHO it is not rational *anytime*

--
Rob
Jan 1 '08 #41

P: n/a
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.start(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.start(layout)"???
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.
This is what you meant by "internally rendered tables"?
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.
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.
Jan 1 '08 #42

P: n/a
On 2008-01-01, brave1979 <br*******@o2.plwrote:
[...]
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.
Jan 1 '08 #43

P: n/a
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.start(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.start(layout)"???
Usually I have only one layout described in javscript variable named
layout. And "BraveLayout.start(layout)" builds it according to the
description. But I may have more than one layout each described in
different js variable and with
BraveLayout.start(layoutOfRegistrationPage) 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.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.

This is what you meant by "internally rendered tables"?
Yes.
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.

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.
Jan 2 '08 #44

P: n/a
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
Jan 3 '08 #45

P: n/a
On 3 Sty, 05:48, Bergamot <berga...@visi.comwrote:
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.
I'm sorry. I guess I'm completely lost in this argumentation.
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.
Experts are not to teach anybody anything, that's what teachers are
for. Experts are to use their experise to help people do things they
want to do but don't know how to do themselves.
If you can tell your client what he wants/needs (and that is by
accident one of the things you can do and like to do) then you are
really lucky guy. :-)
In my life It's more like Golden Rule: "He Who Has The Gold Makes The
Rules"
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.
Once you have technology to achieve what they want everybody wins.
They have what they want. And you can deliver it to them easily.
Jan 3 '08 #46

P: n/a
Ben C wrote:
On 2008-01-03, Bergamot <be******@visi.comwrote:
>>
Anybody tried this thing with JAWS or some other screen reader?

The idea is that the screen reader would read out the uncluttered HTML,
not the generated table soup.
I don't think it's that simple. All the major Windows screen readers use
IE's rendering engine for web browsing. I presume they'll only "look" at
the HTML if JavaScript is disabled.
I don't know if that actually works.
It seems unlikely, to me anyway.

--
Berg
Jan 3 '08 #47

P: n/a
On Jan 3, 4:36 pm, Bergamot <berga...@visi.comwrote:
Ben C wrote:
On 2008-01-03, Bergamot <berga...@visi.comwrote:
Anybody tried this thing with JAWS or some other screen reader?
The idea is that the screen reader would read out the uncluttered HTML,
not the generated table soup.

I don't think it's that simple. All the major Windows screen readers use
IE's rendering engine for web browsing. I presume they'll only "look" at
the HTML if JavaScript is disabled.
I don't know if that actually works.

It seems unlikely, to me anyway.
Could somebody test this please?
Jan 6 '08 #48

P: n/a
On Jan 3, 4:36 pm, Bergamot <berga...@visi.comwrote:
Ben C wrote:
On 2008-01-03, Bergamot <berga...@visi.comwrote:
Anybody tried this thing with JAWS or some other screen reader?
The idea is that the screen reader would read out the uncluttered HTML,
not the generated table soup.

I don't think it's that simple. All the major Windows screen readers use
IE's rendering engine for web browsing. I presume they'll only "look" at
the HTML if JavaScript is disabled.
I've checked how jaws actually behaves.

It reads whatever is seen on the screen line by line. It does not read
HTML source. It does not read DOM tree. It seems like it reads actual
pixels visible on the screen.
So as far as I can figure out any layout that has more than one column
is not JAWS friendly because it reads one line from left column and
immediately, without stopping reads line from center column. And then
it reads second line from left column and immediately second line from
center column. I tested it with pages using my lib and pages from
zengarden. They behave exactly the same. I guess any person who uses
JAWS must probably disable javascript and css on all pages to avoid
multiple columns. In such case my layout and pure css layouts behave
exactly the same.
Jan 6 '08 #49

P: n/a
brave1979 wrote:
>
I've checked how jaws actually behaves.

It reads whatever is seen on the screen line by line. It does not read
HTML source. It does not read DOM tree.
Have you verified that there aren't configuration options that do it
differently?

BTW, you do know that JAWS isn't the only reader, eh? It is probably the
most used one, though.

--
Berg
Jan 6 '08 #50

53 Replies

This discussion thread is closed

Replies have been disabled for this discussion.